? DisplayLists with weird rendering problem ?

[Z-Knight]

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:

  gl.glNewList(list, GL.GL_COMPILE);
    drawImmediateMode();
  gl.glEndList();

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

  private void drawImmediateMode(GL gl) {

    for (int i = 0; i < objects.size(); i++) {
      Obj tempObj = objects.get(i);
      if (tempObj.groups != null) {
        for (Obj.OffsetAndLength group : tempObj.groups) { 

          // gl.glColor3d(1.0, 1.0, 1.0);                <===== Adding this line, or the one below it causes
          // gl.glDisable(GL.GL_TEXTURE_2D);                   a massive slowdown during first rendering
                                                                             when using DISPLAY LISTS. Taking these out
                                                                             results in no problems at all.

          gl.glBegin(GL.GL_TRIANGLES);
            for (int j = group.offset; j < group.offset + group.length; j++) {
              gl.glNormal3f(normal.getX(), normal.getY(), normal.getZ());             
              for (int k=0; k<3; k++) {
                gl.glVertex3f(verts[k].getX(), verts[k].getY(), verts[k].getZ());
              }
            }                     
          gl.glEnd();
     
        }
      }
    }

  }

When I render I simply do the following:

public void display() {
   gl.glCallList(list);
 }

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.

[loom_weaver]

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.

[Z-Knight]

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).

Games published by our own members! Check 'em out!

[loom_weaver]

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.

[Z-Knight]

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.

[Z-Knight]

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

[Z-Knight]

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.

[loom_weaver]

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?

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75   76   77   78   79   80   81   82   83   84   85   86   87   88   89   90   91   92   93   94   95   96   97   98   99   100   101   102   103   104   105   106   107   108   109   110   111   112   113   114   115   116   117   118   119   120   121   122   123   124   125   126   127   128   129   130   131   132   133   134   135   136   137   138   139   140   141   142   143   144   145   146   147   148   149   150   151   152   153   154   155   156   157   158   159   160   161   162   163   164   165   166   167   168   169   170   171   172   173   174   175   176   177   178   179   180   181   182   183   184   185   186   187   188   189   190   191   192   193   194   195   196   197   198   199   200   201   202   203   204   205   206   207   208   209   210   211   212   213   214   215

*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

[Z-Knight]

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.

[Z-Knight]

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:

-display()-----------------------------------------------
[null] Update Display Lists[null] Immediate Mode time: 31
...done. 31
 display() loop time: 31
         start to vehicle render: 0
            vehicle render total: 31
           vehicle render to end: 0
    time between display() calls: 16
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: 0
            vehicle render total: 0
           vehicle render to end: 0
    time between display() calls: 12174
--display()-----------------------------------------------
 display() loop time: 0
         start to vehicle render: 0
            vehicle render total: 0
           vehicle render to end: 0
    time between display() calls: 32
BUILD SUCCESSFUL (total time: 1 minute 13 seconds)

Note the RED line above showing a 12 second delay.

Games published by our own members! Check 'em out!

[Z-Knight]

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!

[gouessej]

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).

[theagentd]

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

[Z-Knight]

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.

[Riven]

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.

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

[theagentd]

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