ForgottenLib - Real time ray tracing api

[Vilem Otte]

Dobrý den, rozhodl jsem se tady hodit male preview na muj osobní projekt ForgottenLib, nebo-li knihovna na ray tracing v reálnem čase.

Co se týče knihovny tak ma pořad velmi daleko k tomu, aby byla dokončena (a pravděpodobně ani po víceméně stabilnim release nebude ... spíše se bude vyvýjet dále). Řekněme, že knihovna má pořád celkem dlouhou cestu ke stabilnímu vydání. Nicméně jsem se rozhodl taky ukázat nějaké věci dosažené pomocí dané knihovny. Zejména demonstraci "Ruins raytraced", která byla interaktivně vykreslena na 4 jaderném CPU o taktu 3GHz.







Mno, je to docela dost screenů, za jejich počet se omlouvám (možná příště hodím 2-3 plus na ostatní link).
Co se týče samotné knihovny, zatím jsem se ji pokoušel implementovat pouze pod Windows, ale podle mě nebude problém ji celou portovat na SDL, popř. cokoliv jiného. Nevyužívá ani OpenGL k vykreslení (tedy nemusí), tahá se skrz Microsoftí bitmapu.
K technické stránce věci - zatím je ray tracer v rané fázi, obsahuje KD-traverzu, ale plánuji ji přepsat na BVH traverzu (popř. BIH traverzu), protože nepodporuje dynamické objekty => fixní traverza pro přepočet stromu. Traverza je nakonec provedena pomocí 2x2 pakety polopřímek v SIMD procesoru (tj. práce se všemi 4mi najednou na float úrovni). I když podle mě toho můžu ještě mnoho zoptimalizovat - co není potřeba nemít na float úrovni (tímto lze opravdu hodně ušetřit), zbavit se KD, přejít na BVH - ve skutečnosti to urychlení ani příliš velké zpomalení nebude, jenom půjdou implementovat dynamické objekty. IMNSHO provádím plno maticových výpočtů pro kameru úplně zbytečně ... zde by se taky dalo mnoho ušetřit, a tak dál a tak dál.
Ohledně grafické stránky, podporuje raytracer zatím pouze pár věcí. Dynamické globální osvětlení (použito vlastně ve většině dem enginu pro výpočet POUZE globálního osvětlení), normal mapping (tangent space), distribuovaný ray tracing (měkké stíny pro světla, které mají oblast, nejen bod (area lights), měkké reflekce, supersampling), RIP mapping - anisotropní filtr textur, několik stínovacích modelů (tady použit jenom Blinn-phong, ale podporuje také složitý Torrance-Sparrow), a možná i pár dalších věcí na které si už nevzpomenu.
Největší problém není s rychlostí ray traceru, jak by si většina myslela, ale s KD-tree ... jeho výpočet je dlouhý a navíc je pouze pro statické objekty. To bychom mohli vyřešit přechodem na BVH, popř. BIH ... no pokusíme se a potom snad uvidíme a snad také bude stačit.

Kazdopadne se budu snazit po implementaci BVH/BIH ForgottenLibovi vyrobit nějaké pěkné demo a časem ho možná i uvolnit. Nečekejte však, že to bude zítra. Mojí prioritou je momentálně dělat na enginu, toto je projekt pro můj "volný čas", navíc na něm dělám sám (narozdíl od enginu).
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]

Cool... screeny by nebyly větší? A kolik snímků za sekundu to udělá při jakým rozlišení přibližně?
_________________
AMD Open Source Graphics Driver Developer

[MePHyst0]

ako hovori Eosie, hi res screenshoty pre fajnsmekrov by bodli hlavne ta 4. ma zaujala. nevidim ci tam nejak specialne pocitas vodu, ale celkovo to vyzera dost fotorealisticky. no a maximalne super by bolo keby si sem hodil rovno video urychlujes ten render cez GPU? pomyslal si nato?

[OndraSej]

MODERÁTOR: přesunuto, nejde o hru

I já se připojuju s žádostí o bližší informace - obrázky vypadají zajímavě, ale pokud jsou v rozlišení, ve kterém se zobrazují, tak už to trochu na zajímavosti ztrácí.
Btw. jakým způsobem je reprezentovaná tráva? Každý list samostatně, nebo nějak procedurálně? Nebo jiná vychytávka?
_________________
http://trionteam.net

[Vilem Otte]

