[Question] excluding statements from display list

Hi,

I’m coding a loading bar, to display computing percent of a big display list creation.
The trouble is that I need to exclude some GL instructions from the ones stored between glNewList() and glEndList(). Typically, the instructions which displays the loding graphics.

Is there some GL command to discard instructions from the display list being constructed ?

Thank you !

Well yeah… :wink:


glNewList

... blabla

if(!exclude):
  commands to exclude

glEndList

[\code]


but nothing in teh API can do it, in the end you have the control over your application!

This solution doesn’t solve my problem, unfortunatly :(:frowning:
Indeed, I have to mix, within the same block of glNewList()-glEndList(), instructions which must be part of the display list, and instructions which mustn’t !

This idea is that my display list cost much time to compute, since it has millions of polygons. So, during the creation of the list, that is to say between the statement glNewList and the statement glEndList, I want to display in the same time, on the screen, some primitives which represent avancement in computation of the list. But these primitives are not part of the object being generated in the list, so they must not be stored in the list, with the object’s triangles.

If the API does not provide anything to do that, does this mean that while a list is being generated, your graphic cards is frozen ?

not possible with display lists, but you could use VBOs and not upload the full chunk but partially, then update screen graphics, pump vbo again and so on

So your are displaying some useless geometry to distract the user while your are loading a big model? :wink:

If I am not mistaken, it is not possible to have 2 threads in your application that call some opengl commands. So, the solution is the CrazyButcher’s one since you can load mesh data asynchronously in another thread mapping the VBO data and in the first thread display what you want to show the loading progress.

You are making 1 large display list? How long does it take?
It should be like 0.1 sec or something, not worth displaying a progress bar.

Or if you want, use two rendering contexts in two threads. While the one creates the DL, the other one shows the progress. And BTW, a DL with millions with polygons will probably be extremely slow. You should do some sort of occlusion/LOD when working with large amounts of geometry.

For a terrain mesh of 2 300 000 polygons, it takes something like 0.5 sec.
It is not very much, but it’s on my computer which is quiete powerfull. On a weaker system I will last more.

Moreover, my mesh generation algorithm, based on perlin noise coupled with bicubic interpolation, costs much time to compute on such a volume of points, so I code a progress bar for this step.
The idea is to display the progress bar just when the user click on the generation button, to be a forecast of the ending of the operation as precise as possible. So I would really enjoy to include display list creation in this display.

I will meet the same trouble when I will implement this progress bar into a precomputation of static shadow volumes of this type of mesh. I takes something like 5 sec on a mesh of 2.105.334 polygons on my computer. So a display of the computation progress is necessary in term of “quality” of the application.

if its really just mesh uploading, use VBO, more flexible, really common these days. And in most cases the same/similar speed. However you might also want to render so much in chunks aynway instead of large array to benefit from 16 bit indices.

There’s something I missed, display lists aren’t supposed to be stored on the GPU RAM ?

There is no law that says that they can’t. Display lists may be accelerated, and one possible way for a driver to do so is to create some static VBOs under the hood.

I had a quick look in the Red Book to see if glDrawPixels calls are stored in display lists, and unfortunately (for this purpose) they are.

It looks like the simplest option to achieve this is with dual rendering contexts with shared lists, as Zengar suggested, but you’ll be in platform-dependent territory.