Nieuwe ray-tracingtechniek voor realistische graphics

Op de CeBit-beurs toonde een team van de Universiteit van Saarland uit Duitsland een nieuwe techniek om ray-tracing te gebruiken zonder dat daar monstermachines aan te pas moeten komen.

Ray-tracing is een techniek die driedimensionele graphics, bijvoorbeeld games, veel realistischer kan maken. Tot voor kort moesten daar veel krachtige computers voor gebruikt worden, maar een team wetenschappers uit Duitsland heeft laten zien dat deze techniek nu ook gebruikt kan worden door middel van het inzetten van een aantal specifieke chips in combinatie met high-end grafische kaarten. De techniek wordt nu vooral gebruikt in films, voor het realistischer maken van special effects, of voor cartoons.

Het team van de Universiteit van Saarland heeft een serie ray-tracingalgoritmes ontwikkeld die de techniek veel makkelijker in gebruik maakt. De algoritmes zijn uitstekend te gebruiken met chips met meerdere processing cores. 'Aparte cores kunnen gemakkelijk gebruikt worden voor het berekenen van verschillende lichtstralen. Op die manier maak je optimaal gebruik van de aanwezige computerkracht', aldus een woordvoerder. Een van de wetenschappers heeft de techniek gebruikt om ray-traced versies van Quake 3 en 4 te maken. Met traditionele rendertechnieken worden minder goede resultaten behaald. Deze ray-traced versies bieden de speler veel betere lichteffecten dan wanneer traditionele rendertechnieken gebruikt worden. De algoritmes worden beschikbaar gemaakt via het Open RT-project.

Reacties (49)

[Electrowolf]

Sorry, maar erg onder de indruk ben ik niet.

Dit om het simpele feit dat raytracing zo ongeveer het ideale algoritme is om te multie-threaden. Iedere core laat je 1 straaltje bereken en je hebt zo hoge framerates. Om dit voor elkaar te krijgen heb je, bij de raytracer die ik heb gemaakt, letterlijk minder dan 5 regels code nodig om dit te doen. Als je dit aanzet op een dual core machiene zie je bijna 50% afname in de rederingtijd.

Dat ze hier een aparte chip voor hebben gemaakt is mooi, maar ik denk (geef source) dat het hier dus gaat om een chip met veel kleine cores die wiskundige vergelijkingen snel kunnen oplossen. Op die manier kan je een chip maken die ideaal is voor dit soort dingen en je snel resultaten kan halen met deze specifieke toepassing.

Toch juich ik de publicatie toe, want zoals te zien is aan de reacties weten veel mensen niet eens wat het is.
Wat mij nog interessant lijk is om een raytracer in een functionele taal (bv haskell) te maken ipv imperatieve talen. Dan zal je waarschijnlijk nog betere resultaten gaan krijgen!

(PS. de raytracer was gemaakt in Java, ook al is het niet de meest ideale taal voor zo iets.)

Edit: rephrase en typo

[doxick]

kijk, en dat is nou het grote verschil:

Nee een raytracer is niet het ideale algorithme omdat je het per pixel kunt verdelen per thread.
Cache misses spelen nogal parten op zo'n moment lijkt mij he...
Het is inderdaad WEL ideaal om het op te splitsen, dat klopt, maar niet per pixel... per 16*16 square wordt volgens mij veel gebruikt.
Daarnaast ligt er wel iets meer aan ten grondslag dan enkel 5 regels code schat ik. Ik ben er geen expert in (Zelfs geen amateur) maar ik vind het wel interressant.

Daarnaast haal je geen hoge framerates op huidige hardware wil je de raytracer echt GOED laten werken (eg: reflectie en refractie bijvoorbeeld...).
Ik hoorde dat op de GDC een raytracer door IBM getoond werd op 3fps op een 24core bladeserver, ZONDER refractie en reflectie... Blijkbaar is het dan niet ZO makkelijk als het lijkt...

[Electrowolf]

Hangt van wat je er allemaal bij doet etc etc.
De indruk die ik hier krijg is dat het een sterk geoptimaliseerd algoritme is, niet een echt nieuwe ontdekking.
Heb even gezocht, ze gebruiken zelf ook niet het minste:

a cluster with 20 AMD XP1800 was used

http://graphics.cs.uni-sb...egoshooter/downloads.html

Ik ben zelf een raytracer liefhebber, maar heb zwaar de indruk dat het resultaat nogal wordt opgeblazen.

