IDF: Intel toont raytracing-versie van Wolfenstein

Intel heeft op de IDF een versie van het spel Wolfenstein gedemonstreerd waarbij de graphics met raytracing worden gerenderd. De berekeningen worden door een viertal servers uitgevoerd, waarna de beelden naar een client worden gestuurd.

Met de aangepaste raytracing-engine kunnen erg realistische beelden worden geproduceerd, maar wordt ook veel rekenkracht vereist. Om die capaciteit te leveren maakt Intel gebruik van een opstelling waarbij de beelden worden gerenderd op een aantal servers om daarna naar een client te worden gestreamd. De gamingdienst OnLive gebruikt een vergelijkbaar concept om gaming op minder krachtige hardware mogelijk te maken.

De vier rendermachines zijn niet voorzien van traditionele videokaarten, maar maken gebruik van Intels Knights Ferry-platform. Hierbij bevat een enkel pcb een groot aantal x86-cores; de technologie is gebaseerd op Intels geannuleerde Larrabee-videokaart. De multicore-opzet maakt de hardware bij uitstek geschikt voor raytracing, dat zich immers goed leent voor parallellisme. Gezamenlijk weten de machines de gamebeelden met een framerate van 80fps te renderen op een resolutie van 1280 bij 720 pixels. Vooralsnog gaat het puur om een demonstratie van de technologie; Intel heeft momenteel geen plannen om Knights Ferry geschikt te maken voor de consumentenmarkt.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (56)

[max3D]

Fascinerend om te zien, maar totaal uit sync met de werkelijkheid natuurlijk. We praten hier over zeg 80fps op een ´magere´ 1280x720 res die compressed iets van 0,5 MB zullen zijn als je die kwaliteit wil, maar doe de math en je praat over 40MB/sec. Let op de hoofdletter B! Wie ziet het voor zich dat hij zijn nieuwste spel over een 40GB lijn speelt? En je vriend thuis uitnodigen voor een potje vereist wordt dan lastig. De demo was niet voor niets in Intel´s research lab....

Nee, dit is puur een vrij onzinnige demonstratie van Larrabee´s GPU killer, die zelf gekilled werd omdat hij niet opgewassen was tegen het ATI/Nvidia geweld. Nu heet ie ´Knights Ferry´ of in de volgende revisie ´Knights Briidge´ of MIT. Whatever: Larrabee zonder video output zeg maar.

Intel moet iets hebben om de GPU processing van zich af te slaan. Veel ontwikkelaars staan voor de keuze welke co-processor ze zullen ondersteunen (ja, co-processors want zo noemden we vroeger fpu accelerators dus waarom zouden we het woord niet weer gebruiken. Ik verdiende mijn eerste geld met de import van razendsnelle Weiteks!).

Ze kunnen kiezen voor ATI = OpenCL. Prestaties onder de maat en OpenCL is een onvolwassen platform. Voor Nvidia met zijn mega core units 512 op de laatste GTX + CUDA dat veel verder ontwikkelt is en oh ja, Intel wil niet vergeten worden dus Larrabee 2 + en Direct Computing als combi.

Intel wil natuurlijk alles doen om met name de Nvidia opmars in co-processors tegen te gaan. De Tesla´s (dedicated co-procs gebaseerd of de GF10x techniek van de grafische kaarten) zijn waanzinnig snel en hebben een berg geheugen voor professioneel gebruik. Niet voor niets dat sommige grote computer graphics studio´s (ILM, Zeta etc) overstappen naar CUDA renderfarms en hun 2000+ Intel CPU´s gaan dumpen.

Van ATI hebben ze niet zoveel meer te duchten. Nu AMD die bezit hebben Intel en AMD hetzelfde probleem: ontwikkel een goede GPU processor en je kannibaliseert je eigen CPU verkoop. Wie wil er een multi core Bulldog hebben als hij voor 200$ een veel groter aantal cores kan kopen uit de gamekaart serie.

Dus Intel heeft voor een klassieke Intel core gekozen (een hele oude P54 als ik het me goed herinner) en die opgenomen in een multi core bus ring ontwerp dat nu op 32 zit, maar met wat die shrinks naar 50+ zal gaan.

Toffe keuze voor developers die houden van klassieke ISA based programming (lees niet zo goed zijn en graag doen wat ze altijd al doen) en het helpt natuurlijk als je marketing centjes van Intel krijgt. The best of both worlds: met hulp van VTune maximum parallelisme uit je applicatie krijgen wat je toch al moest voor de multi core CPUs, even recompilen voor de Larrabee wannabee en nog geld toe om niet zoveel moeite te hoeven doen. Tel uit je winst.

Vandaar dat alle Larrabee 1´s nu naar developers gegaan zijn als Knights Ferry ontwikkelkit. Leuk om vast mee te spelen.

Daarnaast moet Intel iets laten zien om iedereen warm te krijgen voor de spectaculairee performance mogelijkheden en hier komt de crux waarom ze nu ´Wolfenstein de raytrace versie´ demonstreren op de IDF.

