CryTek i Dubrovnik

poruka: 10
|
čitano: 3.980
|
moderatori: Lazarus Long, XXX-Man, vincimus
1
+/- sve poruke
ravni prikaz
starije poruke gore
16 godina
protjeran
offline
CryTek i Dubrovnik

Neznam dali je netko primjeti ovo http://www.crytek.com/downloads/technology/  ,(Atrium Sponza Palace, Dubrovnik) vidio sam nekoliko demoa koji koriste ovaj model, al nisam imao pojma o čemu je riječ

Programko http://programko.bloger.hr
 
3 0 hvala 2
15 godina
neaktivan
offline
CryTek i Dubrovnik

Da, vidio sam taj demo kad je izasao ali nisam znao da je to palaca iz Dubrovnika.

 

Apropos tehnologije, kako ih mrzim s tim globalnim osvijetljenjem... nemam pojma sto bih dao da mogu samo baciti pogled na taj shader par sati, da skuzim kako radi. To je bolesnoca, jedan jedini, direkcionalni izvor svijetla, a cijela palaca je osvijetljena, svaki kutak!

Uz malo truda, da se vidjeti da s danasnjim hardwareom moguce je prebakeati transfere energije za kompletno staticnu scenu (staticnu geometriju da ni ne spominjem), ali to jednostavno pada u vodu cim dodas najobicniji kus geometrije koji se mice po prostoru.

Nije mi jasno... bas mi nije jasno. Mislim, siguran sam da varaju slicno kako Source vara za ambijentno osvijetljenje ("ambient cube"), ali ne mozes iskalkulirati transfer svaki frame dovoljno brzo. Mrzim ih :-D

Don't try to undertand if you weren't there... you felt different then - Marching off to War...
Poruka je uređivana zadnji put uto 20.4.2010 16:14 (Deus ex machina).
 
0 0 hvala 0
14 godina
neaktivan
offline
RE: CryTek i Dubrovnik

Rijec je o popularnoj sceni pri testiranju renderera. U galeriji gotovo svakog renderera ces naletjeti na rendering te scene. Ocito crytekovci pokusavaju slati podsvjesne poruke da je njihov engine na razini tih renderera. Ah taj marketing Smijeh

 

Ni ja nisam znao da je to u Dubrovniku (meni je taj model otprije poznat kao "atrium sponza", ali nisam imao previse motivacije istrazivati gdje je to)

16 godina
protjeran
offline
CryTek i Dubrovnik

Možda je to razlog, ali meni je prvo prošlo kroz glavu da je utjecalo to da u Crytek-u ima ljudi hrvatskog podrijekla, ako pogledate u source code CryENGINE C++ MOD SDK - a, vidjet će te imena ljudi koja zvuče kao naši ili sigurno imaju naše podrijeklo. A kad domoljublje proradi... Druga stvar koja mi je prošla kroz glavu je ; da Mađarska (Budimpeštanska podružnica) voli ljetovati na Jadranu. Belji se Vjerovatno nikad nečemo saznati pravu istinu. Mršti se.

Programko http://programko.bloger.hr
 
1 0 hvala 0
15 godina
neaktivan
offline
CryTek i Dubrovnik

Pa, brijem da je dovoljno odaslati email i pitati ;-)

Don't try to undertand if you weren't there... you felt different then - Marching off to War...
 
0 0 hvala 0
16 godina
neaktivan
offline
RE: CryTek i Dubrovnik
Deus ex machina kaže...

Da, vidio sam taj demo kad je izasao ali nisam znao da je to palaca iz Dubrovnika.

 

Apropos tehnologije, kako ih mrzim s tim globalnim osvijetljenjem... nemam pojma sto bih dao da mogu samo baciti pogled na taj shader par sati, da skuzim kako radi. To je bolesnoca, jedan jedini, direkcionalni izvor svijetla, a cijela palaca je osvijetljena, svaki kutak!

Uz malo truda, da se vidjeti da s danasnjim hardwareom moguce je prebakeati transfere energije za kompletno staticnu scenu (staticnu geometriju da ni ne spominjem), ali to jednostavno pada u vodu cim dodas najobicniji kus geometrije koji se mice po prostoru.

