[ glorius @ 16.03.2010. 00:19 ] @
Napravio sam Terrain klasu i trenutno istrazujem nacine brzog renderinga.

Odlucio sam se za Octree + Frustum culling.

Jos uvek nisam implementirao ovaj algoritam ali ideja je sledeca.

Imam teren koji prvo generisem kao jedan veliki mesh i onda ga podelim na subgrids i onda napravim Octree ciji nodovi sadrze subgrids...
Pomocu frustum planes testiram visibility node-ova Octree-a i renderujem visible nodes.

Zeleo bih da iskoristim mogucnost Progressive Mesh-a (ID3DXPMesh) tako da mi svaki subgrid bude progressive mesh i u zavisnosti od udaljenosti grida u view space smanjujem ili povecavam broj vertex-a svakog vidljivog subgrida u funkciji od udaljenosti subgrida od eyepoint-a kamere.

oGooglao ali nisam nista nasao o performansama Progressive Mesh-esa... Plus, ne vidim da se mnogo forsiraju ( ili ja nisam naisao na neki source gde se oni primenjuju u slozenijim scenama ) pa me je to navelo na razmisljanje o performansama funkcija ID3DXPMesh::SetNumVertices i ID3DXPMesh::SetNumFaces. Nisam upoznat sa internim algoritmom ovih funkcija ali pretpostavljam da one generisu mesh 'on-fly' i rade po principu Optimize i MeshSmooth opcija u 3D Studio MAX-u.

Naravno, sve bih to mogao sam da testiram ali me generalno zanima kakve bi bile performanse pri koriscenju ove dve funkcije progressive mesha pri renderovanju slozenijih scena ( tipa, large terrain ).
[ tosa @ 16.03.2010. 08:21 ] @
Ima i druga opcija, Filip je napravio jedan fini terrain SDK, mogao bi da ga kontaktiras ili pogledaj: http://www.advantageterrain.com/
[ Dark Icarus @ 16.03.2010. 20:20 ] @
Evo i ja se trenutno zavitlavam oko terena mada eksperimentišem čisto edukativno, ne pokušavam ni da ciljam na neke high-end performanse ali opet...

Po onome što sam pročitao o geometrijskom mipmapingu stekao sam utisak da se sada za 2d teren najviše koristi ROAM (koji koliko kapiram radi na osnovu toga što ima detaljnu heightmapu negde iza kulisa i svaki "patch" terena počne od dva ogromna trougla i teselira se dok god je odstupanje od heightmape veće od nekog thresholda). Meni ovaj metod ne odgovara jer ne dozvoljava overhangs pa se na žalost nisam udubio u to previše.

Da li se to sada postiže preko PMesha ne znam, voleo bih da mogu više da ti pomognem :( . Mada deluju kao da rade istu stvar i ne bi me začudilo da je optimizovano sa ovim na umu.

Ako neko ima neko iskustvo sa ovim, i meni bi dobro došle.
[ glorius @ 16.03.2010. 22:19 ] @
Toso, hvala na linku, pogledacu SDK.

I ja sam malo citkario o ROAM sistemu ali nisam probao da ga implementiram ( planiram da ga proucim u buducnosti ).

Vidim da AdVantageTerrain SDK koristi velike Height mape i teksture i odmah mi je Oblivion pao na pamet :)

Dobro je poznavati vise tehnika tako da se mogu koristiti u zavisnosti od potreba aplikacije.

Meni se na prvi pogled svidela mogucnost koriscenja PMesh-eve jer stvarno olaksava rad zato sto PMesh automatizuje LOD proces i u kombinaciji sa Octree ( ili bilo kojom tehnikom za space partitioning ) moze fino da se iskoristi i za slozenije terene. Kasnije mogu da se uvedu optimizacije, itd.

Nigde nisam naisao na neki primer koji koristi ovaj nacin za renderovanje terena ali cu ga implementirati pa mozemo da prokomentarisemo rezultate :)








