Ma apucasem sa fac un teren mare si dupa ce l-am texturat i-am facut tiling mare sa s vada frumos DE APROAPE langa camera. Insa de departe se vede oribil tilingul mare.


Acuma cum sa fac ca terenul mare sa aiba o textura sau doua de baza cu tiling mic sa se vada bine de la departare dar totusi langa camera sa fie tiling mare eventual niste calcule in plus pentru normal mapping sau alte minuni.

Daca as adauga alta textura tilata mult, peste cea de baza a terenului cum fac ca sa nu apara si la departare. Ca sa fac calcule de alphablending in pixel shader cred ca ar fi prea naspa (asta ca o idee random).
Ca sa fac multe texturi pe ditai terenu iar nu-mi convine. Apoi mai e tranzitia lor daca fac mai multe texturi.

daca vrei o textura chiar asa de mica ..incearca sa bagi niste texturi care nu au diferente mari de culoare ... cum e albu ala spre deosebire de galben ..daca ar fi o textura seamless ,de nisip ceva mai usor de "tillat" ti-ar iesi sigur mai bine .. oricum incearca o rez mai mare

Sau ai putea sa faci ca in orice joc si sa, stii tu, pui chestii pe el. Vegetatie, munti, rauri, drumuri, case si inamici; si sa nu ai numa un singur tip de teren. Nici nu mai e loc sa observi problema!

Asta, si foloseste o textura mai uniforma, nu cu pata aia alba in mijloc.

Dar pentru detalii sa zicem normal map la drum cat is in apropiere eventual chiar si parallax mapping. Nu ar fi prea performant sa fac la tot terenu (care sa zicem are un drum lung) parallax mapping. Sau o textura cu care sa fac specular doar in anumite zone. Asta cred ca iar s-ar vedea naspa de la distanta si ar fi neperformant. Etc..

Efectele astea sunt per-pixel, asa ca un drum lat de 5m e lat de doar cativa pixeli cand e la distanta. Daca stai la nivelul terenului, atunci "in departare" reprezinta mai putin de 10% din suprafata ecranului, pe cand "aproape" reprezinta peste jumate din ecran.

WoW are per-pixel specular + specular maps, si nu mi sa miscat niciodata incet. (la 1280x800 AAx4)

Utilizeaza detail textures:

tex #1 - diffuse- tiling mic cateva blocks, 3x3 or smtg..
tex #2 - detail- tiling mare, like 100x100, pt camera, ai grija ca textura sa fie granulata, adica sa nu aiba "entitati" de imagine f mari, sa fie gen ciment, nisip uniform, f multe pietricele, sau iarba

multiply blend astea doua layere, multiply si cu shadowmap sau ce ai tu pe acolo si voila, awesome terrain ( and some subtle vertical-horiz. fog )

O mica smecherie pe care o poti face cu detail textures e sa modifici mipmap-urile (in cazul in care vorbim despre un DDS). Ideea e sa faci ultimele mipmap-uri (ultimele 4-5) sa fie doar o culoare (complet gri, sau complet alb), iar urmatoarele 2-3 sa le faci tranzitie intre adevaratul mipmap si o culoare uniforma. Astfel obtii detaliu mare de aproape, si teren smooth de departe

Scuze ca am raspuns cam tarziu dar ideea ta este foarte foarte buna. Am si testat si merge destul de ok doar cu cateva mici probleme cand se vad ciudat putin unele triunghiuri cand se schimba nivelul terenului. Dar in schimb tranzitia intre mipuri e foarte fina. Tre sa bibilesc texturile alea mai mult sa iasa perfect. Ms mult pentru sfat

Nicio problema. Si eu am citit chestia asta pe alte forum-uri, si o dau mai departe

Am observat ca si cel mai mica diferenta de poligoane la teren schimba drastic performanta. Si as vrea sa incerc sa implementez un algoritm de reducere a numarului de triunghiuri pentru o anumite portiune departata de camera a terenului.

Am citit documentul ala de pe cartea GPU GEMS 2 - Terrain Rendering using GPU-Based Geometry Clipmaps si nu inteleg cum reuseste sa randeze celelalte portiuni de teren cu mai putini vertecsi. Adica nu prea am inteles nulte din el.

Am inteles ca folosesc vertex textures sa memorez geometria x,y a terenului si inca o textura pentru z (heightmap). Dar la departare cand vad alte bucati de teren ele cum sunt efectiv randate cu mai putini vertecsi daca vertex shader ruleaza la fiecare vertex indifierent de textura aia ?

Sau randez terenul o singura data cu un numar fix de vertecsi dar care sunt modificati in functie de texturile alea (mai multi langa mine, mai putini departe)? Dar si asta pare cam imposibil de realizat.

Mai in termeni pentru prosti imi poate explica cineva pas cu pas ?