#Eosie
Co se týče snímků za sekundu - tak lze dosáhnout kolem pěkných 20 - 30 fps na 4 jaderném procesoru (a to je ještě plno místa kde optimalizovat, zatím jsem byl hlavně líný, abych to udělal ... za tu rychlost muze hlavne KD-tree traverza) při rozlišení 640x480. Počítám, že ve finálu bude API schopno na jednojádře běžet při rozlišení 640x480 alespoň na 20fps.

Screenshot time

(zatim sem hodim jen jeden, dalsi nemam tiple)

#MePHyst0
Tak ten screenshot je zrovna podobny tomu 4. Co se tyce vody, tak to je klasicky material s povrchem fraktalu, pomer reflekce/refrakce je pocitam presnymi Fresnelovymi vzorci (ne jejich pseudo implementaci), voda ma index lomu 1,33 - pro material je nastaven stejne. Plus na ni ma take velky vliv globalni osvetleni.

Video bych hodil rad, ale nemam tuseni jak ho tipnout a ulozit (mimo ukldani renderovanych screenu jako AVI, to by ale nebylo uz real time - ty 4 jadra uz jsou tak dost vytizene ... ale muzu se pokusit o tak pul minutove videjko). Fraps ani podobné bohužel použít nemůžu - nerenderuji přes OpenGL (a ani přes DirectX).

Co se tyce GPU raytracingu a urychleni, vazu se ciste jenom na CPU. GPU ma limit instrukci (ano shader model 4.0 ma sice velky pocet instrukci, ale jenom moje zakladni non-KD traverza jich ma cca 20x vice nez cely jeho limit). Navic pro KD-tree potrebuji obrovske pameti, pro tuto scenu mel "pouze" par set MB (myslim ze neco kolem 300 MB, ale nejsem si ted 100% jisty), naopak pokud bych presel na BVH nebo BIH, dostal bych se s touto scenou kolem 10 MB.
Dalsi vyhodou raytraceru je, ze muze renderovat na kazdem x86 compatibile CPU, obsahuje sice SIMD traverzu (pro informaci psana v SSE instrukcich a neobjektovem C), ale pokud CPU nema SIMD jednotku, jednoduse lze prejit na klasickou traverzu (pro informaci psana v neobjektovem C). Chvili jsem premyslel i o ASM traverze - ktera by byla napsana v assembleru, ziskal bych nejakou rychlost to ano, jenomze nevim jestli ten cas venovany ASM traverze za to stoji, myslim si ze bude stacit SIMD/C, s optimalizaci KD-tree + BVH (popr. KD-tree + BIH).

Reprezentace travy je v klasickem nemarihuanovem stavu (toto byl vtip, ktery skonci v propadlisti dějin ... taková kulturní vložka do postu). Teď vážně - tráva je reprezentována trojúhelníkovým modelem ne nepodobně jako v oblivionu, uvažujeme i o voxelové reprezentaci trávy (přece jenom toto JE raytracer a to znamená, že můžeme sledovat voxely velice, velice rychle ... i když trojúhelníky taky mají něco do sebe). Po terénu byla tráva distribuována staticky jako připravený model, jinak by bylo potřeba po každém procedurálním rozhození překopat KD-tree a to by trvalo (pro celou scénu se stavěl cca 1 hodinu 40 minut - mám pomalý KD-tree generátor )

Vychytávka - mno, ta tráva také podléhá globálnímu osvětlení
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[ladik-BigBoss]

super. presne takhle jsem si predstavoval v Panu prstenu 2, jak Gandalf popisuje smrt "then you see it, white shores and land in swift sunrise"

video bys mohl udelat jednoduse, kdyz si kazdy frame ulozis treba do nekomprimovaneho TGA (hlavicka a RGB data), pak v nejakym editoru (VirtualDub) spojis do AVI (codec bych volil h264 nebo XviD). myslim ze v nizsim rozliseni by ti to 4 jadro zvladlo

[nou]

inu myslim ze by to ani nemuselo byt realtime by sa to generovalo ako animacia v 3dsMax alebo iny. takze poukladat vsetky framy ako obrazky a potom spojit.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[Vilem Otte]

Hm... spíše než video jsem uvažoval nějakou malou přímo real time demonstraci (tohoto dema asi ne - běží na KD-tree a já připravuji BVH místo něj ... takže možná i dynamické objekty ve scéně - proto spíše demo jiné scény ... ještě se rozhoduji, navíc velikost KD-tree není zrovna nejmenší (nevim kolik přesně, ale nejmíň pár set MB to bude, možná i více)).

Nebude to hned, možná i nějaký týden to potrvá (záleží kolik času si na ray tracer najdu - ale něco mi říká - že to demo bude ještě tento měsíc). Modely zatím sice nemám, ale přemýšlím co to bude - kdybyste někdo měl nápad, klidně řekněte