[ Dark Icarus @ 17.03.2010. 04:53 ] @
Javi kako si to izveo, ja ću naravno postovati rezultate ako nešto uspem da uradim :). U pravu si, nema baš mnogo konkretnih resursa sa detaljima implementacije a i ono šta ima staro je bar 3-4 godine. Svi se pozivaju na neke prihvaćene algoritme a konkretnog primera koji koristi takve algoritme - nigde :P .

Ovako il' onako i ja ću morati da imam varijabilni LOD, mada će moja implementacija verovatno biti jednostavnija od tvoje :) . Ja sam se recimo odlučio za quadtree pošto mi se sve se odvija u nekom relativno malom pojasu iznad terena tako da mi maltene nikakvu uštedu neće doneti ta treća dimenzija. Na kraju ću uraditi neki naivan algoritam sa ručnim rekalkulacijama ... za moje potrebe dovoljno... postaviću i ja svoja iskustva... jbg, možda i to nekom pomogne sutra :D.
[ Filip Strugar @ 18.03.2010. 13:18 ] @
ROAM niko ne koristi, to je iz vremena softverskog renderinga. Malo novija, ali isto matora tehnika je Geomipmapping (http://www.flipcode.com/archiv...g_Geometrical_MipMapping.shtml) koja je bila upotrebljiva u vreme prvih 3D grafickih karti i jos uvek moze da se koristi (mada neefikasno).

Za dobar/brz terrain rendering u danasnje vreme ne treba koristiti bilo sta sto kreira/modifikuje trouglove at real-time, tako da progressive meshes i slicno otpada.
Razlog za to je sto moderan CPU nije u stanju da obradi ni priblizno velik broj trouglova koliko moderan GPU (cak i low-end) moze da iscrta tako da se u mnogim slucajevima vise isplati raditi brute-force rendering nego bilo sta komplikovanije.

Za vece terene savetovao bih ChunkedLOD (http://tulrich.com/geekstuff/chunklod.html) koji je baziran na quadtree podeli i prekalkulisanoj geometriji, ili Geometry Clipmaps (http://research.microsoft.com/en-us/um/people/hoppe/proj/gpugcm/) koja crta direktno iz heightmap-e.
Moj library (www.advantageterrain.com) radi nesto slicno ChunkedLOD-u samo ima drukcije (bolje) resen prelaz izmedju razlicitih LOD levela, ali pocetna ideja je ista.

A inace upravo zavrsavam clanak & demo na tu temu, sa prikazom nove tehnike koja koristi quadtree podelu i crta direktno iz heightmape (nesto izmedju ove dve gore) - napisacu ovde kad to zavrsim & kad bude published!
[ glorius @ 18.03.2010. 14:58 ] @
Eto razloga zasto nigde nisam video PMesh-es pri terrain renderingu. :)

Jos jedna stvar koju sam primetio kod pristupa Quadtree + PMesh je da posto svaki node Quadtree-a mora biti PMesh ( isti je slucaj i ako su obicni meshevi ) cesto cu morati da switchujem vertexshadere, teksture i render states tako da se Quadtree mora drugacije organizovati. Drugim recima, Quadtree bi trebalo kalkulisati na nivou Vertex i Index buffera. Npr. imamo jedan vertex buffer koji predstavlja veliki mesh terena a svaki node sadrzi indices face-ova koji ce iscrtavati.

Quadtree sam koristio na mojoj staroj igri u OpenGL-u ( jos u vreme win98 :) ) pa sam mislio da iskoristim tu tehniku sa unapredjenjima ( kao sto je PMesh ) ali, kao sto Filip rece, sa modernim hardverom, bolje je prebaciti sto vise procesiranja na GPU tako da cu poceti da razmisljam u tom pravcu.

[ Filip Strugar @ 11.07.2010. 21:51 ] @
Alert, alert, thread necromancy!

Glorius, ako te jos uvek interesuje (ili bilo koga drugoga) terrain rendering, htedoh samo da javim da je moj clanak na tu temu konacno objavljen. Tekst, demoi i ceo source code se moze skinuti sa mog sajta.

Pozdrav,
Filip