Hoe staat het met realtime raytracing?

Een rendertechniek in de spotlight

Tot slot

Realtime raytracing in games is nu nog een redelijk eenzijdige affaire, met vooral Nvidia als grote speler, en enkele ontwikkelaars als Crytek en Wargaming die de technologie op hun eigen manier implementeren. Hierin komt in de komende jaren waarschijnlijk verandering. Zo zal de installed base van apparaten met ondersteuning voor hardware-accelerated raytracing in 2020 en de jaren daarop flink stijgen dankzij de komst van nextgen-consoles. Een grotere installed base kan het interessanter maken voor ontwikkelaars om de technologie te proberen, vooral als ontwikkelaars in één klap van zowel de consolemarkt als de pc-markt kunnen profiteren door het gebruik van standaarden als DXR.

Het is natuurlijk nog afwachten hoeveel ontwikkelaars daadwerkelijk gebruik gaan maken van de raytracinghardware in consoles, maar onze verwachting is dat ze in ieder geval zullen experimenteren met de rendertechniek. Ontwikkelaars delen dat sentiment; TJ Wagner van de World of Tanks Console-group vertelt: "We verwachten dat de beschikbaarheid van raytracing in nextgen-consoles ontwikkelaars zeker zal aanmoedigen om de technologie te onderzoeken en ermee te experimenteren." Tegelijk stelt hij dat de krachtigere hardware ook kan worden gebruikt om traditionelere rendertechnieken te verbeteren. "Elke ontwikkelaar krijgt de flexibiliteit om zelf uit te zoeken hoe hij de hardware het best kan gebruiken in zijn eigen games."

Natuurlijk blijft de impact op prestaties een probleempunt. Zelfs huidige implementaties van raytracing, die voornamelijk gebruikmaken van raytracing voor een enkel spelelement en de rest van de game alsnog met rasterization renderen, leiden nog tot flink prestatieverlies in games. De huidige RTX-gpu's bieden op dit gebied verbeteringen, maar nog geen oplossing. Ampere, de PS5, de Xbox Series X en wat AMD in de planning heeft, zullen hierin waarschijnlijk nog geen verandering brengen. Pathtracing in triple-A-games zal dan ook nog enkele jaren op zich laten wachten.

Toch hebben ontwikkelaars enorme stappen gezet in 2019. In maart liet cloudgraphics-bedrijf Otoy weten dat het een scène met pathtracing kan renderen op één frame per seconde met zijn Octane-engine. Hiervoor worden vijftig samples per pixel vergaard. Tegelijkertijd neemt Quake II RTX op een hogere framerate minimaal vier samples per pixel. Enkele jaren geleden zou alleen het denoisen van de scène al minutenlang duren. Nieuwe gpu-architecturen en verdere optimalisaties zullen gaandeweg steeds meer mogelijk maken, dus games met volledige pathtracing zijn in de toekomst in ieder geval niet ondenkbaar.

Reacties (95)

Fun fact: Wolfenstein 3D van iD Software maakte in 1992 al gebruik van raycasting in real time.

Het gaat hier over twee verschillende technieken, die allebei ray-casting heten. Eentje schiet alleen primary rays in echte 3d space, dus van oog door pixel tot aan object, en is wat in de tekst wordt beschreven. Wat wolfenstein deed is op een 2d map een intersectie berekenen en die dan als fake 3d tekenen. Daarom kon je in wolfenstein (en ook Doom) bijvoorbeeld nooit onder een brug doorlopen.

Daarom kon je in wolfenstein (en ook Doom) bijvoorbeeld nooit onder een brug doorlopen.

Ook in Duke Nukem 3D werkte de rendering net als in Doom, maar door middel van een slimme truc kon je wel in verschillende ruimten komen die boven elkaar lagen. Zo kwam je in de bioscoop vanuit de lobby via een wenteltrap naar de bovenliggende projectorruimte. De truc was dat er verschillende "maps" waren die overeenkwamen met verdiepingen. Klom je de wenteltrap op, dan kwam je zonder het te merken van de ene in de andere plattegrond terecht. Maar binnen zo'n plattegrond had alles weer 1 bodem en 1 plafond; nergens krijg je in dat spel twee ruimten boven elkaar te zien.

Ook in Duke Nukem 3D werkte de rendering net als in Doom

