Hi,
My question is: is it possible to compile a display list (without calling it!) in one thread while open gl renders in another thread.
Thanks.
A GL Context is bound to a thread, so you can’t call GL commands for the same context in different threads. You could create a second context and share you dispay list space, but a better choice would be using the VBOs 
Thanks.
Next question (sorry if it is trivial): Can I use a VBO to store material data (diffuse and specular colour, shininess, etc.)?
I know a VBO is more flexible than a display list, I just wanted to know if I can use display lists efficiently for never or infrequently changing data. I thought that if some data changed, I can free the corresponding display list and compile a new one.
I plan to use a lot of text in my application, and font outlines are stored in display lists. Do you think that I should use VBOs for everything else (geometry, materials)?
Thanks for the help.
Store the material data as uniform variables. (if they are per mesh)
The VBO stores only the per vertex attributes (position, per vertex color, normal, tangent…)
Could you elaborate this a little further and maybe with a sample or a link to a sample?
This is exactly my problem. I don’t need per vertex colours, I use materials (with ambient, diffuse and specular colours, etc.) instead. I would only use one material for one VBO (1 VBO= 1 mesh). Is it possible without having to use immediate mode?
Thanks.
VBO’s have nothing to do with fixed function materials. VBO’s are for storing vertex attributes (pos,texcoord,colour etc.), nothing else.
Use display lists for your materials if you want, you will claw back some CPU but probably not any rendering performance. Share the display lists between your 2 threads/contexts, but put in place some kind of synchronisation, so as you’re compiling a display list in the worker thread, your render thread is not trying to draw it…otherwise you may get undefined/undesirable results.
“Use display lists for your materials if you want, you will claw back some CPU but probably not any rendering performance”
Do you think it would not be a lot faster to switch from one material to the other when I draw the elements of my scene if I used display lists? Because if the gain is negligible than I don’t think it would be worth the bother. The extra CPU time I would gain I don’t need. I will dedicate a full CPU core for rendering.
My application won’t need millions of vertices and will use at most up to a hundred materials at a time. Probably a lot less. I just thought it would be worth a little effort to optimize when I use only a few materials but still switch between them dozens of times. But is it really worth the effort (share display lists, etc. although I can easily guarantee that a display list being compiled by another thread will not get called by the rendering thread until it is ready)?
Thanks.
Originally posted by aronsatie:
Do you think it would not be a lot faster to switch from one material to the other when I draw the elements of my scene if I used display lists?
I don’t think you will see any gain at all. Just store your material settings along with your VBO and call the Material command before each drawing. This is more flexible too, you can change the material for the same mesh which won’t be possible with display lists. VBOs are supported on almost all consumer hardware nowadays, they were integrated in 1.5
In the end, it probably comes down to function call overhead. A single glCallList versus 4 or 5 glMaterial calls. But then again what does the driver do when it gets a glCallList? Is the look up expensive versus just setting some uniforms (which is what is happening under the hood whenever you call glMaterial - all modern hardware is shader based emulating fixed function)?
If I were you I wouldn’t bother compiling my materials into display lists.
Also, be aware that display lists are only worth while on nvidia hardware - lesser hardware such as ATI don’t have good support for display lists, as they’re mainly a D3d/gamers IHV.
You sound very convincing, so I started thinking about why I even asked this question. Then I found that on page 283 of the read book it suggests that lights, material properties and lighting models can be optimized by compiling them into display lists.
But probably this is not the case for me. I will set the ambient only once for the scene and not per mesh (I see no point in it). This leaves the diffuse and specular colours that would change quite a few times and several others less frequently (I plan to use parameters like culling, PolygonMode, BlendFunc, BlendEquation, etc. as parameters for a material).
Maybe I can store current values and use the CPU to check for only the parameters of the next material that are different. All in ‘immediate’ mode.
Do you think it is the best thing to do? It certainly is the easiest.
Sorry for asking for a ‘final confirmation’, I just want to make sure.
Thanks.
I forgot to mention that I will not bother with all types of VGA card, I will only support Nvidia and G80 or better. I can do that easily, because the application will be more or less for my own use
> I will only support Nvidia and G80 or better
Then you have all the cards 
The method you suggest sounds most reasonable to me. You could also implement some sorting, so that objects that use the same material settings are drawn in groups, but that is most probably not worth the time.
Why bother with the fixed function pipeline anyway? Just implement your own lighting and you will end with better quality and performance anyway.
“Why bother with the fixed function pipeline anyway? Just implement your own lighting and you will end with better quality and performance anyway.”
I suspect you are referring to something I don’t know. Could you please elaborate?
Aha, I thought so. Maybe for version 2.0
Right now I want to have a working version and there is still a lot of other stuff I don’t have experience with.
Thanks, guys.