Intel stopt al vele jaren veel geld in hun eigen raytrace techniek omdat raytracing als moeilijk implementeerbaar op multi core Nvidia like cores beschouwd wordt. Het is dé videorendering techniek (tov van de vele andere die in spellen en professionele toepassingen gebruikt worden) die enorm graag op een CPU draait en wat is Larrabee is: een bunch of X86´s. (heel veel meer eigenlijk, maar voor het principe houden we het bij deze simplificatie).

Ziedaar deze ogenschijnlijk nutteloze demo. Goed voor de stockholders die overtuigd worden dat Intel on top of GPU achtige oplossingen zit, goed voor aarzelende developers die bang zijn om het vertrouwde x86 platform te verlaten en zo hoop houden dat hun app niet ten onder zal gaan aan de nieuwe startup´s die vanaf het begin gefocussed zijn op GPU only (meestal CUDA only) oplossingen en daar fantastische resultaten mee boeken.

en p.s. waarom kon Intel niet vier Larrabee´s in één doosje kwijt? Je prikt zo 4xGTX480 in een simpel doosje en Intel´s special development lukte het niet om voor een cruciale IDF presentatie dit te bereiken. Bij Larrabee´s ontwerp niet goed nagedacht?

Wie per se dit rare Wolfenstein raytrace zou willen spelen zal toch liever een stevige machine in het server hok zetten en dan intern een pijp van tig GB leggen ipv te vertrouwen op 4 remote servers over een dedicated glasvezel lijn naar Intels HQ.

en p.s2 voor wie dit niet helemaal begrijpt en denkt dat hij al zo iets gezien heeft: dat kan. Immers half life 2 bijvoorbeeld gebruikt ook raytracing en oogt zo snel als deze demo, maar dan op een gewone CPU: Dat is echter een software only renderer ipv een hardware assisted versie. Dus nee, Intels hoge inzet op nu juist raytracing als de showcase voor Larrabee like toekomstige co-processors is niet zo spectaculair, hoewel Half Life 2 niet een miljoen polygonen in een kandelaar stopt, maar wie wil dat?

edit: ik bedoel dus niet te zeggen dat HL2 in game RT gebruikt. Ongelukkig geformuleeerd. De level editor doet het en de rest zijn in software getructe RT achtige effecten die door veel mensen als RT gezien worden en in de praktijk vrijwel dezelfde mogelijkheden bieden als in het fimpje van Intel nu getoond worden.

en de laatste ps: wie dit voor professione toepasingen wil: cloud computing voor graphics kan de Mental Images Reality server gebruiken. Vrijwel onbeperkt schaalbare toegang tot bergen dedicated CUDA cores met lokale preview etc. Al veel verder ontwikkeld en gewoon bruikbaar.

Reacties op de commentaren:

@ leuk_he dank voor het compliment. Ik vergat helemaal niet dat dit een onderzoeksproject is; dat is juist Intel´s fail. In ´96 kondigden ze aan dat we binnen vijf jaar op 80cores zouden zitten. Zie Otellini hier met de die in zijn handen http://techfreep.com/intel-80-cores-by-2011.htm

Developers is nu beloofd dat er volgend jaar shipping versies zullen zijn van de Knights Bridge architectuur die nu gedemonstreerd werd. Niet over vijf of tien jaar.

@biebbiefGTR: zeldzaam irrelevante opmerking. Ik zou er niets van weten

@yopie: je hoeft mij het verschil tussen een Gpu en een Cpu niet uit te leggen, noch de keuzes tussen de verschillende ´standaarden´. Ik ken ze en noem de gpu´s fp co-processors dat lijkt me nog duidelijker dan jouw tekst. Wat dacht je dat de dode Larrabee was? een universeel inzetbare CPU die Intels hoofdmarkt zou kannibaliseren? Dream on.

Dat jij niet wist waar je een 4 pci-e moederbord vandaan moest halen bij de marktintroductie van de gtx480 zegt meer over jou. Intel zou best een mult-cpu moederbord kunnen bouwen voor de Larrabee, dat kost ze geen miljoenen en het gaat om een markt van miljarden dus.... Nee er zit een probleem in het ontwerp van de Larrabee dit dit verhindert.

De kern is dat intel RT op een CPU stimuleert omdat het de techniek is waarvan men aanneemt dat deze het gemakkelijkst op een general purpose chip kan draaien en natuurlijk prima schaalt met het aantal cores. Vandaar hun inzet op juist dit terrein.

@knirfie244: er zijn veel meer rendering technieken dan dan de drie die jij noemt én de SFX industrie vermijdt juist vaak RT. Kale RT wil al helemaal niemand zien in een film, povray wel eens bekeken? Zie je het voor je?

Dat Larrabee meer is dan een P54 op een ring bus schreef ik zelf ´simplificatie´. Ik ken mensen vanuit de CG industrie die betrokken waren bij het ontwerp en dat waren niet de minste dus er zitten veel slimme extensies in het ontwerp uit de CG praktijk. Vergeet alleen niet dat dit voor ATI en Nvidia ook geldt.

@bazkie_botsauto en anderen: ik weet dat HL2 niet real time op RT draait, maar het is een techniek die gebruikt wordt dus ik dacht door het te noemen de ´ja maar dit kan al´ weg te nemen´. Ik had het beter weg kunnen laten. Zal het editen.´

