OpenGL GL_TRIANGLE_STRIP index-generering.

[Klette]

Sliter litt med en algoritme for å få laget en index-liste over rekkefølgen på hvilke vertices som skal tegnes.

Verticelisten er generert utfra et heightmap, og lagres i en interleaved array (ikke at det har noe med saken å gjøre her egentlig )

Det er i alle fall blitt generert 4 vertices pr pixel i heightmapet, dvs i dette tilfellet 128x128x4 vertices som skal sorteres for bruk av triangle_strip. (Z-form langs x-axen)

 

Her er funksjonen jeg har nå:

void Terrain::generateIndices(int numInd, int width, int height)
{	
int curPos = 0;
this->indices = new unsigned int[numInd];
cout << "Number of indices to order: " << numInd << endl;

for(int y = 0; y < height*1; ++y)
{
 for(int x = 0;  x < width*1; ++x)
 {
 	indices[curPos] = y*width + width + x;
 	indices[curPos+1] = y*width + x;
 	curPos += 2;
 }
}

cout << "Done calculating " << curPos << " indexes" << endl;
/*for(int i = 0; i < numInd; i++){
 cout << indices[i] << endl;
}*/
}

 

Den fungerer helt greit på den første raden, men er jo et problem med stiching her.

Sliter også litt med å få den til å regne ut riktig antall indexer.

 

Noen tips?

[jajajalla]

Heisann, poster et svar her likeså greit jeg, men snakker vel med deg etterpå.

Forresten, det er mildt sagt vanskelig å bruke TRIANGLE_STRIP sånn du ar skrevet

koden, det bare vanskeligjør ting utrolig mye. Hvis du bruker bare GL_TRIANGLES

på koden med denne index-funksjonen så tror jeg det skal virke.

Men husk at det tegnes width * height * 2 triangler, noe som vil si

at du må gi ogl width * height * (2 * 3) vertex-indekser når den tegner

med bare triangler da, og det er vel i alle fall i utganspunktet det letteste.

 

mvh

 

void Terrain::generateIndices(int widht, int height)
{
int curX = 0, curY = 0;
int currentIndex = 0;
int curVertex = 0;

//Create some room in our array, width * height * 6
//because that is how many vertexes we need when we draw.
//Now remember to draw width * height * 6 vertexes!
indices = new unsigned int[width*height*6];

for(curY=0;curY<height;curY++){
 for(curX=0;curX<width;curX++){
 	//Top left corner of first triangle
 	indices[currentIndex] = curVertex;
 	currentIndex++;
 	//Top right corner of first triangle
 	indices[currentIndex] = curVertex + 2;
 	currentIndex++;
 	//Bottom left corner of first triangle
 	indices[currentIndex] = curVertex + 1;
 	currentIndex++;
 	
 	//Bottom left corner of second triangle
 	indices[currentIndex] = curVertex + 1;
 	currentIndex++;
 	//Top right corner of second triangle
 	indices[currentIndex] = curVertex + 2;
 	currentIndex++;
 	//Bottom right corner of second triangle
 	indices[currentIndex] = curVertex + 3;
 	currentIndex++;
 	
 	//Go to the next quad
 	curVertex+=4;
}

[Klette]

Dog, da blir jo tearing et problem, uten striping altså...

[sexyme]

Tror nesten det blir feil jeg?

[Dustwave]

3 Sofister:

a) Georgias (483-374)

b) Trasymachos (479-400) “Rett er makt”

c) Pytagoras (481-411)

”Mennesket er alle tings mål”

 

Legg spesielt merke til den siste!

 

Var dette svar på det du lurte på?

[jajajalla]

Dog, da blir jo tearing et problem, uten striping altså...

Hvorfor skulle det bli det?

[Klette]

Du husker vi snakket om den ene hvite pixelen alene i et heightmap?..

 

Anyway, ahr fikset det, paster koden etterpå, har den ikke her (er ikke hjemme).

[jajajalla]

Du husker vi snakket om den ene hvite pixelen alene i et heightmap?..

 

Anyway, ahr fikset det, paster koden etterpå, har den ikke her (er ikke hjemme).

Kk, poenget mitt var uansett bare at TRIANGLE_STRIP ville gjøre kodinga mye vanskeligere. Når du kan oppnå akkurat det samme med mindre koding, og, hvis

du først laster opp alt til skjermkort-minnet, lik ytelse.

Endret 6. september 2005 av jajajalla

[Giddion]

Jeg kan ikke si jeg har teste ut tri vs tri-stripe ved bruk av FBO (OGL) , men tri-strip er ikke så mye vanskligere. Desuten vil tri-strip bruke mindre minne uansett hvordan du gjøre det. Når det gjelder display list (OGL) så er det driver relatert.

Men jeg vil gjerne vite åssen implimintering du snakker om ved opplasting til skjermkortet?

[Klette]

rett og slett at man laster opp dataene til agp-minnet.

http://developer.nvidia.com/object/Using_GL_NV_fence.html er en teknikk, veldig enkel og implementere, men kun nvidia da :\ (ps, bør kun brukes på statiske objekter (noe som ikke forandrer seg ) )

