[DirectX/VC] Grote ellende met de Vertex normals

[Sponge]

Sinds kort ben ik bezig wat C++ te leren, naast alle andere talen die ik al opgedaan heb. Ik heb al een ruime ervaring in DirectX, alleen nog nooit in 3D gewerkt.

Zo nu en dan komen ik iets tegen waar ik uren op zit, en dan gelukkig nog de oplossing voor vind, zoals de Quad Tree die ik voor m'n terrein gemaakt heb. Echter nu zit ik met een probleem, waar ik echt niet meer uitkom.. en de uren teller gaat maar omhoog en omhoog .

Mijn terrein is 128x128 gebaseerd van een heightmap die 256x256 is. Elke triangle is in principe 16 pixels breed.

Het terrein is ingedeelt dmv. een quad tree, 8x8 hokjes. Een quad is dus 128/8 = 16x16 vertices groot. Omdat we dingen een beetje efficient willen houden, zijn de vertices ook ingedeeld in quads

Dus de vertices gaan zoals dit (eerder plaatje van tijdje terug, daarom engels ):

.

(Edit, ik zie nu datdit plaatje niet helemaal klopt.. na een tijdje gaat de structuur naar beneden. alles gaat gewoon zoals de quad van 1t/m9)

Geen volledige rijen dus! Nu heb ik een stuk code om normals te berekenen die bij het terrein voorbeeld zat waarop ik mijn spul baseer. Werkt gewoon goed, op een ding na .

Wireframe ziet er goed uit:


Maar als je het solid rendert (zonder tex voor duidelijkheid)



Tevens is dit probleem met normals -denk ik- ook het probleem voor het door elkaar heen lopende terrein:



Er gaat dus iets mis in de normals berekeningen, alsof ie de randjes niet meeneemt. Maar aangezien ik door alle indices heen loop, lijkt me dat het gewoon goed komt. Ik heb al veel dingen geprobeert, zoals bijvoorbeeld niet de indices te gebruiken, maar gewoon de vertices. Gaf ook niet echt het gewenste resultaat .

Misschien heeft hier iemand ervaring met quadtrees en normals/indices, en heeft die een ideewaar ik een denk fout maak? Ik heb de situatie al meerdere keren op papier uitgewerkt, maar ik kom er niet uit.

Normal code:

code:

D3DXVECTOR3 CTerrain::GetTriangleNormal(D3DXVECTOR3* vVertex1,
D3DXVECTOR3* vVertex2, D3DXVECTOR3* vVertex3)
{
    D3DXVECTOR3 vNormal;
    D3DXVECTOR3 v1;
    D3DXVECTOR3 v2;

    D3DXVec3Subtract(&v1, vVertex2, vVertex1);
    D3DXVec3Subtract(&v2, vVertex3, vVertex1);

    D3DXVec3Cross(&vNormal, &v1, &v2);

    D3DXVec3Normalize(&vNormal, &vNormal);

    return vNormal;
}

for(i = 0; i < m_dwNumOfIndices; i=i+3)
    {
        
        dwVertex1 = pBufferIndices[i];
        dwVertex2 = pBufferIndices[i + 1];
        dwVertex3 = pBufferIndices[i + 2];

        vNormal = GetTriangleNormal(&D3DXVECTOR3(pcvVertices[dwVertex1].x, pcvVertices[dwVertex1].y,
 pcvVertices[dwVertex1].z),
&D3DXVECTOR3(pcvVertices[dwVertex2].x,
pcvVertices[dwVertex2].y,
 pcvVertices[dwVertex2].z), 
 &D3DXVECTOR3(pcvVertices[dwVertex3].x, 
pcvVertices[dwVertex3].y,
 pcvVertices[dwVertex3].z));

        
        pNumOfSharedPolygons[dwVertex1]++;
        pNumOfSharedPolygons[dwVertex2]++;
        pNumOfSharedPolygons[dwVertex3]++;

        pSumVertexNormal[dwVertex1].x += vNormal.x;
        pSumVertexNormal[dwVertex1].y += vNormal.y;
        pSumVertexNormal[dwVertex1].z += vNormal.z;
        
        pSumVertexNormal[dwVertex2].x += vNormal.x;
        pSumVertexNormal[dwVertex2].y += vNormal.y;
        pSumVertexNormal[dwVertex2].z += vNormal.z;

        pSumVertexNormal[dwVertex3].x += vNormal.x;
        pSumVertexNormal[dwVertex3].y += vNormal.y;
        pSumVertexNormal[dwVertex3].z += vNormal.z;
    }

    
    //Unlock the index buffer
    m_pIndexBuffer->Unlock();

    for(i = 0; i < m_dwNumOfVertices; i++)
    {
        vNormal.x = (float)pSumVertexNormal[i].x / pNumOfSharedPolygons[i];
        vNormal.y = (float)pSumVertexNormal[i].y / pNumOfSharedPolygons[i];
        vNormal.z = (float)pSumVertexNormal[i].z / pNumOfSharedPolygons[i];

        D3DXVec3Normalize(&vNormal, &vNormal);

        pcvVertices[i].nx = vNormal.x;
        pcvVertices[i].ny = vNormal.y;
        pcvVertices[i].nz = vNormal.z;
    }