[Reactie gewijzigd door max3D op 23 juli 2024 08:12]

[YopY]

Fascinerend om te zien, maar totaal uit sync met de werkelijkheid natuurlijk. We praten hier over zeg 60fps op een ´magere´ 1280x720 res die compressed iets van 0,5 MB zullen zijn als je die kwaliteit wil, maar doe de math en je praat over 40MB/sec. Let op de hoofdletter B! Wie ziet het voor zich dat hij zijn nieuwste spel over een 40GB lijn speelt? En je vriend thuis uitnodigen voor een potje vereist wordt dan lastig. De demo was niet voor niets in Intel´s research lab....

1280X720 is een 720p HD stream. Heb je 40 MB nodig om Youtube op 720p te bekijken? Neen. 0,5 MB/frame en de frames als losstaande plaatjes is wel een heel naïeve manier om videobeelden over te sturen (want ja, een spel zoals je dat ziet is gewoon een interactieve video, als je het lekker abstract bekijkt).

Intel moet iets hebben om de GPU processing van zich af te slaan. Veel ontwikkelaars staan voor de keuze welke co-processor ze zullen ondersteunen .

Beetje abstracter, ze moeten kiezen welke GPGPU techniek ze gaan gebruiken - NVidia's CUDA, AMD's STREAM, OpenCL, of DX11's DirectCompute. DirectCompute en OpenCL zullen bijvoorbeeld ondersteund (moeten) worden door de GPU fabrikanten. Dat de ondersteuning voor elke techniek zal wisselen is wel bekend - zie ook bijvoorbeeld DX 9, 10 en 11 en OpenGL.

Ik denk overigens ook niet dat Intel met deze technologie direct kan concurreren met de GPGPU's - die zijn nl gespecialiseerd in het verwerken van floating points, terwijl een cluster X86 cores general purpose zijn. Ze zullen dus een bredere hoeveelheid taken parralel uit kunnen voeren, terwijl de GPGPU's voornamelijk gespecialiseerd zijn in specifieke rekentaken.

Van ATI hebben ze niet zoveel meer te duchten. Nu AMD die bezit hebben Intel en AMD hetzelfde probleem: ontwikkel een goede GPU processor en je kannibaliseert je eigen CPU verkoop. Wie wil er een multi core Bulldog hebben als hij voor 200$ een veel groter aantal cores kan kopen uit de gamekaart serie.

Omdat je met een veel groter aantal cores nog geen PC kunt laten draaien, . Zoals gezegd, GPGPU's zijn voor specifieke taken (ook al heten ze 'general purpose', ze zijn het niet), terwijl de goeie ouwe X86 nog gebruikt wordt voor De Rest.

en p.s. waarom kon Intel niet vier Larrabee´s in één doosje kwijt? Je prikt zo 4xGTX480 in een simpel doosje en Intel´s special development lukte het niet om voor een cruciale IDF presentatie dit te bereiken. Bij Larrabee´s ontwerp niet goed nagedacht?

Bij tech demo's is het niet zo belangrijk of ze het allemaal in één kastje kunnen proppen. Ze moeten eerst de technologie maar eens uitontwikkelen. Je kon immers ook niet gelijk 4 GTX480's op één bord prikken toen het net nieuw was, laat staan op volle kracht laten draaien - het duurde even voordat moederborden zover ontwikkeld waren. Zelfde verhaal hier, Intel zal geen miljoenen uitgeven aan het ontwikkelen van een chipset voor experimentele technologie zoals dit.

en p.s2 voor wie dit niet helemaal begrijpt en denkt dat hij al zo iets gezien heeft: dat kan. Immers half life 2 bijvoorbeeld gebruikt ook raytracing en oogt zo snel als deze demo, maar dan op een gewone CPU

Neen, raytracing is niet geschikt voor consumenten-PC's, en kan dus niet de primaire rendermethode zijn voor games als HL2. Misschien dat ze een optionele raytrace renderer hebben voor demonstratiedoeleinden. Stuur eens een linkje waar je dit vandaan hebt?

[OddesE]

een spel zoals je dat ziet is gewoon een interactieve video, als je het lekker abstract bekijkt

True, maar je vergeet wel twee belangrijke details:
1) Youtube en andere streaming video wordt gebufferd (en dat kan niet bij een real-time spel) en zelfs dan is het nog niet altijd smooth
2) Video's op youtube zijn van tevoren geencodeerd en dit vergt ook wel flink wat power.

Zomaar spel beelden als een video streamen is dus zo simpel nog niet.

[knirfie244]

Intel stopt al vele jaren veel geld in hun eigen raytrace techniek omdat raytracing als moeilijk implementeerbaar op multi core Nvidia like cores beschouwd wordt. Het is dé videorendering techniek (tov van de vele andere die in spellen en professionele toepassingen gebruikt worden) die enorm graag op een CPU draait en wat is Larrabee is: een bunch of X86´s. (heel veel meer eigenlijk, maar voor het principe houden we het bij deze simplificatie).

