? DisplayLists with weird rendering problem ?

OpenGL Development JOGL Development
#1

I am about to bash my head into this monitor because I cannot figure out the cause, the source or the solution to a very weird rendering problem. I’m trying to work on a simple version to demonstrate the issue but in the meantime here is my problem.

I am working on rendering a 3DS model. I am able to read in the model quickly enough and then I try to render it and this is where I get the weird results. I have two ways of rendering: Immediate Mode and Display Lists. The Immediate mode rendering has no problems, other than it is a bit slow if I have large models. The Display Lists mode is essentially created using:

This is essentially my Immediate Mode rendering code (psuedo code):

When I render I simply do the following:

So here is where it gets weird. I put timing statements all over the place to measure how long something takes to complete. The loading of the model is tiny. The rendering in immediate mode is tiny. The creating of the display lists is tiny. Calling glCallList() on the list is tiny.

BUT…upon the first rendering my updates get blocked for a period of time that is proportional to the size of the 3DS model only if I include the RED section above…for some reason calling any of those methods, and others as well causes a massive slow down that takes control of my update and does not return it for a few seconds. Effectively the time between the end of the first display() call and the start of the next display() call is delayed by the few seconds.

I have NO IDEA why this is happening…I can take out those glColor3d() or glDisable() calls and it is fine. I can put in a glIsEnabled() call and it is fine too but certain gl calls cause my slowdown. I can’t understand what is happening here at all. I realize the first time you send something to the graphics card via a display list invocation that things can be slow…but in my case the display list is only bad/slow when those extra commands are sent and those can be in a display list - as far as I’m aware.

I don’t know if this is an OpenGL question or a JOGL question…btw, I control my display updates using the display() call on my GLJPanel, but somehow this issue is preventing from making any updates…I essentially lose all listener control, the long pause occurs and then I get them all back and the scene continues to render without any problems…only that first one is an issue.

#2

If I’m not mistaken, the call gl.glDisable(GL.GL_TEXTURE_2D); is a significant context shift.

Your loops appear as:

for (int i = 0; i < objects.size(); i++) // how many objects do you have?
…
for (Obj.OffsetAndLength group : tempObj.groups) // and for every object, how many groups are you iterating through?

Try to re-arrange things so that you switch to and from GL_TEXTURE_2D as few times as possible i.e. if you’re calling this function more than 3-4 times total during your entire rendering phase then you’re doing it wrong. [edit] Also the glEnable/glDisable calls do not belong in a display list.

#3

yeah, but that was just an example…forget that glDisable() call because I get the same issue by simply having a glColor3d(1,1,1) call in its place.

I had a bunch of texture/material calls in my code that are different for each “group” that I have, which is why I made mention of it. But I commented everything out…it is barebones now and I only add that glColor3d() call and it is still causing that delay between update loops.

OH yeah…forgot to mention that I’m still using JOGL version 1.1 (or whatever the last 1.XX release was prior to JOGL 2.0).

#4

Hmm, I don’t know then. Can you post a more up-to-date example?

In my experience, glColor*, and glVertex* + glBegin/glEnd have always been pretty snappy both in immediate mode and display lists.

glEnable/glDisable and glBindTexture can be really slow.

#5

yeah, I’m working on a super stripped down version of both my render code and an example that uses it. I’ll keep the 3DS loader pretty much intact because that loading part is fine.

I’ve ripped out all of my VBO and vertex array code and am working on stripping out all extra calls/methods I had for my own benefit that are not needed in the example. I also need to add a new mouse listener to allow you to rotate the scene because I took out my camera code for fear that it was the problem.

After all of the stripping so far, I still have the problem. I hope to have an example code uploaded today - but worst case it will be tomorrow morning. Thanks for your help.

#6

I’ll post something in the morning tomorrow (Tuesday)…I need to find a 3DS model that I can attach.

#7

sheesh…finally found a site where I can upload my source code example - all others were blocked by my lovely work spy-on-your-employees system.

Here is the link to the JOGL version 1.1.1 example: http://www.nippyzip.com/uploads/111004013618-16435.zip - that should be good for 3 days.

I included a 3DS example file called “Gantry.3ds” and my source code that includes helper classes (JOGUTILS 3DS loader stuff) and my modified Viewer and Renderer. This file is comprised of about 700 objects, 174000 vertices and 177000 faces.

Copy all the files into one project folder and copy the Gantry.3ds file to some directory and note the path. Then edit the 'Dumb3DSViewer.java (line 87) and set the path to this model in that location.

To run the program you run the ‘Dumb3DSViewer.java’ class. When it starts it will show a blank 3D scene with only the colored 3D axes. You can use the mouse to do some crappy rotation. Since I don’t use an FPSAnimator, the updates to the scene occur as a result to changes in the view - so when you move your mouse to rotate the scene then stuff gets updated. So keep that in mind because you will have to do some rotations while the model is loading to see the issue that I am seeing.

