Public Group

# OpenGL Display Lists

This topic is 2550 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

I'm building my terrain as a series blocks that get dynamically created as they come into view and destroyed as they go out of view. Each terrain block contains 64x64 = 4096 tiles, and each tile is made up of two triangles. Each block builds an OpenGL display list when it is instantiated. At each frame, I just use glCallList to draw each block. At any given time there are between 9 and maybe 15 terrain blocks visible. So, for each frame I'm calling glCallList between 9 and 15 times.

However, even with everything loaded into display lists and nothing much else going on at each frame, I'm seeing terrible frame rates - in the mid-to-upper teens generally speaking.

If I shrink my block size down to 16x16 tiles, I get up to about 22 or 23 fps. Still not great, but much better.

Is there some limit to the size of display lists? It would appear that drawing one big display list is slower than drawing several smaller ones. Is this understanding correct?

##### Share on other sites
What else is in your scene? Are you triangles textured? What is the size of your cliping boundaries?

I use display lists to render text on the screen. Basically two triangles per letter. I can have 100's of characters on the screen at a time and I don't see any slow downs.

##### Share on other sites
You don't mention if these are 2D or 3D blocks. Also, do you consider your computer to be good enough to do that kind of drawing? You are drawing 4096x9=36,864 tiles, which is a lot in my opinion.

##### Share on other sites

What else is in your scene? Are you triangles textured? What is the size of your cliping boundaries?

I use display lists to render text on the screen. Basically two triangles per letter. I can have 100's of characters on the screen at a time and I don't see any slow downs.

In addition to the terrain, I have a handful (less than 50) trees that I've drawn by hand. Each uses maybe 100 triangles.

Currently, there are no textures.

I have alpha blending enabled, as well as depth buffering and lighting.

By clipping boundaries, do you mean what frustum am I using? I'm using gluPerspective to build that:

GLU.gluPerspective( 80.0f, 16.0f / 9.0f, 0.1f, 500.0f ); 

##### Share on other sites

You don't mention if these are 2D or 3D blocks. Also, do you consider your computer to be good enough to do that kind of drawing? You are drawing 4096x9=36,864 tiles, which is a lot in my opinion.

Sorry, it's 3D.

This is a Dell laptop with a Core i7 8-core processor, 8GB system memory, and an nVidia GeForce GT 555M discreet graphics card with 3GB of RAM. I regularly play games (WOW, LFD2, Civ5, etc) at high resolution and "full" graphics settings and achieve frame rates in the 45's - 60's.

##### Share on other sites

If I shrink my block size down to 16x16 tiles, I get up to about 22 or 23 fps. Still not great, but much better.

I should also have mentioned than when I do shrink down the individual block size, I simultaneously increase the number of blocks by an amount that causes the system to draw approximately the same number of vertices on the screen. The only real difference is that there are more call lists each with a smaller (about 1/4) number of polygons.

##### Share on other sites
First thing is to find out where exactly your performance problems are coming from; drawing (or use of display lists) may not be the root cause (it may well be your dynamic generation and destruction, for example). So comment out your drawing commands (specifically your glCallLists calls) and measure performance. That'll give you a good indication of how much performance impact your drawing has on your overall program. Work back from there to identify the point at which performance goes back up again, and you've found your bottleneck.

##### Share on other sites

First thing is to find out where exactly your performance problems are coming from; drawing (or use of display lists) may not be the root cause (it may well be your dynamic generation and destruction, for example). So comment out your drawing commands (specifically your glCallLists calls) and measure performance. That'll give you a good indication of how much performance impact your drawing has on your overall program. Work back from there to identify the point at which performance goes back up again, and you've found your bottleneck.

I'm fairly certain it's not during the block computation. When I first start the game up, block computation takes a few hundred milliseconds, but then once that's done it doesn't happen again until I move to another block. If I just start the game, and don't move at all, my frame rate is still in the upper teens even though no computation is taking place.

I'll try profiling the process and see if that can give me any insight into what's going on.

##### Share on other sites
You might consider using VBO instead, nehe as a good tutorial on them.

##### Share on other sites

I'm building my terrain as a series blocks that get dynamically created as they come into view and destroyed as they go out of view. Each terrain block contains 64x64 = 4096 tiles, and each tile is made up of two triangles. Each block builds an OpenGL display list when it is instantiated.

I'm surprised nobody mentioned this part already.

Don't do that. That was how things were done in the mid 90's. There were all kinds of fancy routines for continuous level of detail and other fancy stuff.

Then someone came along with a programable pipeline. The GeForce 3 video card programmable vertex shaders transformed the world of terrain rendering.

Vertex shaders and geometry clipmaps can render many thousand square miles of detailed terrain with practically zero effort. It will automatically be at the best LOD. About the only significant issue is that it doesn't morph between LOD levels, but that is a very tiny price to pay since you can include so much higher details at every level.

Here is the classic GPU Gems article (with source) on how to do it, though newer and fancier algorithms exist. You get better visual results for far less memory, plus it frees up the cpu and the bus for more important tasks.

[font="arial, verdana, tahoma, sans-serif"]

Each terrain block contains 8192 triangles. At any given time there are between 9 and maybe 15 terrain blocks visible. So, for each frame I'm calling glCallList between 9 and 15 times.
[/font][font="arial, verdana, tahoma, sans-serif"]Those are tiny. The video card can process those without effort.[/font]
[font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]
However, even with everything loaded into display lists and nothing much else going on at each frame, I'm seeing terrible frame rates - in the mid-to-upper teens generally speaking. Is there some limit to the size of display lists? It would appear that drawing one big display list is slower than drawing several smaller ones. Is this understanding correct? [/quote][/font][font="arial, verdana, tahoma, sans-serif"]The problem is not with display lists. Display lists are just batches of instructions.[/font]The problem is that you are saturating the communications with your card on trivialities. You are flooding the bus between your CPU and GPU by re-transmitting your data in tiny pieces every frame.
[font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]Dump all of it to the card up front. Let it live on the video card memory. Use a shader on the video card to process it. If you can't dump it all at once, create a really big interleaved array and dump that to the video card every frame. At least then you are using a single transfer rather than a ton of tiny stored commands.[/font]

1. 1
2. 2
3. 3
Rutin
22
4. 4
JoeJ
16
5. 5

• 14
• 29
• 13
• 11
• 11
• ### Forum Statistics

• Total Topics
631774
• Total Posts
3002286
×