Vele andere technieken? Er zijn 3 gangbare (en een aantal niet zo veel gebruikte): Ray Tracing, Ray Casting en Scanline rendering. Casting word veel gebruikt bij games, echter wordt tracing bijvoorbeeld zeer veel gebruikt in de SFX industrie voor films, series, etc.

Dus Intel heeft voor een klassieke Intel core gekozen (een hele oude P54 als ik het me goed herinner) en die opgenomen in een multi core bus ring ontwerp dat nu op 32 zit, maar met wat die shrinks naar 50+ zal gaan.

larrabee is wel heel wat meer als een oude P54 op een ringbus, er is heel wat gestript en toegevoegd, zoals x64 en een 512bit vector unit. Vooral de vector unit is van belang voor het hele concept van Larrabee, en met 16 simultane single precision bewerkingen in elke vector unit haal je behoorlijk wat flops met 32 cores. (32 cores * 16 SIMD * 2flops * 2GHz = 2TFlops)

[Reactie gewijzigd door knirfie244 op 23 juli 2024 08:12]

[OddesE]

Volgens mij gebruikt vrijwel geen enkele commerciele game raytracing omdat het gewoon veel te traag is.

Verder vind ik dit eigenlijk een interessanter project wat render technieken betreft. Een 'vierde render techniek': Unlimited Detail.

[humbug]

Raytracing is inderdaad (nog?) te traag voor games.Tegelijkertijd is iedereen er wel van overtuigt dat raytracing uiteindelijk de mooiste techniek is om grafische effecten mee te doen. Het maakt een hoop van de trucjes die nu gebruikt worden overbodig. Dus als er genoeg performance is voor realtime Raytracing zul je raytracing in games zien verschijnen.

[leuk_he]

Lange goed onderbouwde rant . Waarbij je echter vergeet dat dit slechts een onderzoeksproject op de larrabee spinoff is, en niet bedoeld is voor een daadwerklijk produkt.

Onderzoek dat pas toepasbaar wordt als er over 5 of 10 jaar een larrabee kloon wordt uitgebracht voor consumenten.

[awulms]

Inderdaad. Iets wat nu nog 4 servers vraagt kan over een paar jaar inderdaad in 1 enkele chip worden gepropt, als de miniaturisatie zich in het huidige tempo blijft voortzetten. Het is dus een heel goed initiatief dat de software nu al wordt geoptimaliseerd voor real time ray-tracing zodat als de hardware goedkoop genoeg geproduceerd kan worden, de software bibliotheken ook al beschikbaar zullen zijn.

[Verwijderd]

Iets met "Je hebt een mooie klok opgezet maar weet nog duidelijk niet waar de klepel hangt."
Probeer gerust opnieuw met je onderzoek! Je bent er dicht bij

[Verwijderd]

misschien een beetje muggenziften, maar half-life 2 gebruikt geen raytracing. ja, de map editor wel (soort van), voor lightmap berekening.. maar dat telt niet

edit* yopy was me voor

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:12]

[AmigaPower]

Een mooie toepassing van een aantal onderzoeken die op de universiteit van Saarbrucken zijn opgestart. Daniel Pohl, degene die dit project bij Intel begeleidt, heeft enkele jaren geleden voor die universiteit een raytrace-versie van Quake 3,4 en Wars gebouwd. Het streamen van de gegenereerde beelden naar een thin client is dan een logisch (en als je het mij vraagt niet zo vernieuwend) gevolg.
Op deze wikipagina kun je meer vinden over specifieke raytracing hardware.

[Reactie gewijzigd door AmigaPower op 23 juli 2024 08:12]

[Pmf1971]

Moooie vooruitblik op spelletjes die over een jaar of 5 a 7 op een gewone pc te spelen zullen zijn. Raytracing is the way to go

[Qualian]

Hoop het niet, want ik vind dit voorbeeld er eerlijk gezegd niet uitzien... realistische reflecties en refracties in een spelwereld met schrale textures en onnatuurlijke animaties

Voor een realistischere spelwereld zie ik toch meer in hardware tesselation, goed gebruik maken van particle / voxels, depth of field, motion blur, hi-res diffuse / specular / bump maps etc.... en spiegelingen, breken van licht en andere effecten gewoon goed faken en zorgen dat de belichting in orde is. Gewoon op de hardware die je thuis hebt staan. Tijdens het gamen valt het vrijwel niemand op of een weerspiegeling wel of niet helemaal correct gerenderd wordt, als er maar een acceptabele indruk van een weerspiegeling gegeven wordt en daar zijn ze tegenwoordig naar mijn mening best goed in.

Maargoed, wel interessant voor bijvoorbeeld industrieel ontwerpers die hun product zo realistisch mogelijk willen presenteren en daar budget voor hebben.

---edit---

Oh en schademodellen en physics natuurlijk... zoals voor haar en vacht bijvoorbeeld, daar valt nog veel terrein te winnen. Gezichten kunnen ze met de juiste textures, animaties en belichting al vrij realistisch maken, als ze dat met haar ook nog een keer lukt...

[Reactie gewijzigd door Qualian op 23 juli 2024 08:12]

[paazei]

'Maargoed, wel interessant voor bijvoorbeeld industrieel ontwerpers die hun product zo realistisch mogelijk willen presenteren en daar budget voor hebben.'