Cea mai simpla chestie e sa spargi terenul in mai multe bucati si sa desenezi fiecare bucata cu LOD-ul ei. Fiecare e un draw call, fiecare are vertex buffer propriu, end of story. Cind trebuie sa schimbi LOD-ul, generezi alt vertex buffer sau incarci altul de pe disc sau cum vrei. O metoda banala de a genera vertex buffere cu LOD este sa iei height map-ul si sa sari pixeli. Pentru LOD0 fiecare pixel e un vertex. Pentru LOD1 sari cite un pixel, deci o sa ai de 4 ori mai putini vertecsi. Pentru LOD2 sari din 4 in 4 si tot asa cite nivele vrei.

Chestia asta va duce la sparturi intre bucatile de LOD diferit, ca nu se va mai pupa numarul de vertecsi dintr-unul cu vertecsii din celalalt. Se rezolva foarte simplu, mai desenezi niste triunghiuri care conecteaza vertecsii mai multi de pe latura bucatii cu LOD mai mic cu vertecsii mai putini de pe latura bucatii celeilalte. Procesul se numeste "stitching", e foarte simplu de implementat daca stai cu un pix si o foaie si te gindesti 5 minute. Inseamna inca un draw call pentru fiecare pereche de laturi pe care trebuie s-o cirpesti.

De aici se pot face o multime de alte lucruri. Poti reduce numarul de draw call-uri comasind bucatile cu acelasi LOD prin diverse trick-uri obscene de index buffer. Poti comasa si geometria de stitch cu si mai multe trick-uri. Poti observa ca draw call-urile sint tot timpul grid-uri regulate cu acelasi numar de vertecsi (dupa comasare) si sa folosesti un singur vertex buffer pentru grid, plus inca un vertex stream per-call pentru inaltimi (ceea ce e prea multa bataie de cap pentru beneficiile aduse, dupa parerea mea si chinuie cache-urile). Poti observa ca de fapt merge prost din cauza ca desenezi grid-ul in ordinea naturala, ceea ce face varza cache-ul post-TnL si sa reordonezi index buffer-ul ca sa folosesti respectivul cache in mod optim (e banal pentru grid-uri regulate). Poti compresa vertecsii terenului observind ca sint suficienti 4 bytes pentru pozitie (X si Z 1 byte, Y 2), ca poti calcula coordonatele de texturi in shader din pozitie, deci nu trebuie sa le stochezi si ca normala incape in 2 bytes. Poti reciti articolul despre clipmaps, care va fi mai inteligibil dupa ce incerci chestiile de baza, dar valoarea lui practica nu-i asa de mare. Poti face un miliard de alte chestii cu geometria, dupa care inca 2 miliarde de chestii cu shading-ul (splatting, megatextures, tile maps etc.), da' intii fa chestiile de baza, care-s evidente.

LE: nu mai fugiti la carti si google pentru orice mizilic. Solutia cu spartul in mai multe bucati e banala si ar trebui sa apara imediat daca te gindesti un pic singur. Evident, nu-i state-of-the-art, nu se foloseste in incarnarea sa cea mai simpla in AAA-uri, da' nu lucrezi la un AAA. Toata smecheria e sa experimentezi acum cit poti, ca sa intelegi bazele. E bine sa reinventezi roata aici, ca asa a inceput toata lumea, inclusiv aia care au facut solutiile mai complexe, gen clipmaps. Nu s-a trezit unu' intr-o dimineata cu clipmaps sau geomorphing sau cine stie ce in cap. Intii s-a gindit la solutia banala, a inteles-o, a inteles care-s problemele ei, dupa care s-a gindit cum s-o imbunatateasca. Daca reinventezi solutia banala fara google si carti, intelegi. Daca te uiti direct la chestii avansate, o sa fii in ceata mai mult timp.

M-am gandit la spartul terenului in mai multe bucati ba chiar facusem o varianta unde bucatile erau progressive meshed (generate cu functia din Dx).

Ma documentasem dintr-o carte unde scria ca daca folosesc ProgressiveMesh mi se reordoneaza vertecsii (pentru un edge colapse corect cred) si nu mai sunt atat de bine aranjati pentru cache. Si de asta ma gandeam ca poate ar fi vreo metoda mai buna.

Conflictul dintre progressive meshes si vertex cache se poate aplana folosind multi-level PM (vezi aici toate detaliile posibile si imaginabile despre VIPM). Da' oricum, eu n-am zis progressive meshes, am zis LOD-uri discrete, cu tranzitii discrete. Dezavantajul e ca ai popping cind se schimba LOD-ul, dar poate sa nu conteze (terenul are iarba, pomi si case pe el), sau se poate pili pina e acceptabil (geomorphing e o idee). Avantajele sint ca poti face sa ai cache usage optim si e absolut banal de implementat.

Nu stiu nici un joc care sa aiba VIPM pentru teren mare (stiu jocuri cu VIPM pentru toata geometria, dar cu nivele mici unde "terenul" e un mesh facut in Max, ca orice altceva), dar stiu o groaza care au LOD discret (cu popping cu tot).