Nije mi jasno... bas mi nije jasno. Mislim, siguran sam da varaju slicno kako Source vara za ambijentno osvijetljenje ("ambient cube"), ali ne mozes iskalkulirati transfer svaki frame dovoljno brzo. Mrzim ih :-D

Imas objavljene clanke na kojem principu radi i tehnika je dosta "jednostavna" u sustini i ne radi se jednom shaderu nego hrpi njih te passova da se postigne tako nesto. Vec je dosta puta napravljena slicna stvar.
Ovo nije prekalkulirano nego full dinamicko i nema problema sa dinamickim objektima. Nema veze sa tehnikom koja se koristi u source engineu. Ovdje se jednostavno radi o 3D gridu recimo 32x32x8 koji se puni sa color informacijom i transfer energije se prenosi kroz taj grid u par passova. Color informacija koja se prenosi u grid se izvodi sa dva mjesta. Prvi je scena koja se promatra iz kamere i scena koja se promatra iz shadow map kamere. U tom trenutku se preko MRT renda tri teksture u nizoj rezi. Jedan je color informacija, druga je buffer sa normalama i treca je depth buffer. Onda se iz iz toga progresivno puni grid i simulira se transfer energije, s tim da svaka tocka u gridu ima takozvani occlusion factor i smjer. Izuci kako radi PRT pa ces vidjeti o cem se radi. Na osnovu tog occlusion faktora i smjera se odreduje distribucija energije svaki sljedeci pass. Nakon nekoliko passova dobije se grid u kojem je distribuirana energija. Taj grid se pakira u volumnu teksturu i u sljedecem passu kad se renda stvarna geometrija na ekran se fino samplea ta volumna tekstura i dobijes realtime globalnu iluminaciju u svakoj tocki i jos dobijes besplatno trilinearno filtriranje. S ovim se lako rijesi i soft refleksija jer je dovoljno samo samplati par puta unutar grida od tocke za koju se racuna osvjetljenje u smjeru reflektirane zrake. To samplanje akumuliras i normaliziras i dobijes realtime soft refleksiju. Takoder se moze napraviti i volumetrisko osvjetljenje jer mozes u smjeru svakog pixela kamere samplati par desetaka puta i akumilirani tu color informaciju i onda ju blendati s ostatkom scene. Jos prije 5 godina sam imao ideju izvesti slicnu stvar, ali nisam nikako stigao jer su me drugi projekti stiskali pa su bile potrebnije druge stvari. Al ideja je bila ista da se globalna iluminacija sprema u volumne teksture. S tim da sam u to vrijeme mislio prekalkulirati za svaki sektor grid i odgovarajucu volumnu teksturu. Sad da to radim bi isto isao na to da obnovljam grid svaki frame. Grid je inace virtualni sto znaci da se pomice skupa sa kamerom svaki frame jer bi inace trebalo tona memorije i nemoguce za prekalkulirati vise informacija sa trenutnim karticama. To znaci naravno da jako udaljeni objekti nece imati glboalnu iluminaciju ali nije to toliko niti bitno. Oni su jos i prosirili metodu tako da korisite kaskadne gridove. To je fora sa vise nested gridova razlicite rezolucije. Tako se pokrije vece podrucije sa manjim zauzecem memorije. To je fora preuzeta i kaskadnih shadow mapa. Uglavnom ova tehnika ce profitirati na DX 10.1 i DX11 render pathu jer je tamo moguce direkno rendati u volumnu teksturu dok to na DX9 nije moguce. E da, i ovu metodu je moguce prosiri na jos jednu tehniku samo onda nije moguce dobiti occlusion informaciju a to je da se za svaku tocku u gridu spawna jedno svjetlo. Naravno posto se radi o jako puno svjetala za recimo 32x32x8 grid to je  8192 svjetla ako bi se za svaku tocku stavilo jedno svjetlo. A veliku kolicinu svjetala je jedino moguce implementirati preko deferred render tehnike ti se svako svjetlo racuna u screen spaceu. Tu tehniku je isto crytek demonstrirao jer je njihov novi engine totalno orjentiran na deferred render. Radi konzola to im je sada puno vise odgovaralo. Inace ni to nije novo i puno ljudi je radilo tako nesto samo to nisu velike firme koje bombasticno objavljuju takve stvari kao jedan veliki crytek. Npr. ovu zadnju gore spomenutu tehniku je ubacio tip u svoju infinity svemirsku igru. To ce koristiti vjerojatno za osvjetljavanje unutrasnjosti stanica. Evo ovo je najjednostavnije sto sam ovo mogao pojasniti.