Video se mi moc nechce dělat z několika důvodů:
1. - je velké (mno nemusí být, ale o tom se tady můžeme dlouho hádat)
2. - bude mi dlouho trvat než ho vyrobím (a já radši místo toho budu pokračovat v ray traceru)
3. - když vám ukážu video, nebudete se moct podívat jak moc do detailu jde ray tracer, když vám ukážu interaktivní demo - tak si budete moct vše projít jak chcete
4. - otestujete ray tracing na vašem PC v případě dema, v případě videa ne

EDIT: Demonstrovaná scéna by samozřejmě byla s vodou
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]

Nějaký update? Nové screeny? Video? Demo, které můžeme zkusit?
_________________
AMD Open Source Graphics Driver Developer

[Vilem Otte]

Mno, malý update přece jenom bude...

Programování ray traceru pokračuje, už byly stanoveny nějaké základní specifikace, ovšem pořád nejsou všechny dokončeny ... pár informací však již mohu uvolnit:

1) Plánuje se podpora urychlení výpočtů přes GPU pomocí OpenCL (ještě ale pořád záleží na tom, jak se k němu postaví AMD/ATI) - především traversalu, stínování a možného post-processing. Podpora LaraBee bude, ovšem záleží zase na Intelu, kdy ji uvolní. Ovšem nic z tohoto nemění, že ray tracer poběží i na samotném CPU.
2) Stínování bude částečně programovatelné.
3) Ohledně akceleračních struktur uvažujeme že je bude moct řešit přímo programátor (ovšem k dispozici by byly i vestavěné - KD-Tree, BVH, momentálně pracujeme na BIH a QBVH).

Co se týče demonstrace, tak budeme veřejně uvolňovat demo (velmi brzy, řádově v týdnech), které používá jak CPU tak GPU (momentálně přes OpenGL, které používáme i k urychlení některých částí stínování a také k post processing efektům). Ještě však pořád řešíme některé poslední otázky ohledně filtrace textur, zda bude možno použít antialiasing (nejlépe na GPU, protože CPU supersampling a texturový filtering je při raytracingu velmi náročný) a také budeme ještě některé části předávat na GPU, abychom dosáhli vyšší rychlosti.

Screen z dema -

Především jsme se zaměřili na stíny a reflekce/refrakce na vodě. Uvažujeme také o ukázce lokální dostupnosti světla a globálním osvětlení - ovšem přece jenom pořád jsme se s nimi nedostali na rozumný čas dynamického výpočtu.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Vilem Otte]

Nuže další update k ForgottenLIB.

O jeho další ukázce praktického použití jsem se rozhodl asi předevčírem, když jsem něco opravoval v Materiálovém editoru.
Zkusil jsem dát dohromady ForgottenLIB (a velkou část jeho vykreslení) s Materiálovým editorem (a tudíž i s enginem), nedopadlo to zrovna nejhůře a tak jsem se tedy rozhodl uploadnout na youtube prvně jedno, poté druhé video (v prvním ukazuji jen stíny a ve druhém už i s nějakým tím GI solverem ... není to ale zatím plnohodnotný path tracing).
Obě videa jsem nahrával když běžely interaktivně na jedné z mojich testovacích mašin (Core 2 duo 2.67 Ghz, 2GB RAM a GeForce 8600GTS. K nahrávání jsem použil fraps (kdy jsem se až překvapivě divil, že mi klesl výkon jen asi o 5-10% když nahrávám).
Jak jsem také napsal k popisu videa ForgottenLIB se tady nestará o celé vykreslení - nejnáročnější výpočty (shading pomocí Oren Nayar diffuse modelu a Cook Torrance specular modelu) nechávám na GPU - kam posílám veškeré potřebné data (překvapivě to rychlost o dost zvýšilo, sám jsem to o tolik nečekal).

Škoda že ForgottenLIB zatím pořád není úplně hotový na reálné použití (a zřejmě bude až za dlouho) - ale pomalu se blížím hranici kdy už se bude dát nějaká ta knihovnička uvolnit.

Nuže k videím:
První ukazující plausibní stíny
http://www.youtube.com/watch?v=Dz-QE37vyuQ
Druhé ukazující plausibní stíny a globální osvětlení
http://www.youtube.com/watch?v=NOyojy7n7h0

Na konci druhého videa lze také vidět "pseudo lva" který chodí - dynamický model kde jsem musel přestavět BVH každý snímek byl jak jsem předpokládal nejpomalejší.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.