Display list size problem

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.

glNewList(mesh_list, GL_COMPILE);

for (j = 0; j < (mesh_rows-mesh_rowstep); j += mesh_rowstep)


for (i = 0; i &lt; mesh_columns-mesh_columnstep; i += mesh_columnstep)




umm. 2.5 million polys, eh? in a display list… stored in memory. yep… that sounds like page thrashing to me

really, 2.5 million polys at 3 verticies per poly, at 3 coordinates per pixel at 4 bytes per cordinate is 85 meg of mesh

don’t use a display list for geometry that is THAT complex. generate the data on the fly, if you must.


on the fly == immediate mode, btw

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!!

Good luck!

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 !



Yeah you’re right, thanks. My book’s not very clear

Ive got DrawElements working now, getting similar performance to Display lists with less memory.

For anyone whos interested this is what I’m working on http://www.dialspace.dial.pipex.com/voodoopeople/Mars3d.htm

hey Adrian.

Your Mars looks good!!! Keep up the good work. Could you release the .exe, I d’like to see it live!!

i think it’s easier to buy a spaceship,fly over to mars and take some pictures of it, than programming this thing… :slight_smile:

Thanks Gorg, you can download it from here

It requires a minimum of 128Mb of RAM.

If anyone runs it with a Geforce could you let me know what framerate you get, thanks.

This is cool.

Adrian : Maybe you could raise the amount of distance for the zoom.

I have PIII450 with 256megs of ram and Ati rage 128 and I get 0.33 fps!!!

the rotation are fine, but the zooming is slow.

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.

it was at 26X26.

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!

I’ll try new settings and post the results.

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 :

  1. 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

  2. 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)

Resolution FPS TPS
13x13 0.6 1.25M
26x26 2.2 1.40M
39*39 4.4 1.54M

But I hope to try it soon with Quadro and Wildcat 4210.

This is absolutly cool

Hm, ever thouhght of using a point-cloud to NURBS converter?

I your case (software) NURBS will probably a lot faster than pure geometry.

BTW: I want a GFX card that does the tesselation in hardware.

Keep up your exellent work!


Thanks for all the feedback guys. I’m looking into occlusion culling, I’ve almost cracked it. I’ll look at the other ideas later.

Can’t wait for the new version!

As for my occlusin culling for sphere, I haven’t been able to do it when the sphere can rotate around more than 1 axis.

But you seem to have find something that satisfies you, so I am just going to wait!!!

[This message has been edited by Gorg (edited 05-14-2000).]