Dus als iemand enig idee heeft.. . Ik ben echt radeloos aan het worden. . Ik hoop dat ik ook genoeg info gegeven heb...

[ Voor 7% gewijzigd door Sponge op 27-09-2004 11:05 . Reden: code breedte gefixed ]

[.oisyn]

Je moet je normalen niet berekenen aan de hand van je triangles, omdat niet elke vertex dezelfde soort triangles om zich heen heeft (zo heeft een vertex bijvoorbeeld wel connecties met de vertices linksboven en rechtsonder, maar niet met die van rechtsboven en linksonder). Beter kun je gewoon uit gaan van de vertex en de 4 vertices die het om zich heen heeft (boven, onder, links, rechts).

Ook denk ik niet dat je hier rekening houdt met de triangles die naast een "quad" liggen (ik vind je quad een nogal verwarrende benaming, omdat het in 3d computer graphics ook een afkorting is voor quadrilateral, wat vierhoek betekent). De vertices op de rand van je quad hebben dan alleen verbindingen met de vertices die ook in de quad liggen, en op die manier krijg je dus nooit mooi aansluitende normalen (als quad1 en quad2 naast elkaar liggen, dan zou de meest rechter vertex op de bovenste rij van quad1 dezelfde normaal moeten hebben als de meest linker van quad2).

Normalen genereren uit een heightmap kan heel gemakkelijk. Per vertex initialiseer je de normaal op (0, 1, 0) (recht omhoog dus). Voor de x-richting trek je de richtingscoëfficient van y in de x-richting van je huidige vertex naar de vertex rechts daarvan af van de coëfficient van de vertex links ervan naar de huidige. Hetzelfde doe je voor de z, en vervolgens normaliseer je de normaal.

In pseudocode, v is de huidige vertex, left (v) geeft de vertex links van v etc.

C++:

function calcNormal (v)
{
    nx = ((v.y - left(v).y) - (right(v).y - v.y)) / (v.x - left(v).x);
    nz = ((v.y - up(v).y) - (down(v).y - v.y)) / (v.z - up(v).z);
    return normalize (nx, 1, nz);
}

[ Voor 64% gewijzigd door .oisyn op 27-09-2004 17:06 ]

[Sponge]

.oisyn, Ik zal eens kijken of het me lukt. .

Het probleem licht inderdaad voornamelijk in het feit dat die quad (dus een quad tree vierkant) niet meegenomen worden. Echter is de structuur tijdens het opbouwen meteen al gemaakt voor het efficient renderen, zoals je in de getalletjes kunt zien, hierboven. Gene lange rijen, maar direct alle vertices meteen al ingedeeld in stukken van 16x16.

Daarnaast komt de indexbuffer not die alles nog complexer maakt, door de quadtree volgorde te kiezen, uiteindelijk zal ik dus niet:

1 2 3 4 hebben, maar

1 2
3 4

(dat is dus voor 4 quadtree vierkanten), en om deze aan elkaar te laten "plakken", daar kom ik echt niet uit .

Maar goed, ik zal eens kijken of het me lukt via de heightmap...

[Sponge]

Hm, het huidige resultaat is



Ik zal het nog even na lopen, maar volgens mij doe ik het wel volgens bovenstaande function

[Sponge]

Ik den kdat ik er maar mee stop. Ik krijg het gewoon niet voor elkaar, en na 20 uur hier op gezeten te hebben, heb ik het onderhand echt gehad.

Ik kreeg net nog het idee om een tweede indexbuffer te maken die gewoon row/col werkt, uiteraard werkt het niet, omdat dat gewoon te mooi zou zijn geweest.

(Overigens komt dit imo alleen maar omdat de vertices in vierkanten ingedeelt zijn, zodat ik ze met de quad tree makkelijk offset/length kan renderen.)

[.oisyn]

Het stukje code van de normalen uit mijn vorige post klopt idd niet. Ik ga uit van de verschillen tussen de richtingen van de huidige vertex naar z'n aanliggende vertices, maar feitelijk is de positie van de huidige vertex helemaal niet van belang. Je kunt dus volstaan door het verschil in hoogte tussen de rechter en linker vertex te delen door de afstand in x-richting tussen die twee, en eveneens voor de z-richting. Daarnaast moet je het negatieve verschil nemen omdat de normalen anders de andere kant op gaan staan.