Industrieel ontwerpers gebruiken gewoon de renderer uit hun CAD- of 3Dprogramma, die al sinds jaren kunnen raytracen.
Als je de tijd hebt kan elke pc of laptop raytracen, het gaat erom dat het in real-time gebeurd met een redelijke framerate om raytracing geschikt te maken voor gaming.

Oh en schademodellen en physics natuurlijk... hebben niks met de manier van renderen te maken, maar worden door de game-engine of aparte physics engine berekend en dan doorgestuurd als 3d model naar de renderengine. (correct me if I'm wrong).

[Reactie gewijzigd door paazei op 23 juli 2024 08:12]

[Qualian]

En je ziet niet de voordelen van realtime raytracen op het moment dat je iets aan een klant wil laten zien? Lijkt me toch wel voordelen hebben...

Behalve dat schademodellen over het algemeen meer polygonen vereisen heeft dat meestal niet zo heel veel inpact op het renderen denk ik idd... physics ook niet echt, alhoewel het toepassen van physics in sommige gevallen natuurlijk kan vragen om aanpassingen in de modellen die het renderen zwaarder maken, zoals bijvoorbeeld haar dat natuurlijk beweegt... maar het ging mij er meer om dat er andere en betere manieren zijn om beelden in games realistischer aan te laten voelen, raytracing in deze exacte vorm lijkt mij voorlopig nog veel te inefficient om enigzins de moeite waard te zijn voor toepassing in games...

-----
Dit bijvoorbeeld:
nieuws: Sony brengt The Last Guardian eind 2011 uit
Dat noem ik nou realistisch voor wat er op dit moment mogelijk is

[Reactie gewijzigd door Qualian op 23 juli 2024 08:12]

[SideShow]

Ik was mij niet bewust van het feit dat reflectie en refractie nog niet aanwezig was in de huidige games? Ik dacht dus van wel... (?)

[.oisyn]

Dat wordt gefaked, door de scene nog een keer te renderen vanuit het reflecterende of refracterende oppervlak en de pixels vervolgens te distorten aan de hand van een normal map van de surface. Het geeft de illusie dat het daadwerkelijk reflecteert of refracteert, maar in de werkelijkheid klopt het niet helemaal (omdat er nou eenmaal vanuit 1 oogpunt wordt gerenderd, ipv vanuit elk individueel snijpunt met het oppervlak). Niet dat dat verder boeit, de illusie is goed genoeg

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:12]

[Verwijderd]

Mja, inderdaad. De illusie is goed genoeg. Sterker nog, ik vind simpele statische cubemaps als reflecties er beter uit zien dan raytracing aangezien 99% van alle reflecties die je dagelijks tegenkomt erg diffuus zijn, wat bij een cubemap gratis is (zelfs goedkoper dan high res) maar wat bij raytracing veel en veel zwaarder is. De auto uit dit filmpje, hoewel technisch indrukwekkend, ziet er toch erg onecht uit. Het is leuk voor dit soort techdemo's, maar totaal niet interessant vanuit een artistiek oogpunt. Hetzelfde geld voor schaduwen, een shadowmap mag dan ook 'fake' zijn, het ziet er wel veel beter uit dan de harde schaduwen die een enkele schaduw-ray per primaire ray oplevert. Om zachte schaduwen in raytracing the krijgen zal je per primaire ray toch echt meerdere schaduw-rays moeten uitsturen.

Kortom, leuk voor techdemo's met veel glas, chroom en spiegels, maar in echte games voorlopig nog nutteloos. Misschien dat raytracing beter schaalt dan rasterizing en dat er ergens een break-even punt is.

Maar goed, wel een indrukwekkende demo, mijn raytracer haalt net 20 fps in een scene met 10 kubussen op 320x240 op een dual core

[AmigaPower]

Het is inderdaad mogelijk om reflectie en refractie te berekenen in combinatie met rasterisatie, i.p.v. ray tracing. Echter moet het bij rasterisatie als "extra feature" erbij geprogrammeerd worden, terwijl dit bij ray tracing zo goed als automatisch gebeurd.

[BramT]

Eea wordt veel gesimuleerd/gefaked. Wat overigens nog steeds een heel aardig totaalplaatje kan geven.

[Redneckerz]

overigens@max3d: HL2 en zon beetje alle spellen van nu gebruiken ook helemaal geen raytracing, dat is nu juist het frappante aan het nieuwtje. alle games van nu gebruiken Rasterization om alles op te bouwen. Real-Time Raytracing echter, is veel en veel moeilijker om te recreeren, zowel in hardware als in software. daarom is het vooralsnog iets onmogelijks.

neemt niet weg dat dit een leuk voorbeeld is, vooral de reflecties en bollen zijn leuke uitingen van raytracing. zeker aangezien de reflecties geen normal maps en glanstexturen zijn, maar echte reflecties. en tja, dat kost rekenkracht.

tegenwoordig bestaan er wel specifieke real-time raytracers, maar die hebben 1 nadeel: ze kunnen niet goed met textures omgaan. dus voorlopig is het nog toekomst muziek.

maar het is wel impressive:) hopelijk wordt hier ook weer een website van gemaakt.

