Advertisement

Display lists from planet Slow

Started by December 12, 2000 09:22 PM
8 comments, last by Gamgee 23 years, 11 months ago
Hey everyone. Great forum. I''ve been lurking for a while and decided that I might see if some of the talent on this forum could help me. I have one question that can be solved in two ways. I have been developing an OpenGL program around vertex arrays. I implemented my own ASE loader, generated both face and vertex normals for my objects. I was using glDrawArrayElements to render my models. I was getting well over 300fps on my PII350 w/ geforce. I started running into problems with applying texture coordinates read from the ASE file - I can''t seem to get them working. So I switched to display lists, compiled everything and got 20 frames per second! Now, display lists are not that slow are they? I must be doing something stoopid. I am using lighting, backface removal, depth testing, etc. I am NOT using textures yet - just lit faces. I am setting up the lighting once in the scene. What could be making the thing so damn slow?? My display list is just this: (psModel->nDlist is just an int, nGeom is the number of meshes in the model, for a cube there is only one mesh, two tris per cube face) psModel->nDlist = glGenLists(1); glNewList( psModel->nDlist, GL_COMPILE ); // construct the model object(s) for ( i = 0; i;j++) { glBegin(GL_TRIANGLES); glNormal3fv(psModel->psObject->psFace[j]->vecNormal); //glTexCoord2fv(psModel->psObject->psFace[j]->vec2tc[0]); glVertex3fv(psModel->psObject->psFace[j]->vecVertex[0]); //glTexCoord2fv(psModel->psObject->psFace[j]->vec2tc[1]); glVertex3fv(psModel->psObject->psFace[j]->vecVertex[1]); //glTexCoord2fv(psModel->psObject->psFace[j]->vec2tc[2]); glVertex3fv(psModel->psObject->psFace[j]->vecVertex[2]); glEnd(); } } glEndList(); I could always go back to vertex arrays if someone can help me with texture coordinates… I am basically doing this: glEnableClientState(GL_TEXTURE_COORD_ARRAY); glTextureCoordPointer (2, GL_FLOAT, psModel->psObject[n]->vec2texcoords); The structure of the texcoord array and the way that OpenGL accesses it is not well documented. The docs lump texture coord arrays in with vertex, colour and normal array (all of which I have working) but do not provide any specific detail on using texture coord arrays. From what I can tell, there are two ways it could work: Per vertex texture coordinates: vertexcoords[8][2] = { s0, t0, s1, t1, s2, t2, s3, t3, … } where s0 is the s coord for vertex 0 or Texture coords per vertices in a face: { f0s0, f0t0, f0s1, f0t1, f0s2, f0t2, f1s0, f1t0, f1s1, f1t1, f1s2, f1t2, … } … Where f0 is face 0, and s0 is the s coord for the first vertex in the face. I''m not sure here. I''m guessing #2. I have implemented both with texture coordinate data read from my ASE file, but neither works… all I get is a cube that takes on the colour of the edge of the texture map because it has not been mapped properly (if I use a fudge auto texture generation i get a slightly better result on some faces - it''s not a texture problem eg: wrapping; it definately a coordinate problem) I have checked out Nate''s ASE loader tutorial, but he uses display lists rather than texture coordinate arrays (which is one of the reasons I tried using them in the first place). Any assistance will help save more hairs on my head. Thanks in advance!! </i>
This might sound really stupid, but you''re not in someway compiling the display list each time through... are you?
Advertisement
No, that's not a stupid question at all hehe... but I'm not doing that

Originally with vertex arrays, my render part did something like this:

// various scene stuff
// push matrices
// do rotation transforms of model
// do translation transforms of model
glEnable(GL_VETEX_ARRAY);
glVertexArrayPointer( ... );
glEnable(GL_INDEX_ARRAY);
glIndexArrayPointer( ... );
glDrawElements( ... );
// pop matrix

With the above, I got 300+ fps when drawing a lit cube.

After creating the vertex arrays in my init() code (as in my original post), I replaced all the array stuff with the following:

// various scene stuff
// push matrix
// do rotation transforms of model matrix
// do translation transforms of model matrix
glCallList(psModel->nDlist);
// pop matrix

So effectively all the gl statements for the vertex array collapsed into one for the display list - and my framerate went down to 20fps.


Edited by - Gamgee on December 13, 2000 5:28:15 PM
So, nobody knows?
This might not help but I had a similar problem with my voodoo3 2000. If I was in fullscreen mode the display list would go faster in windowed mode it would go slower. I haven''t tryed display list''s lately so I don''t know it that problem still exsist on my card or not. Takeing this into account I''d say it might be the way the drivers are working!
Otherwise I''d suggest setting up another program specifically to test the problem. i.e. make a cube and call the cube rendering function to draw the cube. see what you get for a frame rate. Then put the cube draw into a display list and call the display list to draw the cube. and see how the frame rate changes. Do this for both windowed and fullscreen modes.
you might need to draw more than one cube so you can get a realistic account of the frame rate. I''d try this with between 10 cubes and 100,000 cubes to see what kind of results you get at differing complexitys.
If you do this I''d be interested in what kind of results you get.
------------------------------Piggies, I need more piggies![pig][pig][pig][pig][pig][pig]------------------------------Do not invoke the wrath of the Irken elite. [flaming]
Thanks for responding - that could be possible.

I did try with a more complex object. The framerate was pretty steady. I went from 20fps with a cube (12 polys) to about 18fps with an object that had about 250 polys.

I think my decision for now is the dump the display lists and go back to the vertex list approach. Later on when I get stuff working there I''ll re-visit the issue.

Now all I need to do is work out how openGL interprets texture coordinate arrays...

Advertisement
display list r good for certain things but not everything.
my opinion is u aint drawing the same thing with dl as vertex arrays. u know a stopid mistake ''hit yourself on head one'' though ive gotta admit 18-20fps even 200fps seems quite slow 4 what ure doing(not in 1600x1200 mind)

http://members.xoom.com/myBollux
No, it''s just a real simple display list.

I think the display list problem has to do with my geforce drivers. I read somewhere that people have experienced similar problems with display lists on geforce cards.

I''m now trying to work out the texture coordinate array issue, so if anyone has any ideas about how texture coord arrays work, I''d be pleased to hear them.
the texture array works same like the vertex array and the normal array (in smoth shading) and the colorvertex array (dont remember the name..)

VECTOR v[3];
fill(v);
VECTOR2D texcoords[3];
glVertexPointer(v);
glTexCoordPointer(texcoords);
and now when you draw a poli with 0,1,2 (a triangle, wow..),
it draws it with

glTexCoord2fv(texcoords[0]);glVertex3fv(v[0]);
glTexCoord2fv(texcoords[1]);glVertex3fv(v[1]);
glTexCoord2fv(texcoords[2]);glVertex3fv(v[2]);

just for every vertex a .. position (vertexarray), a normal (normalarray), a color value (colorarray), and a texcoordinate (texcoordarray) (with extensions for every textureARB an array..)




we wanna play, not watch the pictures

If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

Thanks! That''s a huge help.

So, if I use glDrawElements to construct polys from an with an index array and a vertex array, then does the texture coordinate array need an entry for each vertex, or does it need one for each vertex in each polygon?

Example:

A cube has 8 vertices and 12 polys (2 triangles per face). To texture map the cube, do I:

1) need 8 elements in my texture coordinate array (one for each vertex), or

2) need 36 elements in my texture coordinate array (3 vertices for each poly, times 12 polys)

I''m guessing 2)...

This topic is closed to new replies.

Advertisement