I’m trying to use a display list that draws 2.5 Million polys. It compiles the list OK but when it tries to draw it, it continuously pages to disk giving me a frame rate of 0.2. Is this a known problem with display lists? I’ve experimented with various numbers of polys and its ok up untill about 1.5 Million. I have 128Mb of RAM, I really dont think its because the app has run out of local memory. Heres the code, mesh rows=1600,mesh columns=800.
Thanks.
glBegin(GL_TRIANGLE_STRIP);
for (i = 0; i < mesh_columns-mesh_columnstep; i += mesh_columnstep)
{
glColor3ubv(mesh_colours[i][j]);
glNormal3fv(mesh_normals[i][j]);
glVertex3fv(mesh_vertices[i][j]);
glColor3ubv(mesh_colours[i][j2]);
glNormal3fv(mesh_normals[i][j2]);
glVertex3fv(mesh_vertices[i][j2]);
}
glEnd();
OK well i was hoping display lists were storing the data more efficiently then they seem to be.
Interestingly using bytes instead of floats makes no difference to the display list memory requirements, probably because the display list compiler converts and stores them as floats.
I suggest you to use VertexArrayz instead…
You’ll be able to cache them and of course you’ve got the advantage to access all the primitive’s data with your own structure format!!! (watch out the stride stuff)…
Moreover it’ll speed your rendering!!
that’s it!!
except, of course, the vertex arrays are ALSO stored in memory. An idea would be to carefully think about how you can reuse meshes, rather than just storing every single vertex in memory.
Well I converted easily to using glArrayElements and that slowed things down a bit :/. I’ve heard that glDrawyArrays is faster and with a bit of work I can convert to that (means restructuring my data). I’ve heard that glDrawElements is the fastest but from what I understand that doesnt render with color or normals?! what good is that I must be missing something.
Basically I want the maximum triangle throughput without using display lists(since they cant cope with my mesh size) Im not bothered that the fps will be about 2 and I dont want to use any LOD algorithms. There is a good reason for all this and when I get it working better I will post a URL to what I am doing.
Adrian, I have just checked specs for glDrawElements and you should be able to use the same arrays than for glDrawArrays or glArrayElement, including normals or whatever !
Thanks for the feedback, I’ll look into increasing the zoom speed. To get round the slowness you could reduce the resolution before rotating and zooming and then increase it again when you’ve finished positioning. Was the 0.3 fps at the highest resolution (13x13) or the default (26x26)? What was your TPS? I would have expected a better frame rate looking at your system spec.
But the problem is the card. I don’t know how many colors bits you used(maybe you used indexed mode) and how many depth buffer bits you used, but it makes a lot of difference on that card. I’ve also set the card to full quality instead of speed! So I could probably get higher. And I am also at 1024X768!
By having fun with the settings of my driver I could boost the
26X26 from 0.33 to 0.90 frames
and I was getting 0.51 tps
higher I was easily getting over 1.20.
You application is really not fill limited presently it is transform limited because you have way too much geometry: At whatever resolution the fps is the same.
Here are some optimisations :
Occlusion culling. Since the geometry is your bottleneck, you need to cut it down. And since you only use a sphere, I think we can do something fast. I’ll look into it and come back to you later on that
Orthogonal lighting. You should check that out in the developer section of this site. This will reduce the geometry without losing much quality.
It’s a bit too late for me to do some research. I already have a fast method for sphere for occlusion culling, but it only works if you only rotate the sphere around one axis. I am trying to make it work for any axis. I’ll probably write an update on the forum this week-end or tomorrow
1. Occlusion culling
Yes, it can help. Especially in zoomed state…
2. Orthogonal lighting. You should check that out in the developer section of this site. This will reduce the geometry without losing much quality.
For the best result you need to use adaptive surface simplification (or you may loose some mountains )
My results:
PIII-500, ELSA Gloria L/MX (GLINT MX, no hw geometry)