Nee hoor, de technieken van Wolf3D, Doom en Duke3D zijn in feite allemaal verschillend, al lijken die van Doom en Duke3D wel wat meer op elkaar. Maar goed, Duke3D was ook meer een doorontwikkeling - die kwam in hetzelfde jaar uit als Quake, die al helemaal was overgestapt op triangle rasterization.

Duke3D gebruikt geen BSP tree zoals Doom dat wel doet, waardoor er geen kostbare preprocessingstap nodig was en de leveldata at runtime kon veranderen. Maar dit betekent wel dat het render-algoritme essentieel anders is, daar Doom de BSP tree gebruikt om de ruimtes van voor naar achter te kunnen tekenen. Bovendien ondersteunde Duke3D extra features zoals gekantelde vloeren en plafonds, waar die bij Doom alleen maar strak horizontaal konden zijn. Een andere bijkomstigheid van de sectors+portals ipv BSP in Duke3D is dat je technisch gezien surrealistische ruimtes kon creëren die in de echte wereld zouden overlappen, zoals een huis dat van de binnenkant veel groter is dan van de buitenkant, of een daadwerkelijke wenteltrap waarbij je dus wel een room-above-room kan hebben. De restrictie was wel dat je die verschillende overlappende gebieden niet tegelijkertijd mag kunnen zien, omdat de rendering anders gewoon compleet de soep in loopt. Overigens werden dit soort dingen in de praktijk nauwelijks gebruikt (is ook lastig te authoren in een 2d map editor) en greep men over het algemeen gewoon naar de teleport truc.

Wolf3D was daarentegen echt gewoon raycasting, wat ook heel goedkoop te doen is met een grid-based plattegrond zonder hoogteverschillen.

[Reactie gewijzigd door .oisyn op 17 januari 2020 13:37]

[...]
Nee hoor, de technieken van Wolf3D, Doom en Duke3D zijn in feite allemaal verschillend

Het ging mij niet om de precieze implementatie, maar om de beperking dat je geen ruimten boven elkaar kunt zien, dus dat je net als in Doom op ieder punt 1 plafond en 1 vloer hebt, die wel in hoogte kan variëren.

Wolfenstein 3D is veel simpeler dan die twee: alle muren hebben dezelfde hoogte en staan uitsluitend haaks op elkaar, en vloer en plafond worden slechts gesuggereerd (die zijn simpelweg een egaal gekleurde achtergrond).

Leg dan eens de brug uit waar je over loopt voordat je het einde van level 1 bereikt? De brug waaronder de achter ingang is van de bioscoop.

Alweer zo'n 20 jaar geleden dat ik iets met de Build editor heb gedaan, maar zo uit mijn hoofd waren dat sprites en maakten dus geen deel uit van de daadwerkelijke geometrie van de map. Dat was een mooie oplossing om rond dat soort beperkingen heen te werken.

Aah idd sprites met collision dus..

Klopt waren inderdaad sprites. Veel voertuigen in maps werden ook met sprites gebouwd: meen me nog een brandweerwagen te herinneren. Het effect van belichting werd veelal bereikt met palettes ION Maiden anyone?

Het ging mij niet om de precieze implementatie, maar om de beperking dat je geen ruimten boven elkaar kunt zien

Ja het kernpunt dat ik wilde maken is een beetje verstopt geraakt in mijn post, maar het gaat er dus om dat het in Doom zowel visueel als geometrisch niet mogelijk is, terwijl het in Duke3D visueel niet kan maar geometrisch wel. Maar goed, je zou je af kunnen vragen wat de toegevoegde waarde is van de geometrische mogelijkheid als je visueel nog steeds een probleem hebt, terwijl de geometrische beperking ook prima is op te lossen met teleports (wat ze in Duke3D ook vaak genoeg doen). Het ziet er alleen een beetje raar uit op de in-game map.

Hoe werkt dat met de bioscoopzaal? Vanuit de projectieruimte kon je door het raam de lager gelegen zaal zien en naar beneden springen. Was dat dan een andere map die geladen werd tijdens het omlaag vallen?

Volgens mij weleens iets gelezen over dat er ook een kromme gang was waarbij je meer dan 360 rond liep. Geen idee hoe dat zat. Leuke dingen om over te lezen.

Hoe werkt dat met de bioscoopzaal? Vanuit de projectieruimte kon je door het raam de lager gelegen zaal zien en naar beneden springen. Was dat dan een andere map die geladen werd tijdens het omlaag vallen?