[jajajalla]

Jeg kan ikke si jeg har teste ut tri vs tri-stripe ved bruk av FBO (OGL) , men tri-strip er ikke så mye vanskligere. Desuten vil tri-strip bruke mindre minne uansett hvordan du gjøre det. Når det gjelder display list (OGL) så er det driver relatert.

Men jeg vil gjerne vite åssen implimintering du snakker om ved opplasting til skjermkortet?

Ta en titt på disse funksjonene,

glBindBufferARB;

glDeleteBuffersARB;

glGenBuffersARB;

glBufferDataARB;

glGetBufferParameterivARB;

og, bare så det er sagt, jeg mener, hvis man har x-antall vertexer, og y antall

vertexer, og de ligger inntill hverandre, da vil man når man "pakker"(kommer

ikke på noe bedre ord for det i farten) disse vertexene slik at hver vertex med en

viss koordinat aldri blir gjentatt. Det vil altså si at det eneste man kan tjene noe på

minnemessig er indekseringa når man bruker STRIP.

 

mvh

[GeirGrusom]

tri strips bruker ikke mindre minne, og tar mer prosessorkraft, jeg ville anbefalt å bruke GL_TRIANGLES, og det er ikke GL_FENCE du tenker på Klette, du tenker på GL_NV_VERTEX_ARRAY_RANGE som øker ytelsen veldig, men som bare finnes på GeForce3+ og er nv-only, fencing er ikke alltid nødvendig.

 

Det finnes en implementering i OpenGL 1.5 for å legge data på skjermkortet på en ordentlig måte som heter buffer objects (som jajajalla nevner), men om det blir lagret som en overfladisk, eller fullstendig kopi i AGP minne, vet jeg egentlig ikke.

 

Men det er irrelevant, fordi du egentlig ikke trenger å legge terreng data på skjermkortet, men heller bruke en BSP algoritme (som octree) for å øke hastigheten.

[Klette]

vertex_array_range er beskrevet i det dokumentet

[Giddion]

Hvis objektet er statisk hvorfor da ikke bare bruker display lists?

En ting til, jeg så en test i Nvidia SDK der tri-strip blir demonstrert og det var en måte å sende dataene som hete kalt tri-list og dette var færre indisier enn tri-strip og større fps. Dette var DX, men finnes det noe lignende i OGL?

[Klette]

Prinsippene er vel det samme?...

 

Vertex-arrays fungerer ikke i display lists.... eller, du kan gjerne putte inn en vertex-array i en display list, men du vil ikke tjene noe på det, får den vil bli tegnet på "sin måte" hver gang alikevel.

[GeirGrusom]

heh, hos meg står GL_NV_FENCE i GL_NV_VERTEX_ARRAY_RANGE dokumentet -> nVidia OpenGL SDK

Du trenger egentlig ikke fencing.

 

vertex arrays er en bedre metode en å bruke display lists.

 

Skal du tegne terreng er det ikke sikkert du trenger index buffer heller, ihvertfall ikke hvis du vil ha unike tekstur koordinater for hver celle, da er det bedre å kalle glDrawBuffers.

 

Det jeg bruker for å tegne:

 

glVertexPointer

glNormalPointer

glClientActiveTextureARB

glTexCoordPointer

glDrawBuffers (eller glDrawElements)

[jajajalla]

heh, hos meg står GL_NV_FENCE i GL_NV_VERTEX_ARRAY_RANGE dokumentet -> nVidia OpenGL SDK

Du trenger egentlig ikke fencing.

 

vertex arrays er en bedre metode en å bruke display lists.

 

Skal du tegne terreng er det ikke sikkert du trenger index buffer heller, ihvertfall ikke hvis du vil ha unike tekstur koordinater for hver celle, da er det bedre å kalle glDrawBuffers.

 

Det jeg bruker for å tegne:

 

glVertexPointer

glNormalPointer

glClientActiveTextureARB

glTexCoordPointer

glDrawBuffers (eller glDrawElements)

Hmm, dette ble en stor quote, men samme her!

Endret 8. september 2005 av jajajalla

[GeirGrusom]

Men som jeg sa tidligere, octree er et must hvis du skal tegne terreng, plutselig øker ytelsen 400% eller noe.

[jajajalla]

Men som jeg sa tidligere, octree er et must hvis du skal tegne terreng, plutselig øker ytelsen 400% eller noe.

Har ikke rotet meg til å skrive noe octree-greier ennå, personlig

synes jeg ytelsen økte heftig mye bare ved vertex-buffer-object.

Har lest en del om det så det er bare å finne et ledig øyeblikk å begynne og skrive da!

[GeirGrusom]

jeg fant et ganske genialt prosjekt på sf

glew

 

Siden glh_extensions og glh_genext er så utrolig buggy, så er den utrolig kjekk å ha, den legger inn alle extensions uten at du trenger å tenke på glh_init_extension, og GLH_EXT_SINGLE_FILE tøyset.