En de cache misses zijn ook realtief, hangt erg af van andere factoren(bv. reflections of AA) en hoe je je algoritmes heb geoptimaliseerd. Er zullen vast optimalisaties zijn waar 1x1 berekenen sneller is dan 16x16, maar er zullen er ook zijn waar bij dit niet het geval is. Het probleem naar mijn mening is dan ook dat er geen "ideale oplossing" is.

@Zigi_Samblak
Waar doxick op doelt is dat je met sommige optimalisatietechnieken betere snelheden haalt als je informatie van je pixels om je heen "on the fly" onthoud, en je sommige dingen minder vaak hoeft uit te rekenen
*Raytracer denkt: hmmm, ik heb de vorige keer die muur geraakt.. laat ik eens eerst kijken of ik die nu weer raak!

[RickDeckard]

Het is inderdaad WEL ideaal om het op te splitsen, dat klopt, maar niet per pixel... per 16*16 square wordt volgens mij veel gebruikt.

In theorie is ray-tracing toch echt wel een ideaal algoritme om te parallelliseren. De berekeningen die je moet uitvoeren voor het bepalen van de kleurwaarde van één pixel zijn immers totaal onafhankelijk van de berekeningen voor alle andere pixels. Er moet dus op geen enkel moment gesynchroniseerd worden tussen de verschillende threads - vandaar dat de bewering over 5 regels code vast geen al te grote overdrijving is.

In het uiterste geval heb je voor elke pixel een eigen core met zijn eigen geheugen dat de representatie van de wereld bevat en dan is er zelfs geen sprake van cache misses en andere geheugenconflicten.

[bavanandel]

De berekeningen die je moet uitvoeren voor het bepalen van de kleurwaarde van één pixel zijn immers totaal onafhankelijk van de berekeningen voor alle andere pixels.

In principe heb je gelijk. Losse pixels kunnen inderdaad volledig los van elkaar berekend worden. Wil je echter speedups, dan kun je gebruik maken van het feit dat de kans dat twee naast elkaar gelegen pixels op het scherm een vrij grote kans vertonen bij hetzelfde object te behoren. Wanneer dit daadwerkelijk zo is kan gebruikt worden gemaakt van de al "cached data structures": omdat de rays naar hetzelfde object wijzen zullen ze ook hetzelfde pad door de ruimtelijke objectindeling volgen. Dit kan zeker invloed hebben op de performance.

Van acm.org:

Ray coherence has an additional side effect of promoting accesses to already in-cache data structures, yielding better performance than random access patterns.

[Verwijderd]

Bron? Bij pure raytracing kun je perfect iedere pixel geheel afzonderlijk van elkaar renderen, dus 16x16 is niet nodig en ook dan zouden er zelfs op CGA resolutie genoeg blokjes overblijven voor heel wat threads.

Maar dit gaat dus over een nieuwe rendertechniek die waarschijnlijk juist wel pixels tegelijk uitrekent.

[TweakerNummer]

Er was al heel lang een RayTraced versie van Quake 3. De plaatjes zijn ook al heel oud. Zie http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/

[Bartjuh]

Jup, je kon altijd kiezen tussen ray-traced shadows, of shadow map. Maar shadow map was altijd mooier.

Maar dit is dus een soort verbeterde ray-trace...

[Verwijderd]

Bedoel je in realtime of in 3ds max ofzo. Voor zover ik weet is er nog geeneen spel wat echte raytracing voor shadows gebruikt.

Als je max bedoeld, komt dat omdat shadowmaps van zichzelf al een beetje geblurd zijn, ookal komt je licht vanuit een enkel punt. In dat geval is raytracing eigenlijk veel realistischer, echter, in de werkelijkheid hebben we maar heel weinig echte punt lichtbronnen (de zon bijvoorbeeld zien wij als een schijf, die over het gehele gebied lichtgeeft). Als je area lichtbronnen zou raytracen ziet het er wel weer stukken beter uit dan shadow maps, maar dat is echt zo zwaar dat het zelfs voor offline rendering meestal nog te lang duurt.

[Menesis]

inderdaad. En dan heb je nog veel meer technieken nodig voordat het fotorealistisch is. Want wat doet het licht nadat het een object heeft bereikt in het echt? Juist; het weerkaatst weer door (dit heet indirect illumination). Dit is een nogal belangrijke techniek om binnenscene's mooi te belichten.
Al zijn ze daar ook al erg ver mee zie ik nu:
http://www.fantasylab.com/newPages/rtgi.html