Nee, dan blijf je in dezelfde plattegrond. Binnen een plattegrond kunnen verschillende hoogten van de vloer en het plafond bestaan, net als in Doom, daar kun je ook van een platform afspringen.

En die wenteltrap naar de projectieruimte is zo'n gang waarbij je meer dan 360 graden rond loopt, maar dan ga je in iedere deelplattegrond dus ook naar boven. Zoiets zou ook gelijkvloers kunnen, dan heb je dus iets dat in de echte wereld helemaal niet kan bestaan

Dus mbv teleport?

De truc was dat er verschillende "maps" waren die overeenkwamen met verdiepingen.

Dit is niet (helemaal) juist. De maps konden gewoon boven elkaar liggen, alleen moest de level ontwerper er voor zorgen dat je nooit tegelijk de boven elkaar liggende sectoren kon zien. Je kon dus nooit twee ramen boven elkaar hebben, maar als de ramen ver genoeg uit elkaar zaten kon je wel op 2 verdiepingen tegelijk kijken.

Waar jij het over hebt, het teleporteren, werd gebruikt voor liften waarbij je aan dezelfde kant in en uit kon stappen (wat effectief 2 'ramen' boven elkaar zou zijn) en wanneer je van boven naar onder water ging (en vice versa) waardoor het bijvoorbeeld mogelijk was dat je over de duikboot kon lopen, in het water kon srpingen, en vervolgens onder de duikboot door kon zwemmen.

Dit is niet (helemaal) juist. De maps konden gewoon boven elkaar liggen, alleen moest de level ontwerper er voor zorgen dat je nooit tegelijk de boven elkaar liggende sectoren kon zien. Je kon dus nooit twee ramen boven elkaar hebben, maar als de ramen ver genoeg uit elkaar zaten kon je wel op 2 verdiepingen tegelijk kijken.