Poruka je uređivana zadnji put pet 30.4.2010 10:07 (LevaOpaki).
15 godina
neaktivan
offline
RE: CryTek i Dubrovnik
LevaOpaki kaže...

Imas objavljene clanke na kojem principu radi i tehnika je dosta "jednostavna" u sustini i ne radi se jednom shaderu nego hrpi njih te passova da se postigne tako nesto. Vec je dosta puta napravljena slicna stvar.
Ovo nije prekalkulirano nego full dinamicko i nema problema sa dinamickim objektima. Nema veze sa tehnikom koja se koristi u source engineu. Ovdje se jednostavno radi o 3D gridu recimo 32x32x8 koji se puni sa color informacijom i transfer energije se prenosi kroz taj grid u par passova. Color informacija koja se prenosi u grid se izvodi sa dva mjesta. Prvi je scena koja se promatra iz kamere i scena koja se promatra iz shadow map kamere. U tom trenutku se preko MRT renda tri teksture u nizoj rezi. Jedan je color informacija, druga je buffer sa normalama i treca je depth buffer. Onda se iz iz toga progresivno puni grid i simulira se transfer energije, s tim da svaka tocka u gridu ima takozvani occlusion factor i smjer. Izuci kako radi PRT pa ces vidjeti o cem se radi. Na osnovu tog occlusion faktora i smjera se odreduje distribucija energije svaki sljedeci pass. Nakon nekoliko passova dobije se grid u kojem je distribuirana energija. Taj grid se pakira u volumnu teksturu i u sljedecem passu kad se renda stvarna geometrija na ekran se fino samplea ta volumna tekstura i dobijes realtime globalnu iluminaciju u svakoj tocki i jos dobijes besplatno trilinearno filtriranje. S ovim se lako rijesi i soft refleksija jer je dovoljno samo samplati par puta unutar grida od tocke za koju se racuna osvjetljenje u smjeru reflektirane zrake. To samplanje akumuliras i normaliziras i dobijes realtime soft refleksiju. Takoder se moze napraviti i volumetrisko osvjetljenje jer mozes u smjeru svakog pixela kamere samplati par desetaka puta i akumilirani tu color informaciju i onda ju blendati s ostatkom scene. Jos prije 5 godina sam imao ideju izvesti slicnu stvar, ali nisam nikako stigao jer su me drugi projekti stiskali pa su bile potrebnije druge stvari. Al ideja je bila ista da se globalna iluminacija sprema u volumne teksture. S tim da sam u to vrijeme mislio prekalkulirati za svaki sektor grid i odgovarajucu volumnu teksturu. Sad da to radim bi isto isao na to da obnovljam grid svaki frame. Grid je inace virtualni sto znaci da se pomice skupa sa kamerom svaki frame jer bi inace trebalo tona memorije i nemoguce za prekalkulirati vise informacija sa trenutnim karticama. To znaci naravno da jako udaljeni objekti nece imati glboalnu iluminaciju ali nije to toliko niti bitno. Oni su jos i prosirili metodu tako da korisite kaskadne gridove. To je fora sa vise nested gridova razlicite rezolucije. Tako se pokrije vece podrucije sa manjim zauzecem memorije. To je fora preuzeta i kaskadnih shadow mapa. Uglavnom ova tehnika ce profitirati na DX 10.1 i DX11 render pathu jer je tamo moguce direkno rendati u volumnu teksturu dok to na DX9 nije moguce. E da, i ovu metodu je moguce prosiri na jos jednu tehniku samo onda nije moguce dobiti occlusion informaciju a to je da se za svaku tocku u gridu spawna jedno svjetlo. Naravno posto se radi o jako puno svjetala za recimo 32x32x8 grid to je  8192 svjetla ako bi se za svaku tocku stavilo jedno svjetlo. A veliku kolicinu svjetala je jedino moguce implementirati preko deferred render tehnike ti se svako svjetlo racuna u screen spaceu. Tu tehniku je isto crytek demonstrirao jer je njihov novi engine totalno orjentiran na deferred render. Radi konzola to im je sada puno vise odgovaralo. Inace ni to nije novo i puno ljudi je radilo tako nesto samo to nisu velike firme koje bombasticno objavljuju takve stvari kao jedan veliki crytek. Npr. ovu zadnju gore spomenutu tehniku je ubacio tip u svoju infinity svemirsku igru. To ce koristiti vjerojatno za osvjetljavanje unutrasnjosti stanica. Evo ovo je najjednostavnije sto sam ovo mogao pojasniti.