[bwerg]

daarom is het vooralsnog iets onmogelijks.

En dat blijft het ook, als de game-ontwikkelaars hun prioriteiten niet op ray-tracing leggen maar op andere grafische zaken. Neem bijvoorbeeld een oude, lelijke shooter van jaren geleden. Misschien is het inmiddels, met de rekenkracht die nu in een consumenten-pc zit, best mogelijk om realtime raytracing uit te voeren in dat spel. Dat zal misschien net zo veel rekenkracht kosten als metro 2033 zònder raytracing. Nou mag je kiezen, een lelijk spel maar wel met 100% correcte reflecties, of een mooi spel met zodanig goed gefakede reflecties dat ze ook niet bepaald lelijk zijn en je genoeg rekenkracht overhoudt voor andere zaken die veel meer toevoegen. Place your bets.

Oftewel: raytracing in 3d-simulaties als games wordt pas echt relevant als die programma's zo mooi zijn geworden dat de reflecties echt de lelijkste factor in het geheel is, en ze daar prioriteit aan gaan geven in plaats van het verbeteren van shader models, tesselation etc. Dus de komende 10 jaar niet, en misschien nog veel langer. Vooral ook gezien de rekenkracht die nodig is voor raytracing ook toe zal nemen naar mate het spel voor de rest mooier wordt, en je over 10 jaar met de games van dan nog net zo ver van real-time raytracing af bent als nu met de huidige games of tien jaar geleden met de games van toen (nouja, niet helemaal misschien, maar in grote lijnen telt dat zwaar mee).

[Reactie gewijzigd door bwerg op 23 juli 2024 08:12]

[YopY]

tegenwoordig bestaan er wel specifieke real-time raytracers, maar die hebben 1 nadeel: ze kunnen niet goed met textures omgaan. dus voorlopig is het nog toekomst muziek.

Niet? Lijkt me logisch en redelijk eenvoudig dat een raytracer kijkt welke pixel op het oppervlak dat hij raakt en deze overneemt. Maar ik kan het natuurlijk mis hebben en ray tracing niet begrijpen, .

[Verwijderd]

Lijkt mij inderdaad ook niet zo'n punt, je weet het UV coördinaat van de triangle die je intersect en kan je eenvoudig een texture-lookup doen, lijkt mij. Wat welk moeilijk is bij raytracing voor zover ik weet zijn erg dynamische scenes. Je wilt namelijk niet dat je per ray de hele scene wilt afzoeken (potentieel miljoenen triangles) om erachter te komen met welke triangle de ray intersect, dus gebruik je een datastructuur als een octree om redelijk snel de juiste triangle te kunnen vinden. Maar als er iets verandert in de scene (wat vaak gebeurd in een game) dan moet deze datastructuur gedeeltelijk herberekend worden, wat volgens mij een erg dure operatie is. Ik dacht niet dat dit een opgelost probleem was.

[.oisyn]

Lijkt mij inderdaad ook niet zo'n punt, je weet het UV coördinaat van de triangle die je intersect en kan je eenvoudig een texture-lookup doen, lijkt mij

Zoals ik hierboven al beschreef, de duurheid zit 'm in die lookup, niet het berekenen van de UV coordinaat. De GPU heeft dedicated hardware om gegeven UV coordinaten (of eigenlijk een set van coordinaten, voor meerdere pixels tegelijk - kunnen de gradients ook meteen berekend worden voor mipmapping) meerdere samples (4 voor bilinear filtering, 8 voor trilinear, n*8 voor nX anisotropic filtering) te doen uit een texture en die te filteren. Een CPU moet al die handelingen zelf doen (byte offset in de texture berekenen voor iedere sample afhankelijk van addressing mode, alle samples bij elkaar combineren gegeven de coefficienten, etc.), en elk van die handelingen kost tijd, terwijl de hardware in de GPU dat allemaal tegelijkertijd doet. En niet te vergeten de enorme geheugenbandbreedte die ervoor nodig is (een 16X anisotropic fetch resulteert in 128 samples - voor een 32 bits texture is dat dus 512 bytes aan data, en dat is dan slechts voor 1 texturefetch!)

Wat een rasterizer ook mee heeft is dat je van tevoren al weet dat je heel veel pixels op dezelfde manier in gaat kleuren, omdat je immers actieve textures instelt alvorens je een hele batch aan polygonen gaat tekenen. Bij raytracing weet je de materiaaleigenschappen pas op het moment dat je ray een polygoon raakt.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:12]

[.oisyn]

Wat hij denk ik bedoelt te zeggen is dat de generieke CPU niet zo snel textures kan fetchen zoals een GPU dat kan, omdat die laatste allemaal speciale caches heeft en fetching en filtering hardware, waardoor de uiteindelijke fetch maar een paar cycles kost, terwijl daar op een CPU heel wat instructies voor nodig zijn.

Het is dus niet dat een realtime raytracer het niet goed kan, het is dat de gebruikelijke implementatie op een hedendaagse CPU er meestal wat moeite mee heeft. Larrabee had echter weldegelijk dedicated texture fetch hardware, ik kan me voorstellen dat Knights Ferry dat ook heeft.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:12]