Ik denk dat je het niet helemaal hebt begrepen. Als je in Duke Nukem 3D twee ramen "op verschillende verdiepingen" ziet, zoals de doorgang naar de lobby en het raam van de projectieruimte, (zie https://www.mobygames.com...nshots/gameShotId,700150/ )
dan is er gewoon sprake van 1 plattegrond, net zoals in Doom; de projectieruimte is daar geen verdieping boven een andere, maar is gewoon een deel van de plattegrond met een verhoogde vloer en een verlaagd plafond.

[Reactie gewijzigd door Brousant op 17 januari 2020 14:36]

Ik denk dat jij het niet begrepen hebt

Misschien verward het praten over een hypothetisch level een beetje. Mijn punt is dat het helemaal niks met teleporteren te maken heeft. Een map in DukeNukem kan, in tegenstelling tot Doom, gewoon overlappen. Er kunnen 2 sectoren op dezelfde plek liggen. Randvoorwaarde is echter dat je de 2 sectoren nooit tegelijk kan zien. Dan gaat alles lopen glitchen.

Wat wolfenstein deed is op een 2d map een intersectie berekenen en die dan als fake 3d tekenen.

Klopt. Dit is een tof artikel waarin de techniek die Wolfenstein gebruikt wordt toegepast op een raycasting demo van slechts 265 regels JavaScript: http://www.playfuljs.com/a-first-person-engine-in-265-lines/

Ik heb hier het eerste level van Wolf3D in Javascript, inclusief alle deuren en secrets (maar zonder entities, en slechts een zeer beperkt aantal muurtextures): https://oisyn.nl/wolfjs. Was ook meer een proof of concept dat dat kon in HTML4, want het gebruikt verticale stroken van <img> elementen die geresized worden aan de hand van de diepte van de muur op die plek .

Het grappige is, ik heb de code from scratch ingetypt, maar de implementatie van de deuren en de bewegende muren bij de secrets krijgen exact dezelfde artifacts bij de originele Wolf3D als je je niet aan de restricties houdt, zoals een duur die niet tussen twee muren inzit en je dus van de zijkant kan bekijken terwijl hij open/dicht gaat, of een bewegende secret wall waar je omheen kunt lopen en dus van de zijkant kan bekijken ipv alleen van je af ziet bewegen.

[Reactie gewijzigd door .oisyn op 17 januari 2020 13:27]

Scherp van je! Ik sloop de verwijzing naar Wolfenstein uit de tekst.

EDIT: Ik heb de verwijzing teruggezet, maar met nuance ('soort van raycasting') en een link met uitleg over de implementatie

[Reactie gewijzigd door AverageNL op 17 januari 2020 13:58]

Aan het einde van level 1 loop je toch over een brug?

Om eerlijk te zijn viel de reflectie me op het eerste oog niet eens op omdat ik zo gewend ben aan het zien van realtime computer graphics met alleen screen space reflrections... Realtime raytracing (of AI ondersteund ray-casting en filtering tot de uiteindelijke render dankzij machine learning) voegt niet zo heel veel toe; voor mij iig te weinig om weer een investering van 700+ euro te verantwoorden.

Het geniepige is ook dat Nvidia altijd de vergelijking zoekt met oude technieken.

Ze vergelijken niet HBAO+ versus Raytracing, nee, ze pakken SSAO.
Ze maken geen vergelijking tussen Raytracing en het momenteel beschikbare, maar tussen Raytracing en een scène zonder enige moderne techniek.

Dat is alsof je een iPhone tegen een Nokia uit 1990 benchmarkt, en jezelf dan op de borst klopt.

Allemaal hartstikke leuk hoor, dat ray tracing. Het zal in de toekomst zeker niet meer weg te denken zijn: het wordt er allemaal mooier op. En technisch gezien natuurlijk gewoon een knap staaltje vooruitgang. Ook begrijp ik dat ze ergens een start moeten maken om het op de consumentenmarkt te brengen en de mensen enthousiast moeten krijgen voor deze techniek, maar laten we eerlijk zijn: op dit moment is het (voor de gemiddelde gamer/consument) gewoonweg totaal niet interessant.

Op dit moment zijn er slechts een handvol games die wat leuke 'verbeteringen' in graphics laten zien op je beeldscherm op basis van ray tracing. Tegen een reductie in prestaties van heb ik jou daar, dat dan weer wel. Ik weet dat er meer games aankomen (en ja, de PS5 en Xbox Series X krijgen ook ray tracing mogelijkheden), maar vergeet niet dat de RTX serie inmiddels alweer 15 maanden op de markt is. Tot nu toe ben ik totaal niet onder de indruk van het aanbod aan games of andere toepassingen voor ray tracing.

Ieder zijn mening natuurlijk, maar als ik voor mijzelf spreek: ik had liever wat meer prestatie upgrades gezien van de nieuwste videokaarten in plaats van de (overig kunstmatig gefabriceerde) 'hype' rondom ray tracing (wat trouwens netjes de aandacht heeft afgeleid van het gebrek aan prestatie upgrades die verwacht werden na een R&D periode van meer dan 3 (!) jaar).

Ik vermoed dat de RTX 2000 line-up van NVidia snel achterhaald zal zijn: ray tracing is nog volop in ontwikkeling, en binnen afzienbare tijd is waarschijnlijk veel meer mogelijk met deze techniek dan wat er nu kan (ik reken op een exponentiële groei). Dat zal de huidige generatie RTX kaarten simpelweg niet gaan trekken.

Ik zet mijn geld op de RTX 4000 series, voorlopig blijf ik persoonlijk liever bij een GTX modelletje

Computers kunnen namelijk niet het pad van elke foton uitrekenen. Ze beschikken gewoonweg niet over genoeg rekenkracht om dit binnen redelijke termijn te doen.

Voor de grap even ge-googled. Per oog (edit: absorberen we) 10^16 fotonen per seconde oftewel 20 000 000 000 000 000. Vergeleken met de later in het artikel genoemde ~8,3 miljoen rays (ik neem aan per frame?) dus 498 000 000 rays per seconde. Dus 0,0000025% van de vereiste berekeningen voor 1 ray = 1 foton?

Heb altijd een hekel aan die tech/bio vergelijkingen maar je moet wat om 7 uur.

Overigens begrijp ik dat Octane verhaal aan het einde niet? Ik dacht dat Octane een CUDA renderer was en een NVIDIA gpu een vereiste is?

[Reactie gewijzigd door d.jvan op 17 januari 2020 08:34]

Zoals @Gé Brander aangeeft gaat het inderdaad om het aantal pixels op je computer. De vergelijking met fotonen was puur ter illustratie. Het stuk dat je quote ging eigenlijk alleen over de ontelbare rays/fotonen die niet daadwerkelijk je oog bereiken, maar in plaats daarvan een volledig andere kant op schieten. Het zou zonde zijn om die ook mee te berekenen, aangezien je daar niets van merkt. Dat wordt in de zinnen daarna ook uitgelegd.

Om het stukje over rays per seconde wat aan te duiden: de 8,3 miljoen rays in het artikel ging specifiek over Quake II RTX, zoals ook staat beschreven. Die game schiet minimaal vier rays per pixel af. Op full-hd is dat (1920*1080)*4 = ongeveer 8,29 miljoen rays voor het volledige beeld. Als je de game in 4K speelt is dat (3840*2160)*4 = ruim 33 miljoen rays.

Het aantal rays per seconde hangt af van de framerate. Met een RTX 2080 Super op 4k haalde ik op de redactie ongeveer 20fps, wat zou neerkomen op ongeveer 660 miljoen rays per seconde.

Voor Octane is inderdaad een Nvidia-gpu vereist. Dat gedeelte van de tekst was puur om aan te tonen dat raytracing in de laatste jaren een stuk bruikbaarder is geworden. Ik snap overigens dat de vergelijking met de Turing-architectuur verwarrend is. Ik scherp dat iets aan zodra ik op de redactie ben!

EDIT: wijziging mbt Octane is doorgevoerd!

[Reactie gewijzigd door AverageNL op 17 januari 2020 08:27]

Ja sorry mijn quote en reactie waren erg slecht verwoord, en de vergelijking sloeg toch nergens op. 10^16 fotonen is hoeveel we er absorberen per seconde als we de lucht in kijken en ik vergeleek dat direct met hoeveel rays we de scene in sturen. Leek logisch maar klinkt stom nu ik terugkijk.

[Reactie gewijzigd door d.jvan op 17 januari 2020 08:40]

Gaat het niet om pixels op je computer? Je scherm geeft een beperkt aantal pixels weer. Dus hoeveel fotonen is dan toch niet zo heel erg belangrijk?

Ook wel enigszins belangrijk. Want als je maar 1 sample per pixel hebt dan ga je heel veel noise krijgen.

Of je namelijk net op de rand van een object kijkt of er net naast maakt bij eenvoudige rendering al veel uit (denk aan hoe een draadgaashek er in oude games uit ziet in beweging, en/of moire patronen) en daar is er in weze maar ray die uit de camera de wereld in geschoten wordt op een object. Bij modernere rendering met o.a. raytracing maar ook al met sphere/cubemapped reflecties, zijn er meer rays/bounces en dus meer onvoorspelbaarheid.

Zie het als een slingerende pendule. 1 slinger valt goed te voorspellen met antialiasing of mipmaps, maar als je 3 slingers aan elkaar hangt maakt een klein verschil in de beginsituatie heel veel uit voor het eindresultaat van de laatste ray of slinger. Dus is het belangrijker om meerdere rays in de wereld in te schieten en daar het gemiddelde van te nemen.

Het gaat niet zozeer om het aantal fotonen dat je oog raakt, maar het pad dat zo'n foton aflegt en wat het raakt (hoeveelheid bounces). In het echt gaat licht namelijk van de bron naar je oog, maar in ray tracing begint men in principe bij het oog en rekent dan terug. (bovendien gedraagt licht zich onder bepaalde omstandigheden weer als golf, dus moet het sowieso benaderd worden).

[Reactie gewijzigd door Zoijar op 17 januari 2020 08:15]

Sowieso is licht dat op je netvlies land zelden 1 foton, het licht dat je detecteert met je ogen (of met en camera) bestaat uit vele fotonen zoals hierboven genoemd. Elke foton legt een (iets) ander pad af, daarom is 1 foton simuleren nooit voldoende. Neem het simpele voorbeeld van glas enkele fotonen worden gerefelcteerd terwijl andere worden afgebogen maar wel door het glas komen. En dit is inderdaad allemaal nog los van het golfkarakter van licht, dat laaste wordt bij raytracing niet eens meegenomen.

Inderdaad. Dan kom je ook al snel op sampling. Een van de lastigste dingen in ray tracing is eigenlijk anti-aliasing/sampling. Als je detailed geometry in de verte ziet, dat bv 10x10 pixels is, zou je met 100 rays een grote shimmering mess krijgen omdat je eigenlijk gewoon random dingen raakt. (bv cone tracing)

[Reactie gewijzigd door Zoijar op 18 januari 2020 13:14]

Stel dat enkele fotonen neerkomen op de grote steen in het grasveld. De steen interacteert met de fotonen door ze te weerkaatsen. Hoe de steen dat doet, ligt onder andere aan het materiaal, de textuur en de vorm van de steen. Misschien is hij glad en reflectief, waardoor de fotonen naar een nabijgelegen boom en vervolgens verder worden weerkaatst. Deze weerkaatsingen gaan door totdat de fotonen al hun energie hebben verloren. Intussen worden alle gebieden verlicht waar de fotonen terechtkomen.

Het zal duidelijk zijn dat fotonen sommige plekken in een omgeving indirect bereiken. In het echte leven zijn plekken in de schaduw niet pikzwart, maar grotendeels zichtbaar doordat licht via weerkaatsingen er alsnog een weg naartoe heeft weten te vinden. Deze plekken zijn donkerder doordat de fotonen tijdens hun pad wat van hun energie hebben verloren. Dit is simpel gezegd hoe licht in de natuur werkt.

Jammer dat de auteur weinig snapt van hetgeen hij probeert uit te leggen, want dit is absoluut niet hoe licht in de natuur werkt. Fotonen met minder energie "geven niet minder licht", als een foton minder energie heeft dan schuift de kleur op naar rood (en daarna richting infra-rood etc, tot buiten het visuele spectrum). Plekken die donker zijn worden of nauwelijks bereikt door fotonen waardoor er weinig fotonen weerkaatst worden richting de kijker, of ze absorberen gewoon heel veel fotonen (ook wel bekend als "zwart").

Zoals er ook staat boven die alinea: deze uitleg is 'versimpeld' om de leesbaarheid van de tekst te vergroten. Bovendien staat nergens in de geciteerde tekst dat fotonen met minder energie minder licht geven, alleen dat ze tijdens hun pad energie verliezen, wat ook zo is:

Deze plekken zijn donkerder doordat de fotonen tijdens hun pad wat van hun energie hebben verloren.

Maar die quote is precies wat fout is. Een plek is donkerder omdat er of *minder* fotonen op terecht komen (schaduw) of omdat er veel fotonen worden geabsorbeerd (zwart) of beiden.
Het enige effect van het verliezen van energie is dat de golflengte (kleur) veranderd,

Daar heb je inderdaad gelijk in! Ik zal die zin direct aanpassen. Volgens mij is het dan verder opgelost

Dank!

Ik mis de nadruk op denoisen en de tensor cores, die eigenlijk helpen om met neurale netwerken het beeld sneller te denoisen. Dat is Nvidia haar oplossing geweest om nu al real-time raytracing te verkopen.

Begin jaren ‘90 was ik aan het hobby’en met POVRay en een eigen simpele raytracer (met TI coprocessor naast m’n 386SX ). Toen dacht ik dat we binnen 20 jaar fotorealistische games met real-time raytracing zouden hebben. Little did I know... Games zijn onvoorstelbaar veel mooier geworden, maar het zal nu ook nog zeker wel 10 jaar duren voordat raytracing de norm is en realitische belichting, reflecties en schaduwen vrijwel ‘gratis’ zijn. Ben benieuwd.

En dan gaan we straks weer een stap terug omdat we overgaan op VR waarbij alles twee keer berekend moet worden, beide ogen vangen het licht namelijk onder een andere hoek :-)