Hvala na objasnjenju!

Za ironiju ovo me totalno podsjeca na Source engine - ne na dio oko radiosity mappinga, nego na fakeano environment osvijetljenje. Fakeali su to sa 'kockom' oko scene koja zraci svijetlo, tako da dinamicki entityi izgledaju osvijetljeno realno bez iskakanja. Ovo sto je crytek napravio je ista fora samo sa gridom, ne sa kockom.

 

Dio koji mi nije uopce nije jasan je kalkulacija occlusion faktora. Naime, dobro si poentirao kasnije kad si rekao koliko svijetla trazi svaki grid.

No nema teorije da deferred renderer izgura ni 1000 svijetla, a kamoli 8000 bez LOD-a. Stotinu, dvije, OK prezivljivo, ali 8000? Ni u ludilu. U svakom slucaju je bolje nego 8 svijetala na koje smo ograniceni fixed pipelineom :-D

Drugo, s obzirom da je scena dinamicka, nema prekalkulacija, to znaci da svaki frame moras kalkulirati 8192 occlusion faktora a ta kalkulacija je 'teska' jer trazi vidljivost iz svakog drugog nodea u gridu. Prakticno, loop s counterom od 8000 unutar loop-a s counterom od 8000.

 

Ideja je OK i sasvim logicna smanjiti occlusion rezoluciju scene i blendati rezultate, ali mi nije jasno kako kalkuliraju vidljivost svake celije u odnosu na drugu celiju, da bi uopce iskalkulirai transfer energije - taj dio mi nije jasan, je ga je imho nemoguce provesti u screenspaceu kao SSAO.

 

Mozes baciti par linkova s kojih si pokupio informacije ovdje, nije mi bed pogledati kompliciranija objasnjenja s formulama :-)

 

Edit:

vidi vraga, ipak je moguce.

Don't try to undertand if you weren't there... you felt different then - Marching off to War...
Poruka je uređivana zadnji put pet 30.4.2010 14:53 (Deus ex machina).
14 godina
neaktivan
offline
CryTek i Dubrovnik

Inace Sponza i Sibenka katedrala su kultne test scene za renderere. Dabrovicevi modeli.

I never learned from a man who agreed with me. - Robert A. Heinlein
Moj PC  
0 0 hvala 0
16 godina
neaktivan
offline
RE: CryTek i Dubrovnik