[Er!k]

Zeer interessante ontwikkeling... Ook gezien het feit dat de trend wordt dat je geen software meer koopt, maar afneemt als abonnement (soort SaaS oplossing). Hiermee kan dan op een breed scala aan systemen goede performance worden geboden!

[leuk_he]

Er staat duidelijk in het artikel dat dit niet bedoeld is voor consumenten, maar enkel bedoeld is om raytracen te onderzoeken. Met het soort hardware dat men daar heeft staan is ook een Saas oplossing gewoon te duur.

Blijft staan dat CPU-only raytracing wel degelijk interresant is met de versnelleing van de CPU hardware. Over enkel jaren kun je immers een PC met de zelfde kracht als dat cluster op je buro krijgen.

[YopY]

Met het soort hardware dat men daar heeft staan is ook een Saas oplossing gewoon te duur.

* te duur voor de gemiddelde consument. Het lijkt me dat bedrijven die eens een raytrace rendering van hun product willen hebben wel willen betalen voor capaciteit of sporadische renders.

[bwerg]

Dit gaat over real-time raytracing, waar een gewone CPU nog te traag voor is (je krijgt dan één beeld per X seconde), maar als je een demo-filmpje of zelfs gewoon een foto met raytracing wilt krijgen kan dat nu ook gewoon met een (relatief) lichte pc. Het duurt alleen wat langer om te renderen, maar aangezien het toch niet real-time is maakt dat niet uit, je doet een uur over een filmpje van 10 seconde renderen maar dat doe je natuurlijk gewoon voor de presentatie van je mooie reflecterende product.

[Garma]

"nog" is relatief natuurlijk - tien jaar geleden werd hier ook al onderzoek naar gedaan en toen waren de resultaten behoorlijk impressive. Het probleem is alleen dat raytracing per definitie trager is dan scanline renderen. Wolfensteijn is een jaar oud ofzo en kost nu een serverpark om te tracen, waar scanline het op een normale pc kan. Echter, volgens mij heb ik wel eens demos gezien van tien jaar oude games die nu wel realtime getraced kunnen worden. Maar stel je voor dat je mw2 wil raytracen- raytracing zal altijd achter lopen

Wel jammer want ik ben groot fan van tracen. Naast het feit dat de methode wiskundig zo intuïtief is, vergt het relatief weinig code en genereert het potentieel schitterende renders. Hopen dat een of andere wizzkid nog wat slims verzint om de performance te boosten - misschien in de gpu hoek ofzo

[Reactie gewijzigd door Garma op 23 juli 2024 08:12]

[jacobvdm]

Je moet ook bedenken dat grafische technologie voor consumenten al in de jaren negentig een bepaalde richting op is gegaan (namelijk die van de geheugen hongerige Z-buffers) en er inmiddels zo veel toevoegingen zijn gedaan om de limieten van rasterization weg te poetsen dat de huidige GPUs erg 'gespecialiseerd' zijn (daarom heeft het ook even geduurd voordat het ge-paralleliseerd werd), en ATi/nVidia als gevolg zeer geïnvesteerd zijn in het doorontwikkelen van deze ingeslagen weg.

Raytracing is juist uitermate geschikt om te paralleliseren, en laat dat nou net de richting zijn waarin de processorbakkers gaan Die zullen overigens wel geduldig het moment afwachten dat realtime raytracing voor consumenten-toepassingen interessant word, ook al zal dat nog zeker tien jaar duren.

[Reactie gewijzigd door jacobvdm op 23 juli 2024 08:12]

[Brahman]

Op zich wel natuurlijk, maar het streamen van beelden naar een client geeft natuurlijk wel latency, die je ook terugziet in het filmpje. Dit kan alleen werken op 100% glasvezel met een zeer grote bandbreedte.

Wel leuk voor de toekomst, 1 render server in je huis en gamen op elk scherm in huis.
Of een render slot huren bij een openbare server.

[M14]

Het word misschien helemaal niet gebruikt voor de (snel) bewegende objecten in het speelveld, maar alleen voor de omgeving. In dat geval vormt latency geen probleem omdat dat deel door de pc van de speler word gedaan.

[AmigaPower]

Het voordeel van raytracing is juist om bijvoorbeeld natuurgetrouwe reflectie van objecten te bieden. Als bewegende objecten niet mee worden genomen in het renderen van een statisch speelveld (wat me nogal saai lijkt ) dan zou dit nooit mogelijk zijn.

[Reactie gewijzigd door AmigaPower op 23 juli 2024 08:12]

[paazei]

Lijkt me niet zo handig, dan zou de wereld alsnog constant achterlopen op de rest van de game.

Of ik zie hier iets over het hoofd of je bent toch echt afhankelijk van de hoogste latency, want hoe wil je die wereld anders gelijk laten lopen en zoals amigapower zegt jou informatie inladen om te kunnen reflecteren?
Volgens mij heb je er niet echt lang over nagedacht.

Zoiezo is die latency die je geheid gaat krijgen zonder glasvezel onmogelijk om mee te gamen waardoor ik het nut van server-rendering-based-gaming oid komende jaren nog niet in zie.