[Fireshade]

@Menesis:

het weerkaatst weer door (dit heet indirect illumination)

Dat heet "radiosity"

[dcm360]

Shadow map was altijd mooier dan ray-trace omdat ray-trace langer duurt om te berekenen, en dat dat waarschijnlijk een beetje werd afgeraffeld om het spel speelbaar te houden.

[PuzzleSolver]

Hier de nieuwe versie van die site. Het is gemaakt in OpenRT welke ook in het artikel wordt genoemt.

http://www.q3rt.de/

en quake 4

http://www.q4rt.de/

en nog een leuk artikel hierover

http://www.pcper.com/arti...aid=334&type=expert&pid=4

[CR35]

er staat ook quake 3 en 4...

[MneoreJ]

Zie ook bv. deze paper van Intel. Real-time ray tracing zit al langer in de lucht; tot nu toe ontbrak het alleen aan rekencapaciteit. Met slimmere (paralleliseerbare) algoritmes en multicores zal dit steeds aantrekkelijker worden.

We kunnen als eerste hybridmodellen verwachten waarbij raytracing gebruikt wordt voor sommige lighting, en later misschien volledig geraytracete omgevingen. Daar kun je echt wijze dingen mee doen, zoals echte spiegeling en realistische highlights en schaduwen (ook met tinten).

Dan alleen nog even omschakelen op vectors en we zijn gelijk van al die lelijke, niet-schalende polygonen af. Grapje, het zal nog wel wat langer duren voordat we daar real-time iets mee kunnen...

[kindokolo]