Dat het 2x gterenderd moet worden is denk ik niet zo'n punt.
Je verliest wel wat aan 'set-up' van de twee kijkpunten, maar het renderen zelf is redelijk lineair. Je kunt dan denk ik beter kijken naar de totale hoeveelheid pixels en niet zozeer naar het feit dat het twee losse plaatjes zijn.
Wat VR zo lelijk maakt is denk ik de totale resolutie (beide ogen samen) x lage latency x hoge framerate.

Waar, maar er is ook een andere oplossing. Als we werkelijk een goede head tracking hebben plus een goede eye tracking en we de beelden vlak bij of in het oog kunnen projecteren, dan hoeven we helemaal niet zoveel pixels meer te renderen. Het oog ziet namelijk alleen maar in een heel klein stukje van het netvlies scherp.

Head tracking werkt al aardig, de truuk zit hem dus in een goede real time eye tracking. Als dat werkt dan hoef je maar een heel klein deel van het beeld van beide ogen met hoge resolutie te renderen. Hier wordt door diverse bedrijven aan gewerkt.

Google maar op Foveated Rendering.

Ook leuke herinneringen aan POVRay. De universiteits-servers overuren doen draaien met dat ding
Ik herinner me vooral een Rolls-Royce (dacht ik) die ik verschillende keren getraced heb met veranderende oog- en lichtpunten. Die heb ik nog een hele tijd als achtergrond op mijn desktop gehad.