Ok, so, when you run the program (Dumb3DSViewer) scene is empty…so hit the ‘Z’ keyboard key to load the 3DS model in the background. While that is loading make sure that you are rotating the scene (the 3D axes) around so you can see the updates occurring. While you are doing your mouse rotation you will notice a period during which time you will lose control and nothing will update - probably like 3-4 seconds later the update will finish and the model will be displayed and you will be able to continue rotating.

If you go into the ‘Dumb3DSRenderer.java’ (line 287) there will be the glColor3d(1.0, 1.0, 1.0) call that you can comment out and repeat the process. With this line commented out the 3DS model will load super fast and display almost immediately…I mean you probably have to be moving the mouse around before you hit the ‘Z’ key to load the model so you can see the effect.

So…you might be wondering if my loader is the cause or the way I load by using a separate thread to spawn the loading in the background. Sure, I thought about that, but if the separate thread was the cause then I should see that same issue irrespective of having the extra glColor3d() call or not. I think this has something to do with the way I’m rendering or creating display lists - I don’t know.

I did figure out one thing though - the 3DS model has a lot to do with it and not so much how many vertices or faces it has but rather how many objects it has. The model, Gantry.3ds, only has 700 objects but my work models have about 4700 and if you notice the rendering loop (drawImmediateMode() method on line 278 of Dumb3DSRenderer) I loop over the objects. I used models with more vertices and faces but only like 10-20 objects and the scene was generated super fast…so that kind of confused me as to what is going on.

So having 4700 objects means I loop a lot and have many calls to glColor3d() - but it is necessary because each object could have a different color/material/texture so I can just have one global color call. Note in this example I am only using one color just for testing purposes but the full code has the specific color/material/texture calls for that object.

I hope that is all clear - I know it is kind of wordy.

P.S. For grins and to blow your mind even more, move the gl.glColor3d(1.0, 1.0, 1.0) from the drawImmediateMode() method in Dumb3DSRenderer.java from outside of the glBegin(GL_TRIANGLES)/glEnd() to inside that loop and notice what happens. Tell me it is not confusing that simply moving that call inside the glBegin/glEnd block speeds it up!?! But at the same time, if I try to add a glEnable(GL_COLOR_MATERIAL) call inside or outside the glBegin/glEnd block the slowdown is the same. Hence my crazy situation - I don’t know what is going on. And if anyone does I would be eternally thankful - or for at least a couple of weeks.

#8

I downloaded your code and I ported it to JOGL 2.x since I couldn’t find the 1.1.1 download.

It appears to run fine on my MacBook Pro. I was dragging the axes as I pressed the ‘z’ key. A minor pause but barely noticeable.

Is there something else I should be watching for?


*snip*
--display()-----------------------------------------------
 display() loop time: 11
         start to vehicle render: -1317756508730
            vehicle render total: 0
           vehicle render to end: 1317756508741
    time between display() calls: 1317756508730
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756509955
            vehicle render total: 0
           vehicle render to end: 1317756509955
    time between display() calls: 1214
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756510739
            vehicle render total: 0
           vehicle render to end: 1317756510740
    time between display() calls: 784
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756510789
            vehicle render total: 0
           vehicle render to end: 1317756510790
    time between display() calls: 49
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756510823
            vehicle render total: 0
           vehicle render to end: 1317756510823
    time between display() calls: 33
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511007
            vehicle render total: 0
           vehicle render to end: 1317756511007
    time between display() calls: 184
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511074
            vehicle render total: 0
           vehicle render to end: 1317756511074
    time between display() calls: 67
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511123
            vehicle render total: 0
           vehicle render to end: 1317756511124
    time between display() calls: 49
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511240
            vehicle render total: 0
           vehicle render to end: 1317756511241
    time between display() calls: 116
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511324
            vehicle render total: 0
           vehicle render to end: 1317756511324
    time between display() calls: 83
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511351
            vehicle render total: 0
           vehicle render to end: 1317756511352
    time between display() calls: 27
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511408
            vehicle render total: 0
           vehicle render to end: 1317756511408
    time between display() calls: 56
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511457
            vehicle render total: 0
           vehicle render to end: 1317756511458
    time between display() calls: 49
Loading Model [/Users/skiyooka/Desktop/3dviewer-test/Gantry.3ds]
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511540
            vehicle render total: 0
           vehicle render to end: 1317756511540
    time between display() calls: 82