Realtime raytracing biedt voordelen in vele opzichten. De rendering gebeurt op basis van de wetten van de optica en zijn daarom bijna per definitie veel realistischer. Bovendien kun je hiermee veel grotere 3d-modellen renderen dan met de huidige rastertechniek, omdat alleen datgene wat zichtbaar is wordt gerenderd (zie bijvoorbeeld http://openrt.de/Applications/massivert.php, een model van een boeing 777 bestaande uit 350 miljoen polygonen)
Zeer interessant in ieder geval. Ik ben benieuwd wanneer de eerste toepassingen voor de consument beschikbaar zullen zijn

[doxick]

een leraar van mij is zelf ook bezig met realtime raytracing en ik weet dat die verschrikkelijk goede results haalt...

op mijn c2d 6400 draait het op 12fps op 800*600 met refractie, reflectie etc.

dat is in tegenstelling tot de "runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)" van de bovenstaande link (http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/) toch wel zeer netjes.

ik vraag me dan ook af in hoeverre de algorithmes verbeterd kunnen worden...
hoek van inval, refractie/reflectie... kun je weinig aan veranderen toch ?

[MneoreJ]

ik vraag me dan ook af in hoeverre de algorithmes verbeterd kunnen worden...
hoek van inval, refractie/reflectie... kun je weinig aan veranderen toch ?

Maar da's geen algoritme, da's een berekening. Een ray trace algoritme bestaat nou juist uit het berekenen van al die dingen voor een hele hoop stralen langs een hele hoop objecten. En daar valt een hoop te halen op optimalisatiegebied: misschien kan ik van tevoren bepalen dat bepaalde stralen nooit ergens terecht komen, of dat bepaalde objecten niet mee kunnen doen, of kan ik de resultaten van een eerdere berekening hergebruiken, of kan ik het resultaat van deze berekening schatten aan de hand van de andere, of...

En dan nog geschikte manieren vinden om een en ander in parallel te doen. Nee, daar gaat best wel wat denkwerk in zitten.

Edit: oh, en dan nog bedenken dat het resultaat niet "perfect" hoeft te zijn (kan ook niet, kost veel te veel tijd) maar "overtuigend". Weer een nieuwe dimensie van optimalisatie.

[Verwijderd]

Die leraar heet toevallig Jacco Bikker? Hij haalt inderdaad interessante resultaten.

[doxick]

jep

[Saven]

Tof, fotorealistische games zijn dus niet zo ver weg meer

[Verwijderd]

Toch wel. Ray-tracing zorgt voor realistische reflecties en schaduw, maar vergt daarbij wel nog heel wat meer rekenkracht dan rasterisatie om bijna hetzelfde te bekomen. Bovendien is het vereenvoudigde model van ray-tracing onvoldoende om alle mogelijke lichtinteracties te berekenen die nodig zijn voor echte realistische beelden. Daar is nog eens ruwweg 1000x meer rekenkracht voor nodig dan vandaag beschikbaar op een systeem voor consumenten.

[RefleXion]

Als Moore's law nog 10 jaar stand houd zouden we er dus moeten zijn. Dit zie ik ook nog wel gebeuren door steeds maar meer cores aan processors toe te voegen (voor ray-tracing ook goed te gebruiken). Ik denk dan ook dat raytracing in de toekomst de standaard wordt, het is gewoon een veel betere benadering van de realiteit.

[YopY]

Denk je niet dat de graphics en beeldresoluties etc dan alweer veel hoger en beter zijn? Ray-tracing mag dan wel (op het moment) mooie beelden geven, maar over 10 jaar, wie weet of het dan nog wel nodig is? En daarnaast, de rekenkracht die bij ray-tracing nodig is word verveelvuldigd al naar gelang de hoeveelheid en/of de schermresolutie, ik kan mij best voorstellen dat je tegen die tijd al weer veel grotere spelomgevingen hebt.

Ray-tracing geeft mooie(re) graphics, maar het is niet het meest efficiente.

Voor een stukje meer info over ray-tracing (als je programmeur bent of er in geinterreseerd bent), kijk eens hier, een programma in een weekend geschreven die mbv ray-tracing heel mooie renders geeft, inclusief reflectie enzovoorts.

[GigaDave56]

Denk je niet dat de graphics en beeldresoluties etc dan alweer veel hoger en beter zijn? (YopY)

Er is een grens aan wat ik aan mijn muur kan hangen / op mijn bureau kwijt kan qua grootte. Datzelfde geldt dan gelijk voor de resolutie. Ik hoef geen 12800x9600 (losse pols factor ) op mijn 22"-32" (factor kijkafstand) monitor te hebben.

[HellPunk]

De vraag is of we dat wel willen... fotorealistische graphics staan niet gelijk met goede graphics, d.i. graphics die de spelbeleving ten goede komen. In een RPG is bijvoorbeeld een 'gefantaseerd' bos misschien wel beter dan een fotorealistische weergave.

[JDx]

Voor fotorealistische games heb je ook Global Illumination nodig, niet alleen ray-tracing... dat kost ook enorm veel rekentijd...

[CR35]

met raytracing wordt realtime de licht uitstrooing berekent. Dus ook wanneer licht iets raakt en vervolgens weer weerkaats. Met raytracing kun je dus ook echte realistische spiegelingen maken.

[Verwijderd]

Niet echt. Dat is global illumination/radiosity. Er zijn radiosity implementaties die gebruik maken van raytracing (monte carlo), maar over het algemeen doen raytracers alleen directe belichting. directe reflectie (dus niet diffuus) is ook vrij makkelijk met raytracing te implementeren, dus dat hebben ze meestal ook nog wel.

[pim]

Veel spellen van nu zijn al gerytraced. Daarbij worden voor alle statische objecten, geraytracede textures gegenereerd.

[doxick]

nee, die zijn er nog niet aangezien die niet commercieel haalbaar zijn omdat ze er een bluegene bij moeten geven wil het vloeiend draaien

[pim]

Bluegene? Maar halflife2 is bijv. (niet realtime) geraytraced.

[doxick]

"Blue Gene is een IBM-project om de volgende klasse van petaflop-schaal supercomputers te ontwikkelen"

ja inderdaad, als je het zo bekijkt wel. de schaduwen van statische lichten op statische objecten zijn dan van te voren geraytraced waarschijnlijk.
Ik had het zelf over realtime raytracen

[darkfader]

Ik vind het goed dat dit soort nieuwe technieken in het nieuws komen. Op een gegeven moment komt hier toch een redelijke vraag naar.
De drempel qua raytracing techniek om dezelfde qualiteit als conventionele techniek is in zicht. Daarna wordt het alleen maar mooier.

[Verwijderd]

"Wat mij nog interessant lijk is om een raytracer in een functionele taal (bv haskell) te maken ipv imperatieve talen. Dan zal je waarschijnlijk nog betere resultaten gaan krijgen!"

Wat is dat nou weer voor onzin Een taal als C/C++ blijft toch echt een stuk beter hiervoor omdat de statements redelijk letterlijk door de computer uitgevoerd kunnen worden. Op die manier kun je veel beter nagaan wat je moet optimaliseren e.d.
Bovendien gaat het hier om chips, en ik denk niet dat die zich laten programmeren met een functionele programeertaal