Daarna werd het stil rond raytracing en om eerlijk te zijn dacht ik dat die techniek al lang gewoon standaard in grafische kaarten zat en er daarom niet meer over gesproken werd. Blijkbaar dus niet. Leuke ontwikkeling.

Ik moest idd ook gelijk aan POV denken... Maar dan de versie die ooit stond op de diskette van een Atari ST tijdschrift (ST Format of ST User?) met wat simpele voorbeelden. De arme 8mhz 68000 zonder FPU was zo een etmaal bezig met de simpelste modellen te bereken in een 320x200 resolutie met 24 bit kleuren. Het resultaat was dan te bewonderen in een speciale viewer die met wat truukjes het in 512 (RGB) kleuren (ipv 16) te voorschijn toverde. Maar dan hebt je het ook inmiddels over 25 jaar geleden

Klopt, een beetje plaatje kostte al gauw een etmaal om te renderen. En voor het viewen en converteren van plaatjes gebruikte ik toen Graphics Workshop: https://archive.org/details/msdos_GRFWK61V_shareware. Dat was ook super om hoge kwaliteit dithering toe te passen als je iets graphics op een printer wilde afdrukken. Overigens was die 24-bit RGB naar 8-bit palette conversie ook vrij intensief, dus na het geduldig wachten op de raytracer was je er nog niet