Wederom in pseudo-code:

C++:

function calcNormal (v)
{
    nx = (left(v).y - right(v).y) / (right(v).x - left(v).x);
    nz = (up(v).y - down(v).y) / (down(v).z - up(v).z);
    return normalize (nx, 1, nz);
}

Merk trouwens op dat alle vertices op vaste afstand van elkaar liggen, (right(v).x - left(v).x en (down(v).z - up(v).z) zijn dus constant en staan simpelweg voor 2 maal de afstand tussen 2 vertices in resp. x- en z-richting

Heb het gelijk maar even getest voor ik nog meer onzin uit ging kramen, en dit werkt idd

[ Voor 4% gewijzigd door .oisyn op 28-09-2004 03:02 ]

[-=bas=-]

[support - mode]

Ik den kdat ik er maar mee stop. Ik krijg het gewoon niet voor elkaar, en na 20 uur hier op gezeten te hebben, heb ik het onderhand echt gehad.

Dit is juist het moment waarop je niet op moet geven.
Als je denkt dat je ellende meemaakt, wacht dan maar tot je echt met DirectX aan de slag gaat. Dan krijg je pas echt een bak ellende voor je neus waar je niet goed van wordt.
DirectX lijkt leuk en aardig, maar de documentatie is niet echt fantastisch waardoor je tegen allerlei zaken aanloopt (zoals je nu doet) die misschien met goede documentatie zo opgelost zouden zijn.

Come on chap! You're almost there! (Zeker met de laatste post hierboven)

[/support - mode]

[.oisyn]

_bas_ schreef op 28 september 2004 @ 03:25:
wacht dan maar tot je echt met DirectX aan de slag gaat.

Doet ie toch al?

DirectX lijkt leuk en aardig, maar de documentatie is niet echt fantastisch waardoor je tegen allerlei zaken aanloopt (zoals je nu doet) die misschien met goede documentatie zo opgelost zouden zijn.

Que? DirectX slechte documentatie? Dude, het is zo ongeveer de best gedocumenteerde API die ik ooit ben tegen gekomen :D!. Ik had iig geen problemen met mijn overstap van het alom slecht gedocumenteerde OpenGL naar het geweldig gedocumenteerde Direct3D

[Verwijderd]

.oisyn schreef op 28 september 2004 @ 03:00:
(...)
[afbeelding]

Whee, leuk man ! Dit wil ik ook kunnen.

Zijn er literaire aanraders op dit "vlak" ?

[Sponge]

Goed, gisteren was ik even hopeloos . Maar ik heb weer moed, en als het niet lukt ga ik m'n vertices weer op de traditionele row-based manier plaatsen, ik heb al een theorietje uitgewerkt die niet eens zoveel performance verlies zal veroorzaken. Misschien nog wel beter dan deze quadtree, omdat op dit moment er maximaal 64x drawprimitive gebruikt wordt... Echter kan ik met de andere manier het aantal vertices niet op 16x16 houden per quad, maar wordt het al 16*128...

_bas_ Ik werk al met DirectX sinds versie 5, destijds nog met een typelib in VB . Toen was er geen documentatie, laat staan tutorials. Tegenwoordig is het stukken beter.

Back to work

[Sponge]

Verwijderd schreef op 28 september 2004 @ 08:49:
[...]

Whee, leuk man ! Dit wil ik ook kunnen.

Zijn er literaire aanraders op dit "vlak" ?

Ik denk dat de termen ongeveer zijn:

Fractal / Heightmap
Multi texture
C++
(Geo mipmapping?)

Er zijn een aantal boeken, maar die heb ik nog nooit bekeken (staan wel ergens onder een kopje op www.gamedev.net). (Ik leer het liefts door gewoon te proberen)

[Sponge]

OK. Dit gaat al beter.




Die "San andreas breuk" zit vast ergens in een dom foutje, lijkt mij.
Heb je enig idee waarom die vierkantjes zo zichtbaar blijven .oisyn*? Ik snap niet precies hoe die veroorzaak wordt namelijk. (Dacht eerst te grote stapjes voor de verts, is niet zo)

*Zo beter Osiris?

Ten tweede blijven de heuvels zo nu en dan doorzichtbaar. Ik heb de Zbuffer aan staan. Ik
vermoed dat dit echter te verwijten valt aan m'n lieve ouwe trouwe Voodoo3 met ene 16 bit Z-Buffer. Toch maar eens gaan upgraden denk ik..

btw: Je terrein ziet er idd echt netjes getextured uit

Ik kreeg een idee door je code, en gebruik nu een gemiddelde, met een texture zijn de vierkantjes ook al stuk minder duidelijk (zal wel gewoon normal lighting zijn) met een LOD (meer tri's) zal datr misschien wel beter zijn, maar i kzit niet echt op een LOD systeem te wachten



Nu alleen nog die doorzichtige stukken terrain. hm

[ Voor 33% gewijzigd door Sponge op 28-09-2004 22:34 ]

[.oisyn]

Sponge schreef op 28 september 2004 @ 08:49:
Misschien nog wel beter dan deze quadtree, omdat op dit moment er maximaal 64x drawprimitive gebruikt wordt...

1 DrawPrimitive per quad? Je bedoelt trouwens toch wel DrawIndexedPrimitive he? Slecht idee, je kunt beter een dynamische index buffer vullen en dan je hele landschap (datgene wat je zichtbaar hebt bevonden natuurlijk) in één keer tekenen met een enkele DrawIndexedPrimitive call. Het helpt overigens wel als je vertices sequentieel in je buffer staan, je sizeof (vertex) 24 of een veelvoud van 32 is (dus padden!), en je rekening houdt met het feit dat de vertex cache vroeger (vanaf de GeForce 1 zeg maar) uit 8 en tegenwoordig (meestal, ik meen vanaf de geforce fx serie) uit 16 vertices bestaat. Bij het inlezen van 9 verschillende indices wordt de eerste vertex dus weggegooid en komt de 9e daar dus in de plaats. Als je daarna weer de eerste wilt gebruiken moet ie opnieuw worden ingelezen en getransformeerd.

Overigens heb je het steeds over je quadtree alsof het hele landschap en de manier waarop de vertices ingedeeld zijn daar ook toe behoren. Feitelijk is een quadtree slechts een boomstructuur, de onderliggende geometrische data en topologie doen er verder weinig toe

[.oisyn]

Sponge schreef op 28 september 2004 @ 09:02:
Heb je enig idee waarom die vierkantjes zo zichtbaar blijven Osiris?

Dude, ik heet .oisyn, ga mij niet verwarren met Osiris want dat vind ik een grove belediging

Ik snap niet precies hoe die veroorzaak wordt namelijk. (Dacht eerst te grote stapjes voor de verts, is niet zo)

Hmmm, ik zie het eigenlijk ook niet zo, het lijkt erop alsof je normalen nog steeds niet echt kloppen... Ik kan het niet zo goed zien aan het plaatje, maar misschien is je heightmap gewoon niet vloeiend genoeg? Blur het hele zaakje eens, kijken hoe het dan wordt.

Ten tweede blijven de heuvels zo nu en dan doorzichtbaar. Ik heb de Zbuffer aan staan. Ik
vermoed dat dit echter te verwijten valt aan m'n lieve ouwe trouwe Voodoo3 met ene 16 bit Z-Buffer. Toch maar eens gaan upgraden denk ik..

Wheehehe, dan is mijn vertex cache verhaal van hierboven niet eens relevant

Zijn ze echt doorzichtig, of zijn het eigenlijk gewoon zwart gekleurde vertices die niet transparant zijn (render eens op een witte achtergrond)? In het geval van dat laatste is er nog steeds iets met je normaalberekening, als ze echt doorzichtig zijn kloppen je indices ergens wellicht niet (foute waarden, of een geflipte edge waardoor de triangles ineens backfacing worden en ze dus geculled worden).

btw: Je terrein ziet er idd echt netjes getextured uit

4 textures met coefficienten op basis van hoogte en steilheid

[Sponge]

.oisyn schreef op 28 september 2004 @ 12:34:
[...]


1 DrawPrimitive per quad? Je bedoelt trouwens toch wel DrawIndexedPrimitive he? Slecht idee, je kunt beter een dynamische index buffer vullen en dan je hele landschap (datgene wat je zichtbaar hebt bevonden natuurlijk) in één keer tekenen met een enkele DrawIndexedPrimitive call. Het helpt overigens wel als je vertices sequentieel in je buffer staan, je sizeof (vertex) 24 of een veelvoud van 32 is (dus padden!), en je rekening houdt met het feit dat de vertex cache vroeger (vanaf de GeForce 1 zeg maar) uit 8 en tegenwoordig (meestal, ik meen vanaf de geforce fx serie) uit 16 vertices bestaat. Bij het inlezen van 9 verschillende indices wordt de eerste vertex dus weggegooid en komt de 9e daar dus in de plaats. Als je daarna weer de eerste wilt gebruiken moet ie opnieuw worden ingelezen en getransformeerd.

Overigens heb je het steeds over je quadtree alsof het hele landschap en de manier waarop de vertices ingedeeld zijn daar ook toe behoren. Feitelijk is een quadtree slechts een boomstructuur, de onderliggende geometrische data en topologie doen er verder weinig toe

Mja, DrawIndexPrimitive, uiteraard. Ik kort graag dingen af die logisch zijn (slechte eigenschap). Ik had ook al bedacht om het als volgt te doen:

- Recursief Quad tree af lopen.
- Als we bij de leafs aangekomen zijn, kijken of de hele parent Quad zichtbaar is, zo ja, laagste offset + aantal indices gebruiken.

Maar goed, hoe ik dat uit eindelijk ga doen boeit me niet zo hee lerg, eerst maar een model in kunnen laden, en animeren. Als dat lukt kan het echte werk beginnen, resource managers e.d.

Overigens ga ik (ben ik niet van plan iig) geen rekening houden met aparte kaarten en de eigenschappen die ze hebben, Datis me te fout gevoelig. (En overigens vaak ook nog driver afhankelijk)

Mijn quadtree leaves zijn gelijk aan de "hokjesheid" van m'n vertices, vandaar dat ik het als een term gebruik...

.oisyn schreef op 28 september 2004 @ 12:53:
[...]


Dude, ik heet .oisyn, ga mij niet verwarren met Osiris want dat vind ik een grove belediging


[...]


Hmmm, ik zie het eigenlijk ook niet zo, het lijkt erop alsof je normalen nog steeds niet echt kloppen... Ik kan het niet zo goed zien aan het plaatje, maar misschien is je heightmap gewoon niet vloeiend genoeg? Blur het hele zaakje eens, kijken hoe het dan wordt.


[...]


Wheehehe, dan is mijn vertex cache verhaal van hierboven niet eens relevant

Zijn ze echt doorzichtig, of zijn het eigenlijk gewoon zwart gekleurde vertices die niet transparant zijn (render eens op een witte achtergrond)? In het geval van dat laatste is er nog steeds iets met je normaalberekening, als ze echt doorzichtig zijn kloppen je indices ergens wellicht niet (foute waarden, of een geflipte edge waardoor de triangles ineens backfacing worden en ze dus geculled worden).


[...]


4 textures met coefficienten op basis van hoogte en steilheid

Hehe, ja.. Osiris zie ik constant op IRC, dat ik me wel eens vergis

Overigens heb ik het doorzichtigheid op gelost door een defecte ZBuffer te fixxen, en het terrein filter ik ondertussen ook door ene 8 punts filter, wat al een stuk beter eruit ziet .

Mja 4 textures . Dat wordt een two-pass op een Voodoo, met wolken zelfs een 3 pass. Ik zal daar nog eens wat creatiefs voor verzinnen (nieuwe videokaart+shader ofzo ). Volgens mij kan je nml 4 textures via de R/G/B channels van een andere texture netjes unnen blenden in slechts 1 pass...

[Zoijar]

Verwijderd schreef op 28 september 2004 @ 08:49:
Zijn er literaire aanraders op dit "vlak" ?

Mijn scriptie binnenkort Kom alleen niet tot schrijven...tiled parallel CLOD met 16kx16k terrein en realtime compressie. (maar dat is niet het 'even' doen, het zijn meer dan 8k regels tight C++, zonder de engine )

Overigens kan je dynamisch terrein nooit goed shaden met alleen vertex normals. Je zal toch echt aan ofwel lightmaps, ofwel pixel shaders moeten denken. Het probleem met lightmaps is weer dat je vaak beperkt bent tot iets van 1024x1024 textures oid. En dat je veraf eigenlijk veel te veel detail in je texture hebt.

Literatuur links:

code:

@article{ lindstrom96realtime,
    author = "P. Lindstrom and D. Koller and W. Ribarsky and L. Hodges and N. Faust and G. Turner",
    title = "Real-Time Continuous Level of Detail Rendering of Height Fields",
    journal = "Proceedings of SIGGRAPH'96",
    pages = "109--118",
    year = "1996",
    url = "citeseer.ist.psu.edu/lindstrom96realtime.html"
}

@misc{ rottger98realtime,
  author = "S. Roettger and W. Heidrich and P. Slussallek",
  title = "Real--Time Generation of Continuous Levels of Detail for Height Fields",
  text = "Roettger, S., Heidrich, W., Slussallek, P., Seidel, H-P.: Real--Time Generation
    of Continuous Levels of Detail for Height Fields, Proc. 6th Int. Conf. in
    Central Europe on Computer Graphics and Visualization, pp. 315--322, 1998.",
  year = "1998",
  url = "citeseer.ist.psu.edu/391228.html"
}

@inproceedings{duchaineau97roaming,
    author = "Mark A. Duchaineau and Murray Wolinsky and David E. Sigeti and Mark
 C. Miller and Charles Aldrich and Mark B. Mineev-Weinstein",
    title = "{ROAMing} terrain: real-time optimally adapting meshes",
    booktitle = "{IEEE} Visualization",
    pages = "81-88",
    year = "1997",
    url = "citeseer.nj.nec.com/duchaineau97roaming.html"
}


@misc{jonathan2000,
    author = "Jonathan Blow",
    title = "Terrain Rendering at High Levels of Detail",
    conference = "Game Developers' Conference, San Jose, California, USA",
    year = "2000"
}

@misc{lindstrom01visualization,
  author = "P. Lindstrom and V. Pascucci",
  title = "Visualization of large terrains made easy",
  text = "P. Lindstrom and V. Pascucci. Visualization of large terrains made easy.
    In Proceedings of IEEE Visualization 2001, pages 363--370.",
  year = "2001",
  url = "citeseer.nj.nec.com/lindstrom01visualization.html"
}

@misc{lindstrom02terrain,
  author = "P. Lindstrom and V. Pascucci",
  title = "Terrain simplification simplified: A general framework for view-dependent
    out-of-core visualization",
  text = "P. Lindstrom and V. Pascucci. Terrain simplification simplified: A general
    framework for view-dependent out-of-core visualization. IEEE Transaction
    on Visualization and Computer Graphics, 8(3):239--254, 2002. 2, 8",
  year = "2002",
  url = "citeseer.nj.nec.com/lindstrom02terrain.html"
}

@inproceedings{hoppe2004clipmaps,
    author = "F. Losasso, H. Hoppe.",
    title = "Geometry clipmaps: Terrain rendering using nested regular grids.",
    journal = "ACM SIGGRAPH 2004, to appear."
    year = "2004"
}





@inproceedings{ colormap,
    author = "Alan D. Kalvin, Bernice E. Rogowitz, Adar Pelah, Aron Cohen",
    title = "Building Perceptual Color Maps for Visualizing Interval Data",
    conference = "SPIE Conference on Human Vision and Electronic Imaging V",
    year = "2000",
    month = "Jan"
}

@book{cgpp,
 author = {James D. Foley and Andries {van Dam} and Steven K. Feiner and John F. Hughes},
 title = {Computer graphics: principles and practice (2nd ed.)},
 year = {1990},
 isbn = {0-201-12110-7},
 publisher = {Addison-Wesley Longman Publishing Co., Inc.},
}



@phdthesis{ compression,
    author = "Flemming Friche Rodler",
    title = "Compression with Fast Random Access",
    school = "BRICS, Department of Computer Science, University of Aarhus",
    year = "2001",
    month = "Nov"
}

@book{ibmmpi,
    author = "Scott Vetter, Yukiya Aoyama, Jun Nakano",
    title = "RS/6000 SP: Practical MPI Programming",
    year = "1999"
}

@inproceedings{ dollner00texturing,
    author = "Jurgen Dollner and Konstantin Baumman and Klaus Hinrichs",
    title = "Texturing techniques for terrain visualization",
    booktitle = "{IEEE} Visualization",
    pages = "227-234",
    year = "2000",
    url = "citeseer.ist.psu.edu/dollner00texturing.html"
}

@inproceedings{pascucci,
 author = {Valerio Pascucci and Randall J. Frank},
 title = {Global static indexing for real-time exploration of very large regular grids},
 booktitle = {Proceedings of the 2001 ACM/IEEE conference on Supercomputing (CDROM)},
 year = {2001},
 isbn = {1-58113-293-X},
 pages = {2--2},
 location = {Denver, Colorado},
 doi = {http://doi.acm.org/10.1145/582034.582036},
 publisher = {ACM Press},
 }

[ Voor 111% gewijzigd door Zoijar op 28-09-2004 16:55 ]

[Sponge]

Mijn terrein is niet dynamisch .

Overigens zit ik nu op 50 FPS. .als ik alles eerst naar de indexbuffer kopieer, en dan dat in een keer render. Snap niet waarom.

[Sponge]

Hier is eens wat code, Misschie ndoe ik het wel opeen super trage manier ofzo...

Voor elke leaf

code:

            //If this vertex number is lower, we will update it accordingly.
            if (pNode->MinVertex < StartVertex)
                StartVertex = pNode->MinVertex;

            if (pNode->MinVertex+pNode->NumVertex > NumVertex)
                NumVertex = pNode->MinVertex+pNode->NumVertex;
            
            //NumVertex += pNode->NumVertex;
            
            //We need the total amouynt of indices.
            Indices += pNode->IndicesLength;

            //Copy the amount of indices ,add lastindexposition for new start position
            memcpy((&pBufferIndices[0]+dwLastIndexPosition), pNode->wIndices, pNode->IndicesLength * sizeof(WORD));
            
            //Update new position for next quad.
            dwLastIndexPosition += pNode->IndicesLength;

Het eerste deel is om te bepalen wat de uiteindelijk start en eind vertex wordt, uiteindelijk zullen we super veel vertices onnodig transformeren, helaas .

Stukje code om de IB te locken:

code:

//Lock QuadTree first
    //Get a pointer to the index buffer indices and lock the index buffer    
    g_pGame->objTerrain->m_pIndexBuffer->Lock(0, g_pGame->objTerrain->m_dwNumOfIndices * sizeof(WORD), (BYTE**)&pBufferIndices, 0);

    //Perform quadtree check:
    CheckQuadTree(0);
    
    //Unlock the index buffer
    g_pGame->objTerrain->m_pIndexBuffer->Unlock();
    
    //Only call this when we really need to
    if (Indices > 0) {
        g_pGame->objTerrain->Render(0,(Indices/3),StartVertex,(NumVertex-StartVertex));
    }

De FPS vliegt heel snel (compiled) naar 50 fps, als er een paar stukke nterrain zichtbaar zijn...

Edit: laat ik het eerst maar eens updaten wanneer het zichtbare veranderd ipv. elke frame...

[ Voor 7% gewijzigd door Sponge op 28-09-2004 19:56 ]

[Sponge]

Hm, blijft nog steeds erg laag vergeleken met de eerste versie die alleen de nodige vertices renderde.. Maar goed, ik hou het nu nog even bij m'n voodoo3 denk ik.

Helaa,s op een radeon 9200 of 9200 op een AMD XP 2400 oid gaat het ook nog tussen de 120 en 70.. voor maar max 128x128 verts

(Overigens was dit al dat alleen de memcopy uitgevoerd werd wanneer ik de camera bewoog)


---------

Edit: Zojuit oude code geprobeert, dus maximaal 64x een DrawIndexedPrimitive, die overigens wel dus precies 16x16 vertices per stuk doet (geen onnodige trnasforms), zit meteen tegen de 90fps aan op mijn pc, en 170+ o pde bovenstaande recentere PC... beetje vreemd..

[ Voor 43% gewijzigd door Sponge op 28-09-2004 20:49 ]

[Zoijar]

Waarom draai je niet gewoon even een profiler? Dan weet je precies waar er het meeste tijd wordt besteed

[.oisyn]

Is je index buffer wel dynamic? En waarom lock je dan niet met D3DLOCK_NOOVERWRITE als je slechts wilt toevoegen of D3DLOCK_DISCARD als je hele nieuwe contents hebt?

[Verwijderd]

Mensen even dit: beseffen jullie dat een polygon(surves) die bestaat uit 4 vertexen (of meer), nooit een correcte richt kunnen hebben (dus ook een normaal), terwijl een polygon die bestaat uit 3 (driehoek) vertexen ALTIJD een juiste richting hebben. Of praat ik hier naast de kwestie?

[.oisyn]

wat is een polygonsurve, wat bedoel je in hemelsnaam en waarom kick je een topic van pakweg 9 maanden oud?

[Verwijderd]

Ik ben zelf nog maar net bezig met OpenGL (uhu ) op mijn Mac G5, heb een koppel boeken gekocht en ik ben ongeveer al 70 blz. ver. Ik ben nu ook (eventjes) vast gelopen op normalen berekenen. Het lijkt me dus nu reeds al zeer logisch dat de polygons met 3 vertexen (verontschildig mijn vrije vertalingen en zo) de eenigste zijn die een korrekte rivhting kunnen hebben om dat die de primitiefste vorm zijn om een polygon aan te duiden. Laten we maar zeggen dat die met meer vertexen bestaan uit verschillende polygonnen (!) van 3 vertexen. daarvoor is het niet logisch om de normaal te berekenen van "Quads" (vierkanten toch?)

.oisyn schreef op zaterdag 11 juni 2005 @ 23:00:
wat is een polygonsurve, wat bedoel je in hemelsnaam en waarom kick je een topic van pakweg 9 maanden oud?

Ik bedoelde: surface.

Al ik ongelijk heb of volledig naast de kwestie spreek, verbeter mij GRAAG, ik leer ook nog maar net e

[Verwijderd]

ik heb het nog eens na gelezen. hoe dan ook de polygon MOET vlak zijn om de normaal te kunnen berekenen. DUS om er ZEKER van te zijn dat een polygon vlak (plat) is gebruik je best driehoeken, omdat bij een direhoek alle vertexen altijd in het zelfste vlak liggen. Omdat bij een vierkant 1 van de vier vertexen in een ander vlak kunnen liggen en DUS in feite 2 driehoeken beschrijven.

ik hoop dat dit duidelijker is.

Je kan het altijd zelf eens na lezen. Ik gebruik het volgende boek : OpenGL Programming Guide 4de editie. Dit is te lezen in Appendix E: Calculating Normal Vectors.

In deze appendix maakt men het onderscheid tussen Analitische Vlaken (dit zijn vlakken die op een wiskundige manier verkregen worden) en Polygonnale vlaken. Naar mijn mening kun je dus de Analytische vorm niet toepassen, omdat je gebruik moet maken van de vertexen om de normaal te berekenen.

Nog een Tip: DE LENGTE van de normaal MOET 1 zijn (normalizeren), maar dat hadden jullie vast al wel geweten. Waarom zeg ik dit dan: hij mag niet -1 zijn, wan dan krijg je dus het resultaat van culling. Zorg er dus voor dat de vertexen voor een polygen in CCW (Counter Clock Wise) beschreven worden.

Mag ik nog van dienst zijn. Ik kom regelmatig kijken

[Verwijderd]

Nog even dit. Je berekent dus de normalen van vertexen op zo'n manier dat de vlaken smooth in elkaar overvloeien. Smooth maken is de tweede stap.

De eerste stap is de normalen berekenen voor alle vlakken met behulp van de omschrijvende vertexen.

Om de tweede stap te bekomen dien je nadien de gemiddelden te zoeken voor de vertexen, met behulp van de direct omliggende vlaken. Dus elke vertex appart, los van het vlak dat het op dat moment omschrijft.

Klop dit?

[Zoijar]

Min of meer... iha gebruik je ook triangles, want meer dan 3 punten hoeven niet in hetzelfde vlak te liggen. De lengte van een vector kan overigens nooit negatief zijn, het is nl. de wortel uit de som van de kwadraten van de componenten, en die is nooit negatief. Waar je op doelt is het inproduct met de view vector en je normaal, dan kan je bepalen tegen welke kant van het vlak je aankijkt. Inproduct kan je op twee gebruikelijke manieren opvatten; ofwel de hoek tussen twee vectoren, ofwel de schaal factor voor de ene vector, om een loodrechte projectie daarop te krijgen van de andere.

Vertex normalen berekenen moet je bij oppassen dat je het goed middeld of smoothing groups gebruikt oid. Doe het maar eens bij een kubus bestaande uit triangles, beste oefening.

[Verwijderd]

Zoijan, wat stelt deze dan voor?

[v1 - v2] x [v2 - v3] = vn

deze kreeg ik mee vanuit mijn boek (ik ga er meestal vanuit dat boeken niet liegen, maar zich best ook wel eens kunnen vergissen).

"To find the normal for a flat polygon, take any three vertices v1, v2 and v3 of the polygon that do not lie in a straight line. The cross product is perpendicular to the polygon. etc."

Wat je daar aan haalt met de wortel uit de som van de producten, is dat niet "normalizeren"? Of te wel de lengte van de vector berekenen en dan elk component van de vector daar door te delen?

[Zoijar]

Dat is een kruis product, dat geeft een nieuwe vector die loodrecht op beiden input vectoren staat. Je maakt hier dus twee vectoren aan die de 'edges' van je driehoek zijn, en berekent dan een nieuwe die loodrecht op beiden staat, maw de normaal. Maar de lengte van die vector die je nu berekent is gelijk aan de oppervlakte van het parallelogram dat de twee input vectoren maken, ie. iha. niet 1. Voor veel berekeningen is het handig als de lengte van je vectoren 1 is, omdat je dan efficienter kan rekenen. Dus bereken je de lengte, en schaal je de vector met '1/lengte', deze wordt dan lengte 1, ie. vn/|vn|, en |vn| = sqrt(v1*v1 + v2*v2 + ...)

ik raad je aan hier een goeie tekst over te lezen; het is wiskundig helemaal niet zo moeilijk. Het komt vooral neer op weten hoe je alles kan interpreteren (dat geldt voor lineaire algebra in het algemeen ook: zien dat twee verschillende dingen eigenlijk hetzelfde zijn.)

[ Voor 20% gewijzigd door Zoijar op 12-06-2005 14:06 ]

[Verwijderd]

thanks mate

[.oisyn]

even wat nitpicken

Verwijderd schreef op zondag 12 juni 2005 @ 10:48:
vertexen (verontschildig mijn vrije vertalingen en zo)

vertexen is idd correct Nederlands , hoewel de meeste Nederlandse developers en wetenschappers die ik ken / iets van gelezen heb, gewoon het Engelse woord 'vertices' lenen.

"Quads" (vierkanten toch?)

Vierhoek, een vierkant is een figuur met 4 rechte gelijke zijden

[Verwijderd]

Nitpicken mag. Gelukkig zijn we visueel wiskundigen e