Loading Model: /Users/skiyooka/Desktop/3dviewer-test/Gantry.3ds--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511566
            vehicle render total: 0
           vehicle render to end: 1317756511567
    time between display() calls: 26
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511592
            vehicle render total: 0
           vehicle render to end: 1317756511593
    time between display() calls: 25
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511627
            vehicle render total: 0
           vehicle render to end: 1317756511627
    time between display() calls: 34
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511649
            vehicle render total: 0
           vehicle render to end: 1317756511650
    time between display() calls: 22
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756511667
            vehicle render total: 0
           vehicle render to end: 1317756511667
    time between display() calls: 17
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511695
            vehicle render total: 0
           vehicle render to end: 1317756511696
    time between display() calls: 28
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511861
            vehicle render total: 0
           vehicle render to end: 1317756511862
    time between display() calls: 165
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511900
            vehicle render total: 0
           vehicle render to end: 1317756511901
    time between display() calls: 38
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756511970
            vehicle render total: 0
           vehicle render to end: 1317756511971
    time between display() calls: 69
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756512009
            vehicle render total: 0
           vehicle render to end: 1317756512009
    time between display() calls: 38
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756512042
            vehicle render total: 0
           vehicle render to end: 1317756512042
    time between display() calls: 33
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756512119
            vehicle render total: 0
           vehicle render to end: 1317756512119
    time between display() calls: 77
 ... done
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756512148
            vehicle render total: 0
           vehicle render to end: 1317756512149
    time between display() calls: 29
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756512244
            vehicle render total: 0
           vehicle render to end: 1317756512244
    time between display() calls: 95
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: -1317756512326
            vehicle render total: 0
           vehicle render to end: 1317756512326
    time between display() calls: 82
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: -1317756512392
            vehicle render total: 0
           vehicle render to end: 1317756512393
    time between display() calls: 66
--display()-----------------------------------------------
[null] Update Display Lists[null] Immediate Mode time: 121
...done. 159
 display() loop time: 177
         start to vehicle render: 1
            vehicle render total: 163
           vehicle render to end: 13
    time between display() calls: 77
--display()-----------------------------------------------
 display() loop time: 2
         start to vehicle render: 0
            vehicle render total: 2
           vehicle render to end: 0
    time between display() calls: 24
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: 0
            vehicle render total: 1
           vehicle render to end: 0
    time between display() calls: 15
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: 0
            vehicle render total: 1
           vehicle render to end: 0
    time between display() calls: 71
--display()-----------------------------------------------
 display() loop time: 1
         start to vehicle render: 0
            vehicle render total: 0
           vehicle render to end: 1
    time between display() calls: 83
#9

Thanks for checking it out…I guess one problem is that I’m on a Intel Core 2 Duo t9300 @ 2.5GHz with 2GB of RAM and you are on something much faster. And as a result you might not be seeing that significant of a pause as I’m seeing. Maybe my more complicated model would have a bigger effect.

Let me look for a more complicated model - or maybe you can PM me with an email and I can send you the one I have - zipped it should fit in an email. Maybe then the difference would be noticeable.

#10

so with my larger model, having 4700 objects, the rendering is almost instantaneous when I don’t have those extra glColor3d, etc calls. But when I have those inside the code, I get about a 10-15 second delay for the first render and then everything is fine.

So I see this output at the very end:

Note the RED line above showing a 12 second delay.

#11

It might be that my NVidia Quadro NVS 140M Laptop based video card is a problem here - or the video drivers.

Loom_weaver tried it and had no problems and not big delay like I experience - so maybe it is a hardware/driver thing or some kind of funny that I’m unlucky to experience. Coupled with 3DS models that have lots of objects could be a cause here too. I need to do more investigation because I can load my models relatively fast (no big slowdown) when I use commercial software like Right Hemispheres -> Deep Exploration 6.5 viewer (trial edition).

I want to thank Loom_weaver for taking the time and effort to do some independent testing for me - Thank you!

#12

Display lists are poorly implemented nowadays and it is going worse as time goes by especially on consumer graphics cards (by opposition with professional graphics cards, for example NVIDIA Quadro).

#13

Try to use glColor3f (the float version) instead. I doubt you need 64 bits of color information.

#14

I could do that, but my problem would still exist. The issue is not so much the command that I use there, but rather that certain OpenGL commands are placed there.

Instead of having a glColor3D() I can put a glEnable(GL_TEXTURE_2D) or glDisable(GL_MATERIAL_COLOR) and it will have the same effect. But not all OpenGL commands cause problems…I can put a glIsEnabled(…) and it works just fine.

At first I thought the glEnable()/glDisable() were bad because they query a state variable from OpenGL which is done internally via a massive SWITCH() statement. But glIsEnabled() is also using a large SWITCH() statement so that can’t be the cause.

I can’t see what I’m doing wrong, so it is quite easy to point at the video card or the driver and say that this is a result of some error in their Display List handling. It could be that my Quadro video card is at fault - quite disappointing if that is true. I’m going to have to test this on other computers to truly convince myself of this fact. I just can’t imagine that some video card that was created by very smart engineers would not support display lists correctly - it just has to be something that I’m doing wrong since I’m the one with much less knowledge (at least that’s what I’m feeling in the back of my mind right now).

thanks.

#15

State queries like glIsEnabled(…) are (obviously) silently discarded in displaylists.

#16

Yes, many other calls are also either ignored or executed immediately.