Da samo rijec fake mozda nije upotrebljena na pravom mjestu, jer je sve na neki nacin fake. :) Metoda moze biti samo naprednija od one prethodne. Ima fakea i u filmskoj industriji, buildanje raznih cache podataka da se akcelerira rendering itd. Fora kod source enginea je da je koristio filtrirane cube mape za osvjetljenje okoline i to je jedan od nacina. S tim da su oni prekalkulirati radiosity u lightmape, nakon toga se rendali hrpu cubemapica tamo di je bilo bitno i di ih je artist postavio da poveca gustocu i to se kalkuiralo kod exporta levela, tako da se u realnom vremenu nije nista updatealo. Metoda je super, ali joj je jedina mana sto ne moze osvjetliti staticnu geometriju nego samo male dinamicke entitete. Jer ako per model setiras za shader jednu cube mapu to znaci da ce cijeli zid koristiti samo jednu cubemapu. Znaci nista od toga da neki objekt koji je blizu zid zraci necim, recimo neka crvena kugla ili tepih kao kod cryteka ne moze osvjetliti susjedni zid. Zato su imali 2D lightmape za zidove i staticnu geometriju i cube mape za dinamicke modele. Onda su se pojavile razne tehnike koje su radile grid, ali za svaku tocku u 3D gridu se koristila jedna filtrirana cubemapa. Te cube mape su mogle biti statince, full dinamicke da se rendaju svaki frame ili da se rendanje cubemapa distribuira preko nekoliko frameova. Recimo da ih je u prostoriji 400, pa ih rendas 50 svaki frame. Znaci jedan cubemapa se updatea svaki 8. frame. Ne zaboravi da za cubemapu moras rendati 6 puta radi 6 strana. Tako nesto je ATi implementirao u onom demou za 10.1 demonstraciju, jer je on uveo render to cubemap array pa se moglo vise cubemapa rendati po framu, a za pojedini entitet se moglo setirati array cubemapa pa je osvjetljenje bilo bolje nego da je samo jedna cubemapa. Onda si opet imao metode di je bio prekalkuliran grid sa ambientalnom bojom pa se entitetu prosljedivali 6 boj za svaki smjer pa su se one interpolirale. To je dosta demo-a i igara koristilo. Recimo onaj trinigy engine je koristio i koristi jos uvijek nesto slicno na jednoj razini, imao demo od MS u DX SDK koji koristi to, a boje prekalkulira PRT simulacijom itd. Crytek je prvi ovo spremio u volumnu teksturu da je to dio enginea. Onda je fora da ako imas level prozet tom volumnom teksturom, znaci da za svaki model koji rendas setiras tu jednu te istu volumnu teksturu, a ovisno o poziciji vertexa u prostoru samplas svaki puta drugi dio te volumne teksture. Pozicije su naravno interpolirane po surfaceu. I tako dobijes fine filtrirane prijelaze u boji cak i za isti zid. Volumnu teksturu gledaj kao hrpa 2D naslaganih tekstura jedna povrh druge. To se zovu sliceovi. To bi se cak moglo emulirati sa 2D texture array na DX10 i 11. Ali ce biti samo bilinearno filtriranje, jer nece biti filtriranja izmedu sliceova kao kod volumne. Uglavnom, volumna tekstura je odlicna cak i za staticno prekalkulirani level. Samo eto crytek je odlucio updateati grid i volumnu teksturu svaki frame i eto prolazi bez problema, kartice sada imaju dovoljno snage. Tehnika je stvarno super.


Hmm ovo za occlusion faktor je malo teze pojasniti tipkajuci, ali ako imas depth, normalu i boju pixela, onda na osnovu normale i okolnog dephta mozes izkonstruirati nesto sto izgleda kao usmjerena elipsa/disk. Taj disk odreduje smjer djelovanja energije kad se odbije od tog surfacea. Difuzni buffer odreduje boju koja ce se propagirati kroz grid. I onda u nekih 8 recimo iteracija svaku iteraciju transferiras energiju u smjeru normalne s tim da ta elipsa odreduje smjer u kojem se energija moze siriti. Probaj si to nacrtati na papir. Imas biljeznicu na kockice i da se jedna kockica svaku iteraciju krene siriti okolo a neka elipsa, vise oblik zarulje, odreduje smjer transfera energije. I ako se nesto nade na putu elipsa to nece pokrivati i blokirat ce daljnju distribuciju energije u tom smjeru. To ces vidjeti kao soft sjenu ako se nesto nade na putu kao blocker :) Uh jesam sada ovo objasnio. I sada zamisli kako se u 8 iteracija ta energija siri u zadanom smjeru i okolni gridovi polako dobijaju energiju ako spadaju po smjer te elipse. Prije bi u biti tu elipsu nazvao komad hemisfere. On odreduje koliko okoline dolazi u tu tocku. E sada, u ovoj metodi energija se inicira sa dva mjesta, jedan je iz smjera shadow mape, a jedan je iz smjera kamere. Tako se dobije osvjetljenje od djelova koji inace nisu vidljivi kamerom. To je inace problem kod SSAO implementacije. Ako gledas samo depth buffer koji vidi kamera, onda kako nesto moze bacati sjenu sto nije u kameri. Inace imas cak i verziju sa ScreenSpaceRadiosity, SSR, i s tako necim sam bio eksperimentirao. Problem je isti sto povrsina koja se ne vidi na ekranu, a mozda je pokraj nece bacati globalnu iluminaciju. Ali metoda je istao kao SSAO samo sto ne samplas samo depth buffer nego i color buffer. To je craytek odmah probao nakon SSAO samo je problem metode sto nema veliki radius djelovanja. Ako povecas prevelik kernel za filtriranje, perfomanse odu u bananu jer se ne koristi dobro cache. I onda dobijes samo lokalno color bleed. Al i ovo nekad dobro dode. Samo sto kosta ko vrag na grafickoj ako se kombinira sa SSAO. Previse je to samplova. Zato su odmah presli na volumne teksture i grid pristup.