[mashell]

Of Saas een trend of een hype is moet nog blijken.
Dit is een leuke demonstrator van intel die er voor zorgt zodat we eindelijk weten wat we met al die cores moeten en er nog meer gaan willen, en daar leeft intel weer van.

[HerrPino]

Ik zie dat geen hit worden. Vraag me af of zelfs glasvezel het trekt wanneer er 3-4 PC's op 1 adres om Full-HD beeld op 80fps vragen. Het spel 1x over de kabel, dat wil ik best geloven, maar waarom zou je de beelden continu over glasvezel streamen... dat kost vele malen meer bandbreedte, en dat ook nog continu.

[SCRAP]

Voor de duidelijkheid, Wolfenstein 3D werd altijd al (jawel 20 jaar geleden al) middels ray-tracing gerenderd!! Dat was nou juist het bijzondere aan Wolfenstein. Nu 20 jaar later doen ze het nog een keer over en doen nu net alsof ze met iets bijzonders aan komen zetten.......


Edit: toen was een 80286 al voldoende.......

[Reactie gewijzigd door SCRAP op 23 juli 2024 08:12]

[Verwijderd]

Wolfenstein 3D van bijna 20 jaar geleden werd middels raycasting gerenderd; dat is anders dan raytracing.

Het grote voordeel van raycasting is dat heel weinig rekenkracht kost omdat de afstand maar één keer per verticale lijn bepaald hoeft te worden (d.w.z. 320 berekeningen bij Wolfenstein 3D). Echter raycasting legt wel heel veel beperkingen op aan de 3D wereld; sommige noemde het dan ook 2½D.

[.oisyn]

Vroeger was er geen verschil in raycasting en raytracing, en betekende de terminologie dus hetzelfde. Pas later is er onderscheid in gemaakt, en de consensus is zo'n beetje dat het enige verschil in raycasting en raytracing is dat raycasting een niet-recursieve variant van raytracing is, waarbij je dus stopt zodra je de eerste surface hit.

Wat wolfenstein3D zo simpel maakte was dat er geen hoogteverschillen waren en de camera alleen maar om de hoogte-as gedraaid kon worden. Er hoefte daardoor voor iedere verticale beeldlijn maar 1 ray gecast te worden. Verder was de wereld onderverdeeld in blokjes, wat het vinden van snijpunten enorm vergemakkelijkte. Dát is wat de techniek in Wolf3D zo snel maakte, niet zozeer dat het raycasting ipv raytracing was (reflectie en refractie is in Wolf3D of Doom op zich nog best snel te implementeren - wel een leuk idee eigenlijk, misschien moet ik dat maar eens gaan doen voor de HTML4 versie )

.edit: oh, bedenk me net dat Duke3D ook spiegels ondersteunde, maar dat werd gefaked door de kamer erachter te dupliceren - alleen de sprites werden daadwerklijk gemirrored. Best suf eigenlijk, aangezien je raycaster ook gewoon een ray opnieuw de wereld in kon laten schieten. Maar dan was het natuurlijk geen raycaster meer

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:12]

[ronny]

Zelfs de geheime kamers zitten er in!

[Knobby]

(filmpje gezien zonder geluid)
de scope en vooral de auto waren wel indrukwekkend, maar de rest had een hoog mwah gehalte, en die rook pfff... wat is daar bijzonder aan behalve dat het er niet uitziet?

[.oisyn]

Dat particles voor een raytracer relatief duur zijn omdat de rays zoveel triangles raken

[MArKiTo]

Klopt deze stelling?
"Als het technisch mogelijk is dit in de huiskamer te krijgen en de games gebruiken het, dan zijn alle games te draaien op dezelfde machine, hoe mooi ze er ook uitzien" ? (lees: je moet niet weer een nieuwe graphics card kopen als Crysis 5 uitkomt)

[.oisyn]

Nee, die stelling klopt niet. Raytracing schaalt wellicht iets beter, maar de framerate is nog altijd afhankelijk van de scene-complexiteit. Dat zie je ook wel duidelijk aan het filmpje, als ze die kroonluchter laten zien dan zakt de framerate ook in.

[Verwijderd]

Jammer dat de video niet te bekijken valt wegens stream problemen (bufferen kent hij helaas ook niet) dan maar de youtube versie opzoeken! Een link naar de oorsprokelijke video zou ook een oplossing zijn! Iig ziet 't er leuk uit.

Ik neem aan dat over een jaartje deze technologie of een cloon ervan gewoon binnen 1 systeem gehanteerd kan worden en niet een ton € aan servers nodig is om dit te doen?
In de 3 seconde van het filmpje die ik wel gewoon kan afspelen zie ik nou geen baanbrekende (light effecten) ofzo, daar had Nvidia de troef +/- 9 maanden geleden al mee met hun render mainframe (eff google hoe dat okaweer genoemd werd)

[jacket13]

hah ik zie dat iemand nog niet de vraag heeft neer gelegd ; ik ben zeker dat die man zei dat ze 3 servers hadden draaien om hem 83frames te geven.

is dat niet beetje... insane ? heb je 3 servers nodig voor elke client wat het dus erg omslachtig maakt.