[C++/OpenGL] snelheidsissues

[Arjan]

Goedendag,

ik kom een snelheidsprobleem tegen bij het schrijven van een openGL app. Ik probeer een soort engine te maken die VMRL files in kan lezen en deze kan weergeven. Dat is mij al gelukt, maar ik zit nu nog met het probleem dat ik niet de volledige snelheid krijg die ik verwachtte.

Ik gebruik een method genaamd draw om mijn object op het scherm te toveren en zo ziet deze eruit:

C++:

glLoadIdentity();
glRotatef(rotate,1,1,1);
glBegin(GL_TRIANGLES);
glColor4f(color[0], color[1], color[2], 1-color[3]);
for(int i=0; i<cordInd.size(); i++) {
   if(!norm.empty() || !normInd.empty()) {
      glNormal3f(norm[normInd[i]*3], norm[normInd[i]*3+2], norm[normInd[i]*3+1]);
   }
   if(!texCord.empty() || !texCordInd.empty()) {
      glTexCoord2f(texCord[texCordInd[i]*2], texCord[texCordInd[i]*2+1]);
   }
   glVertex3f(cord[cordInd[i]*3], cord[cordInd[i]*3+2], cord[cordInd[i]*3+1]);
}
glEnd();

Hiermee schrijf ik dus de polygonen naar het scherm. De polygoon data bevind zich dus in de volgende vectoren:
vector<float> cord
vector<float> texCord
vector<float> norm
vector<int> cord
vector<int> texCord
vector<int> norm

Het probleem is dat elke draw aanroep ~400ms duurt op een AMD64 2800+, Radeon 9600 256Mb.
Dat is veel te lang en mijn vraag is dan ook, waar ligt dit aan?
(het gaat hier overigens wel om een testobject met 160.000 faces, maar een willekeurige VRML viewer gooit dit met 25+ fps op het scherm!)

De totale polygoondata zal ongeveer 10Mb in beslag nemen, dus datatransfer lijkt mij niet de bottleneck?

Ik ben erg benieuwd waar het aan ligt, alvast bedankt!

[Obliterator]

Probeer een een glError om te kijken of er misschien ergens iets mis zit.
Je kunt ook de vendor string controleren. Misschien krijg je wel de Microsoft software rasterizer ipv je radeon omdat je een vreemd pixelformaat aanvraagt?

Het enige dat me verder nog te binnenschiet is de vraag of vector je garandeerd dat de data aaneen gesloten zit. Anders kan het accessen van de data wel eens meer tijd kosten dan je denkt.

[Verwijderd]

Tja immediate mode is nou eenmaal niet zo snel. Voor elke vertex die naar de videokaart gestuurd wordt heb je een functie call nodig, en dit genereert nogal wat overhead. Kijk eens naar VBO's of display lists, die zijn speciaal bestemd om grote batches te renderen.

[Zoijar]

Je kan eens "gDebugger" proberen. Maar ik denk ook dat de vertraging komt door de immediate mode. Maak er een display list van, of gebruik VBOs. Wat MIIM al zei...

[Arjan]

Obliterator schreef op donderdag 27 april 2006 @ 19:51:
Probeer een een glError om te kijken of er misschien ergens iets mis zit.
Je kunt ook de vendor string controleren. Misschien krijg je wel de Microsoft software rasterizer ipv je radeon omdat je een vreemd pixelformaat aanvraagt?

Het enige dat me verder nog te binnenschiet is de vraag of vector je garandeerd dat de data aaneen gesloten zit. Anders kan het accessen van de data wel eens meer tijd kosten dan je denkt.

Hoe zou ik de vendor string kunnen controleren?
ik gebruik openGL in combinatie met SDL. (opt moment onder windows xp)

Verwijderd schreef op donderdag 27 april 2006 @ 20:15:
Tja immediate mode is nou eenmaal niet zo snel. Voor elke vertex die naar de videokaart gestuurd wordt heb je een functie call nodig, en dit genereert nogal wat overhead. Kijk eens naar VBO's of display lists, die zijn speciaal bestemd om grote batches te renderen.

Dat is wellicht een oplossing, maar is volgens mij best wat werk om werkend te krijgen als ik het goed lees op inet.

Zoijar schreef op donderdag 27 april 2006 @ 20:39:
Je kan eens "gDebugger" proberen. Maar ik denk ook dat de vertraging komt door de immediate mode. Maak er een display list van, of gebruik VBOs. Wat MIIM al zei...

Display lists lijken mij dé oplossing voor mijn probleem, ga ik even proberen

[edit]
Heren bedankt!

display lists gebruiken bleek idd de ideale oplossing, maar je moet natuurlijk wel even weten dat ze bestaan

[ Voor 6% gewijzigd door Arjan op 27-04-2006 21:40 ]

[Zoijar]

Een VBO is volgens mij nog sneller, omdat display lists voor zover ik weet niet in je video memory worden opgeslagen. Het scheelt alleen de overhead van al die OGL API calls. Er is trouwens ook zo iets als een vertex array call, dan kan je gewoon die hele array in je vectors in een keer doorgeven. Je hoeft er niet doorheen te loopen en steeds glVertex() te callen etc (zie glVertexArray() en dingen als arb_vertex_buffer_object)

[.oisyn]

Obliterator schreef op donderdag 27 april 2006 @ 19:51:
Het enige dat me verder nog te binnenschiet is de vraag of vector je garandeerd dat de data aaneen gesloten zit.

Dat is de hele reden dat een std::vector bestaat, dus ja, dat is gegarandeerd

[Zoijar]

Misschien dat je hier http://www.spec.org/gpc/opc.static/vbo_whitepaper.html nog iets aan hebt