GDC 2011
- Trådstarter sheriffen
- Startdato
Du kommer ikke til å se real-time ray-tracing i spill i den nære fremtid. Se hvor krevende baked radiosity og ambient occlusion er.
In fact, ta og sett opp en enkel 3d-motor og begynn å gjøre raycasts som bouncer X antall ganger med polygon-level kollisjonspresisjon. Se hvor mange rays du klarer å kjøre før simulasjonen går til helvete. Deretter prøver du å gjøre det samme med pikselpresisjon. Så sub-pikselpresisjon. Du kan kanskje gjøre per-poly raytracing og fudge resten derfra, men det er også laaaaangt fram i tid.
Edit: Hah, hvis du raytracer i screen-space sparer du en del bry, men du må STADIG ha worldspace-presisjon på bouncene, og da har du ikke spart så jævlig mye når det kommer til stykket.
Hvis vi får grafikkort med pipelines dedikert til raytracing, så kanskje -- men da har vi egentlig bare utvidet problemet ved å adskille ENDA en fixed-function pipeline. Så da sitter du med spillkode på CPU-en, geometrikonstruksjon på GPU pipeline 1, raytracing i pipeline 2 og post-prosessering i pipeline 3. Woooooh.
GPGPU, sier jeg, og glem fotorealisme. Det er ikke en realitet i offline CG og kommer garantert ikke til å skje i real-time CG før flere tiår etter at det er oppnådd offline, med mindre noen plutselig og ut av ingensteder finner opp en billig, energieffektiv kvanteprosessor som er lett å masseprodusere.
Ha. Ha. Ha.
Jah, seff, voksler er ikke noen catch-all vidunderløsning, men tenk litt på det: om du bruker meshes som shell for partikkelvolumer vil du kunne deformere volumet uten å forandre mesh-en! Det er nemlig det som er så søpledyrt med morph targets og slikt: Du må ha mesh-en i RAM, og så må du applye transformasjonene i geometri-pipelinen eller som vertex shader.
I tillegg er du nødt til å omberegne UVW-ene dine og så må du repacke UVW-ene dine og så må teksturene flyttes omkring (også i RAM eller VRAM, avhengig av hvor mye hastighet du trenger, both of which are highly constrained resources på de fleste konsoller og datamaskiner). Du kan selvsagt lagre den nye geometrien derfra, men da er du plutselig nødt til å swappe masse RAM, hvilket betyr at du er nødt til å budsjettere dobbelt med RAM for hver enkelt deformerbar mesh og vips har du kompromittert enten ytelsen din eller antallet meshes i spillrommet.
Du kan selvsagt streame, men du må fortsatt levne masse RAM til swapping. Du risikerer også at du er nødt til å holde modifiserte mesh-er (eller iallfall transformasjonsmatrisene deres, altså mucho data) i RAM for å holde verdenen konsistent.
Det er også verdt å merke at de fleste spill bruker BSP for statisk geometri (som brett), og at det er et ekstremt lite fleksibelt format. Det er himla rask og greit for å sette opp rendring, men om du forandrer noe i det er du nødt til å beregne hele treet ditt på nytt igjen -- og BSP-trær kommer ikke nødvendigvis likt ut hver gang, det er en av grunnene til at det var så mye artig tunnelering i Counter-Strike. Du kan selvsagt splitte opp brettet ditt i flere BSP-er, men da har du plutselig en flaskehals i optimaliseringen din igjen og du bekjemper hensikten.
Polygoner er troublesome. Enten er de treige, eller så er de infleksible. Kurver er enda verre, ettersom kompleksiteten deres øker eksponensielt. Voksler og pikselvolumer er dyre å beregne og tegne, men det er igjen nokså billig å kødde med dem derfra. Sjekk ut VOXLAP-motoren til Ken Silverman for å se hva du kan gjøre. Kildekoden ligger også der, forøvrig.
In fact, ta og sett opp en enkel 3d-motor og begynn å gjøre raycasts som bouncer X antall ganger med polygon-level kollisjonspresisjon. Se hvor mange rays du klarer å kjøre før simulasjonen går til helvete. Deretter prøver du å gjøre det samme med pikselpresisjon. Så sub-pikselpresisjon. Du kan kanskje gjøre per-poly raytracing og fudge resten derfra, men det er også laaaaangt fram i tid.
Edit: Hah, hvis du raytracer i screen-space sparer du en del bry, men du må STADIG ha worldspace-presisjon på bouncene, og da har du ikke spart så jævlig mye når det kommer til stykket.
Hvis vi får grafikkort med pipelines dedikert til raytracing, så kanskje -- men da har vi egentlig bare utvidet problemet ved å adskille ENDA en fixed-function pipeline. Så da sitter du med spillkode på CPU-en, geometrikonstruksjon på GPU pipeline 1, raytracing i pipeline 2 og post-prosessering i pipeline 3. Woooooh.
GPGPU, sier jeg, og glem fotorealisme. Det er ikke en realitet i offline CG og kommer garantert ikke til å skje i real-time CG før flere tiår etter at det er oppnådd offline, med mindre noen plutselig og ut av ingensteder finner opp en billig, energieffektiv kvanteprosessor som er lett å masseprodusere.
Ha. Ha. Ha.
Jah, seff, voksler er ikke noen catch-all vidunderløsning, men tenk litt på det: om du bruker meshes som shell for partikkelvolumer vil du kunne deformere volumet uten å forandre mesh-en! Det er nemlig det som er så søpledyrt med morph targets og slikt: Du må ha mesh-en i RAM, og så må du applye transformasjonene i geometri-pipelinen eller som vertex shader.
I tillegg er du nødt til å omberegne UVW-ene dine og så må du repacke UVW-ene dine og så må teksturene flyttes omkring (også i RAM eller VRAM, avhengig av hvor mye hastighet du trenger, both of which are highly constrained resources på de fleste konsoller og datamaskiner). Du kan selvsagt lagre den nye geometrien derfra, men da er du plutselig nødt til å swappe masse RAM, hvilket betyr at du er nødt til å budsjettere dobbelt med RAM for hver enkelt deformerbar mesh og vips har du kompromittert enten ytelsen din eller antallet meshes i spillrommet.
Du kan selvsagt streame, men du må fortsatt levne masse RAM til swapping. Du risikerer også at du er nødt til å holde modifiserte mesh-er (eller iallfall transformasjonsmatrisene deres, altså mucho data) i RAM for å holde verdenen konsistent.
Det er også verdt å merke at de fleste spill bruker BSP for statisk geometri (som brett), og at det er et ekstremt lite fleksibelt format. Det er himla rask og greit for å sette opp rendring, men om du forandrer noe i det er du nødt til å beregne hele treet ditt på nytt igjen -- og BSP-trær kommer ikke nødvendigvis likt ut hver gang, det er en av grunnene til at det var så mye artig tunnelering i Counter-Strike. Du kan selvsagt splitte opp brettet ditt i flere BSP-er, men da har du plutselig en flaskehals i optimaliseringen din igjen og du bekjemper hensikten.
Polygoner er troublesome. Enten er de treige, eller så er de infleksible. Kurver er enda verre, ettersom kompleksiteten deres øker eksponensielt. Voksler og pikselvolumer er dyre å beregne og tegne, men det er igjen nokså billig å kødde med dem derfra. Sjekk ut VOXLAP-motoren til Ken Silverman for å se hva du kan gjøre. Kildekoden ligger også der, forøvrig.
Nettopp. 
Raytracing i real-time er et sånt ureduserbart problem som sannsynligvis ikke vil løses før noen kommer opp med en kul modell som ikke krever virtuelle fotoner for å funke. Som sagt, selv screen-space/deferred world space raytracing er ute på viddene, og approximations som deferred rendering lider av at de fortsatt må bruke raycasts for å gjøre radiosity. De kan selvsagt gjøres on a per-face basis, gouraud shading-style, men da er vi ikke lenger fotorealistiske.
JEG KAN TA FEIL, men jeg kan ikke skjønne at dette vil skje i den nærmeste fremtid. Om 25 år, kanskje, men da finnes nok ikke lenger mesteparten av mediaindustriene vi forholder oss til i dag.
EDIT: Vi kan godt få til fotorealisme i særskilte tilfeller med veldig spesifikke rendringsmetoder og shadere som vil være domain-specific. Se på de som bruker Crysis-motoren til spesialeffekter og landskapsskudd i indie-filmer. Det er tilnærmet fotorealistisk, men det funker ikke i real-time ... enda. Det er generaliserte løsninger for fotorealistisk rendring (som ray-tracing) som slår meg som enormt usannsynlig.
Raytracing i real-time er et sånt ureduserbart problem som sannsynligvis ikke vil løses før noen kommer opp med en kul modell som ikke krever virtuelle fotoner for å funke. Som sagt, selv screen-space/deferred world space raytracing er ute på viddene, og approximations som deferred rendering lider av at de fortsatt må bruke raycasts for å gjøre radiosity. De kan selvsagt gjøres on a per-face basis, gouraud shading-style, men da er vi ikke lenger fotorealistiske.
JEG KAN TA FEIL, men jeg kan ikke skjønne at dette vil skje i den nærmeste fremtid. Om 25 år, kanskje, men da finnes nok ikke lenger mesteparten av mediaindustriene vi forholder oss til i dag.
EDIT: Vi kan godt få til fotorealisme i særskilte tilfeller med veldig spesifikke rendringsmetoder og shadere som vil være domain-specific. Se på de som bruker Crysis-motoren til spesialeffekter og landskapsskudd i indie-filmer. Det er tilnærmet fotorealistisk, men det funker ikke i real-time ... enda. Det er generaliserte løsninger for fotorealistisk rendring (som ray-tracing) som slår meg som enormt usannsynlig.
Jaaaaaa ... men i så måte er det vi har bra nok, for det er ikke nødvendig for spillene i seg selv. Dealen med raytracing er at det er convenient to a certain degree men krever enorme mengder simulasjon.
Og ja, jeg vet egentlig ikke hva jeg snakker om. Jeg antar jeg blir korrigert hvis jeg er alt for langt ute på jordet.
Og ja, jeg vet egentlig ikke hva jeg snakker om. Jeg antar jeg blir korrigert hvis jeg er alt for langt ute på jordet.