Overigens, kijkend naar je nickname: mijn eerste computer was een Atari 600XL in 1985

[Reactie gewijzigd door Exirion op 17 januari 2020 13:28]

Met een 320x200x16 resolutie ziet dithering in kleuren er niet geweldig uit... Later heb ik het nog wel eens voor JPG conversie gebruikt... het converteren kostte dan al gauw een uurtje op de ST. Handiger was het dan om het dan bv naar grayscale te converteren. Als ik het me goed herinner was de output van POV mogelijk in een RAW 24 bit formaat... Wat met een eigen gemaakt tooltje in GFA Basic dus heel makkelijk en snel te converteren was. (Eventueel met simpel dithering om van 8 grijswaarden naar bv 15 te gaan)

Overigens : 1e eigen computer tweedehands ZX81 die direct stuk was... daarna Atari 800XL , MSX en toen dus een tweedehands Atari 520ST die eerst weer terug moest voor reparatie, maar het daarna lang gedaan heeft en die uiteindelijk nog ingewisseld is voor een 1040STfm met 60Mb HD (waarmee pas het volle potentieel te benutten was) Daarvoor had ik op school toegang tot de toen al antiek wordende TRS80 (model 3 en 4) en de good old Acorn BBC. Beide uit een tijdperk dat computers echt nog bijna onbetaalbaar waren. Een oom had een paar jaar ervoor al een zelfbouw Acorn Atom... waar mee mijn interesse in computers onstond.
De naam was dus een beetje eentje met een knipoog... zo van in mijn tijd hadden we ook al flame wars over wat de beste computer was... way back in the 80s (Fun fact : Je kunt de Atari ST als opvolger van de C64 beschouwen en de Amiga van de Atari 8 bit)

Ik zette een render in gang op een 386sx voor ik ging werken, bij thuiskomst was het plaatje dan klaar

Heb je toen overwogen om een floating point unit er bij te zetten? Of had je die al ? Ik heb geen flauw idee wat dat toen kostte... een 386sx was veel te prijzig voor mij... De Atari ST heb ik ooit een hele zomer vakantie gewerkt in 1989 toen deze ongeveer de helft kostte tov een heel erg basic PC XT.

Ja ik heb hem later vervangen door een dx2-66 met fpu maar toen kwam eerst doom en daarna quake 1 uit en ben ik povray glad vergeten

[Reactie gewijzigd door StGermain op 18 januari 2020 11:59]

O ja dat was natuurlijk een stuk handiger.. De 386 vervangen door een 486.

