I have an object read from an OBJ file, and I’m rendering it. With directly rendering, I get about 4fps, and with a display list, I get 2fps. What’s up with that? I don’t have an amazing graphics card, but I thought display lists should be always quicker than straight rendering, even on a slower card.
Smaller models are faster with display lists (one test model is 13fps with display lists, and just under 4fps without), but heavier textured models are slower (2fps with DL, 4fps without). It is possible that I’m running out of graphics card memory.
Does this mean I have to write code to time both methods, and then have my program decide on a case-by-case basis whether to use the display list?
Display lists are not often used now a days. If you mean immediate mode rendering when you say “direct rendering”, that will also be slow. You should use Vertex Buffers, ideally use Vertex Buffer Objects, so that you don’t incur the expense of uploading the verts every frame.
How are you using display lists, are you using only the “COMPILE” option then later calling the display list multiple times?
Or are you re-generating the display list every frame? (or possible using the COMPILE and EXECUTE option)
We need more details - perhaps post some code.
What card are you using? How much geometry are you rendering? (Are you sure your OpenGL drivers are installed correctly? what is the string returned from calling glGetString(GL_RENDERER)?)
Oh, I have heard of vertex buffers, but never used them. I will look into this. Are VBOs likely to be faster than display lists? (or possibly take up less graphics memory, allowing it to fit in graphics card memory, and therefore be faster?)
My display lists are just COMPILED first, and then glCallList() is called for each frame.
Details - my objects are human models exported from DAZ. Roughly 70k polygon faces, all textured. Roughly 10 textures, ranging from 256 pixels up to 4192 pixels square. So, yes, there’s a bit of memory there.
My PC is a few years old, P4 HT 3GHz CPU, 1Gig RAM, GeCube RADEON 9200 SE 128MB graphics card. Pretty lightweight hardware for graphics work, but it’s more than some of my customers have, so I want to get the best performance on sub-optimal hardware.
Are you calling commands like glTextureImage2D while compiling the display list ? If so, the texture may be sent back to the GPU each time you call the display list (at least on some hw/driver combo, especialy some ATI ones if I remember correctly). Obviously this can be quite slow and kill your performances.
To avoid this, you should generate all your textures first and only call glBindTexture when building your display lists.
Wow, yeah that is asking quite a bit from that Radeon, but you should be able to get some decent performance, here are some things to consider.
Break up the models into groups of triangles that share the same texture, if they are not already organized in this fashion.
Draw all of the groups that you can before changing textures.
VBOs are fast, they store the vertex data up on the graphics card, eliminating the need to transfer things. You may get equal performance from a display list, if the driver is doing a good job of handling those lists. As it is a somewhat out of vogue way of rendering, I’m probably go with the VBOs.
Consider texture map compression. Those large 4096 textures are thrashing the cache, I’m sure, you’ll get better performance if they are mip mapped, and compressed. The compression extensions are very easy to implement.
Yes, all my textures are pre-bound, and just using glBindTexture(). That did make a big performance increase.
1 and 2) Yes, after importing the polygons from the file, I sort them by texture, so minimal changing of textures is required during rendering. I also pre-bind the textures at this stage, so this is done ahead of time.
I will test out VBOs to compare. I’m basically reading arrays of vertexes, normals and texture coordinates from the file, so it shouldn’t be too hard to implement the VBOs from this.
Interesting idea. I was avoiding mipmaps, because I figured they were only using MORE memory, and that would slow things even more, but you are right - if it means the bigger versions can be swapped out, it might improve things.
Thanks for all the help and ideas. DAZ is certainly much faster at rendering the same object, so if I can get near to the speed of DAZ with some of these improvements, I’ll be pretty happy.
Use the “Full Debug” profile and look in the log for any OpenGL errors.
If you still are having a lot of issues, as a last resort, use the “XML Frame” log capture (press CTRL-SHIFT-F) to capture a frame log and post it on the web somewhere where we can inspect.
Mipmaps increase performance by A LOT.
4096x 4096 texture? That is completely unecessary. Also, are you sure the 9200 supports that dimension? I’d say make your textures no larger than 1024x1024 for just some character.
70K sounds ok so it should run fast with display lists.
Aha!! Finally found the problem, and it was my own dumb fault!
I wrote my code so that the first time I actually use a texture, I load it into the card, and subsequent uses, I just bind to the texture. Problem was, the first time I use it is in building the display list, so the display list was actually calling glTexImage2D(), instead of just calling glBindTexture(), as happened with display lists off.