Nema ti problem deferred render sa toliko svjetala, jer moras na koji princpip radi ta metoda. Recimo rendas u 4 buffera boju, normale, dubinu, light accumulation buffer i jos neke stvari koje ti trebaju. To sve radi jedan shader za svu geometriju osim onu transparentnu. Ona se i dalje mora rendati forward metodom. Onda u postprocessing passu za svaki pixel uzmes te informacije, rekonstruiras world position ili view position i radis lighting. Ako u ligh bufferu nemas svjetla (RGB(0,0,0)) na tom pixelu nece biti svjetla ali se svejedno izvrsi formula za svaki pixel. To znaci da se za svako svjetlo u biti samo renda "krug sa radiusom" svjetla i nebitno koliko svjetala da ima za svaki se uvijek izvrsi jedan broj kalkulacija. Znaci bitno je samo koliko je velik frame buffer. A svaki taj radius svjela mozes rendati kao recimo spheru ili cak particle. A to znaci da sve particle mozes rendati od jednom tj jedan draw call ili jedan DrawPrimitive. A danas mozes rendati i 20000 quadova u jednom pozivu bez usporavanja, barem to uspije izvuci moj particle system. Isto tako sve sfere mozes istancirati ili ih ugurati u jedan VB. Znaci deferred render nije metoda kad rendas objekt pa onda za njega prikacis shader, konstante i teksturu pa onda vrsis osvjetljenje. U toj metodi je overdraw prevelik za racunanje sjetla i zato su lose perfomanse sa puno svjetala, plus ih ne mozes ugurati previse u jedan shader.
U deferred renderu si sve informacije dovedes kao fullscreen teksture i sve operacije., svjetlo sjena, materiali vrsis u fillscreenu rendajuci quadove. To je super jer onda mozes totalno odvojiti od shadera dio za sjene, maglu i druge stvari sto pojednostavljuje shadere.


Evo i ja sam utjerao spozna model u svoj engine i evo kako izgleda. Naravno HDR DOF, HDR motion blur, SSAO, 64 bitni HDR, moja verzija GI, soft sjene, light adaptacija, tone mapping, gama linearne light kalkulacije i sve je dinamicko. Kad uhvatim vremena budem se pozabavio malo vise ovom njihovom tehnikom. Inace svaki surface mi se nije dalo tweakati pa samo samo svima nabacio isti material, vise manje, i nije mi se dalo osvjetljenje podesiti. Evo, ovo je cisti programer art :) Lijepo da su dali taj preradeni model jer je super za testiranje.  Onaj stari spozna je imao premalo detalja i bio je jednolican.

Poruka je uređivana zadnji put sub 1.5.2010 17:12 (LevaOpaki).
16 godina
neaktivan
offline
RE: CryTek i Dubrovnik

Bas sam skuzio da koriste i ScreenSpaceRadiosity za udaljene objekte u kombinaciji s ovom tehnikom. Posto se grid ne moze rasiriti na cijeli level onda za to koriste SSR.
Znaci nije samo da su eksperimentirali pa odbacili.

1
Nova poruka
E-mail:
Lozinka:
 
vrh stranice