RAW 3DE este o abreviere pentru Reconstruction of Ancient Worlds in a 3D Environment, fiind in esenta un engine de randare.
Spre deosebire de cele mai multe engine-uri Open Source actuale al nostru incorporeaza o serie de tehnologii puternice care ii permit sa iasa in evidenta.
La prima vedere, unele dintre capabilitatile engine-ului sunt:
randare la distante mari
randare cursiva a unui numar mare de poligoane
incarcari de interioare
scalabilitate
consum mic de resurse
frustum culling
control LOD (nivel de detaliu; Level Of Detail control)
modele si texturi optimiazate
coliziuni bazate pe OBB-uri (oriented bounding box collision detection)
coliziuni bazate pe sfere
instantiere de obiecte
iluminare bazata pe shaderi
sky box bazat pe shaderi
meniuri 3D
afisare de informatii la cererea utilizatorului
La baza engine-ului sta ideea de turism virtual.
Tehnologii
Visual Studio 2008, 3D StudioMax 2008, SDK DirectX 9.0c iunie 2008, PhotoShop CS3, Luxology Modo 2.03, Curious Labs Poser 6
Cerinte sistem
Procesor 1 GHz
256 MB Ram
400 MB spatiu pe HDD
Placa video compatibila cu DirectX 9.0c si cu suport pentru Shader Model 2.0 support
Am si eu o intrebare: De ce ati ales sa folositi o gramada de poligoane, in loc sa gasiti un echilibru intre geometrie si textura?
Cu cateva modificari, puteati avea un detaliu mult mia bun cu o viteza mai mare. Am vazut gardulete facute din geometrie, cand 1 textura era de ajuns, detaliu fin pe modele care se putea face cu un normalmap, poligoane in plus in locuri cu importanta foarte mica (exemplu scaunele din restaurant).
Spre exemplu, cam acelasi numar de poligoane il are si Crysis pe ecran, insa acolo e vorba de o jungla, cateva cosmelii, munti, apa, caractere, vehicule.
Totusi, e de apreciat munca depusa in modelele 3d.
Cu atat mai usor este acum sa modelati versiuni mai simple si sa creeati normal-maps din obiectul detaliat. (stiu sigur ca 3D Studio MAX are si optiunea asta).
As vrea sa va mai sugerez 2 lucruri cu ocazia asta:
1. Ambient occlusion. In 3d studio max, folosind mental ray, se poate face o textura de ambient occlusion pentru modele. O sa imbunatateasca aspectul considerabil.
2. Umbre. Inteleg ca la momentul actual, e aproape imposibil sa mai ruleze la o viteza decenta odata cu integrarea umbrelor, tocmai de aceea e necesar sa reduceti numarul de poligoane. Umbrele, de asemenea, vor adauga foarte mult detaliu in scena.
In orice caz, va urez succes. E un proiect care arata binisor si are potential
EDIT: In scena cu arcul de triumf, cladirile din jur au un “flickering” destul de neplacut. Banuiesc ca este vorba de dynamic LOD. Inca un motiv bun sa treceti detaliul pe normalmaps: LOD-ul va intra in functiune de la distante mai mari, unde va fi observat mai putin.
Poate au bagat atatea poligoane tocmai pentru a demonstra ca engine-ul lor poate sa duca atatea…si putand duce atatea, o data ce modelele sunt optimizate ca numar de vertecsi, se va putea trece si la alte efecte mai avansate fara probleme de viteza.
Ok, inteleg ca ati vrut sa demonstrati ce poate engine-ul. Puteati face un stress test simplu in cazul asta, nu sa folositi o scena ca stress test
So, uite o sugestie: Ati putea automatiza procesul pt. a face un obiect low-poly + normalmap dintr-unul high-poly. Asta ar pastra scopul programului de a fi accesibil celor care stiu sa modeleze si in acelasi timp ar oferi un nivel mai mare de detaliu la o viteza mai mare.
In cazul in care vreti sa pastrati cat mai putin lucru de texturare din partea celor care creeaza content-ul, atunci puteti incerca sa implementati SSAO (Screen-Space Ambient Occlusion), dar mi-e teama ca o sa sara cerintele la Shader 3.0. (desigur, si acest feature va fi optional).
Nu am apucat sa ma documentez prea mult despre LDPRT, dar e bine de stiut ca lucrati la iluminare Intotdeauna iluminarea are o importanta mare in calitatea finala a imaginii.
Intr-adevar ideile din spatele engine-ului sunt viteza si eficienta. Greseala cea mai frecventa a celor ce programeaza aplicatii 3D real-time este aplicarea optimizarilor la sfarsitul procesului de implementare a facilitatilor. Desigur ca soft-ul ajunge sa fie impresionant intr-un timp scurt dar optimizarea unui cod care deja a atins sute de mii de linii este tortura curata. Pe un sistem cu RadeonX1950 am reusit sa randam chiar si 20 de milioane de poligoane la 29fps. Pe langa asta se adauga faptul ca X1950 este totusi cu 3 generatii in urma modelelor din prezent.
Iar pentru a-i raspunde lui jimanjr: O tehnica de iluminare (LDPRT) este deja in lucru, alaturi de un algoritm de Parallax Occlusion Mapping dar din cauza complexitatii acestor metode devoltarea lor cere mult timp si atentie. In plus cele doua nu se impaca tocmai bine. Trebuie convinse sa colaboreze. Dificultatea lucrului cu codul provine din faptul ca engine-ul este integral dezvoltat de noi si la fel sunt toate metodele care apar in el. Nu am folosit nimic inafara de SDK-ul de DirectX si Visual Studio pentru programare. Ideile sunt preluate din carti, prelucrate, adaptate si optimizate pentru engine.
Am pus mult accentul pe poligonaj fiindca am gandit aplicatia ca fiind in primul rand un instrument de creatie rapida si accesibila celor ce stiu sa modeleze si sa plaseze 2-3 obiecte in scena. Suportul pentru lumini si parallax o sa fie optional pentru a permite scalabilitate. Chiar si in prezent engine-ul scaleaza bine, la setari minime afisand cam a 16-a parte din poligoane (dar in limita pastrarii formei obiectelor).
Ai dreptate. Un normal map si o textura ar fi rezolvat multe dintre acele detalii fine din modele. Dar nu asta era scopul. O textura cu alpha daca nu are in spate un shader puternic de multe ori arata artificial si din unele unghiuri devine chiar deranjanta. Detaliul in model a fost modul nostru de a demonstra eficienta engine-ului. Un fel de simulare de Crysis(daca tot ai facut comparatia). Nu am avut cum sa redam o insula(atat pe timp de vara cat si de iarna), o nava extraterestra si alte medii intinse astfel ca am pus acelasi numar de poligoane pe ecran cu ajutorul unor modele dense.