Zolang ze de 'alles is een spiegel' mentaliteit houden bij het design zal het nooit realistisch worden.

Ik denk dat ze maar even bij de film industrie op bezoek moeten Maar ik verwacht dat mensen uit die markt nog meer in de games gaan werken.

Precies, die zijn net zo erg zo niet erger. Vooral met zaken als massa, zwaartekracht, momentum en overacteren met motion capture. Lijkt soms wel of ze het er om doen. Die brug spring scene in 1917 zakt mijn anno 2020 broek gewoon van af. Of de stormtroopers op de gliders die een gesprekje houden in Mandalorian.
(Zeg maar de power ranger acteer stijl. Want als je een gezicht niet kan zien gaan mensen opeens allerlei extreme gebaren en bewegingen maken.) Half Hollywood heeft zijn kamp diep in de uncanny valley opgezet.
Om over sound engineers maar te zwijgen.. </rant medicijn="maxDosis">

Dat, hoe vaak zie je in het echte leven een auto die zo goed gepoetst is?

Ik minimaal 2 keer per jaar, ik wax ze dan met de hand met Turtle wax uit blijk

En na een dag glimt die ook niet meer zo als de auto uit het plaatje in het artikel

ik denk idd dat raytracing de toekomst heeft ,net zoals je zegt alles is realistischer en beter.
ik heb vroeger ook met povray iets gemaakt samen met mijn vrienden,en het zag er toen al veelbelovend uit.
En omdat videokaarten nu al realtime dit kunnen weergeven vind ik prachtig.
We waren meer dan 8 uur aan het wachten voordat een voorstelling klaar was.Voordat alles gerenderd was.

Ik zie in veel situaties dat realtime raytracing het net wat mooier maakt, maar valt me wel op dat het meteen vaak overdone is. Water partijen zijn standaard spiegels, alles lijkt ineens op een spiegelend oppervlak. Ik weet niet hoe het met de rest zit, maar mijn echte wereld spiegelt toch aanzienlijk minder

Dat vind ik dus ook. Vooral bij schaduws kan ik mij daar aan ergeren: Ze zeggen dat de schaduw van bijvoorbeeld een boom met raytracing nu heel scherp is en dat klopt ook, het is gewoon een grijze/zwarte kopie van de boom. Gaat de raytracing uit is de schaduw wat vager en niet zo scherp. Nu woon ik niet in de woestijn en kom ik regelmatig bomen tegen en die schaduw is toch echt niet zo scherp als ze ons willen laten geloven via raytracing

Schaduwen zouden met raytracing toch juist minder scherp moeten zijn? Dat is namelijk lastig te realiseren bij rasterization.

https://news.developer.nv...nd-denoising-712-minutes/

[Reactie gewijzigd door DohnJoe op 17 januari 2020 11:14]

Precies mijn punt. Kan het betreffende filmpje niet meer vinden helaas maar vond wel veel vergelijkings filmpjes waarin RT aan een betere/mooiere schaduw geeft dan wanneer RT uit staat. Filmpje waar ik op doelde was kort na de BF:V release. Misschien hebben ze bij het editen de beelden verwisseld/door elkaar gehaald. Ik volg heel het RT verhaal niet echt dus ik zal ook vast wel wat achterlopen.

Apple is ook bezig met de ontwikkeling van raytracing in Metal.

https://developer.apple.com/videos/play/wwdc2019/613/

Wat ik alleen nog mis in dit artikel is munnen we nu ook gebruik maken van rtx voor hit detectie en dit offloaden naar een rtx core. Vilgensmij kan dit geziet dat ook gewoon een path trace of box trace is. Momenteel zijn we als game maker daar zuinig mee omdat het je performance kost maar met aparte rtx hardware zou je dus ook veel betere detecties kunnen doen omdat je niet meer zuinig hoeft te zijn met je traces.

"Raytracing maakt dan ook gebruik van een soort lichtstralen, maar anders dan in de natuur, komen ze als het ware vanuit een oogpunt (...) op objecten terecht"
Dat doet denken aan hoe rond 400 voor Christus de Griekse filosoof Plato veronderstelde dat het oog werkt, met een soort stralen die vanuit het oog op objecten vallen. Die theorie werkt nog steeds door in de taal, zo kun je "je oog op iets laten vallen".
Zie https://en.wikipedia.org/wiki/Emission_theory_(vision)