Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  ? DisplayLists with weird rendering problem ?  (Read 2693 times)
0 Members and 1 Guest are viewing this topic.
Offline Z-Knight

Senior Member


Medals: 1



« Posted 2011-10-03 22:57:51 »

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:

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

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

Quote
  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:

Quote
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.
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #1 - Posted 2011-10-03 23:07:16 »

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.
Offline Z-Knight

Senior Member


Medals: 1



« Reply #2 - Posted 2011-10-03 23:14:23 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #3 - Posted 2011-10-03 23:24:29 »

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.
Offline Z-Knight

Senior Member


Medals: 1



« Reply #4 - Posted 2011-10-03 23:40:31 »

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.
Offline Z-Knight

Senior Member


Medals: 1



« Reply #5 - Posted 2011-10-04 00:27:08 »

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

Senior Member


Medals: 1



« Reply #6 - Posted 2011-10-04 20:05:10 »

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.

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #7 - Posted 2011-10-04 21:34:09 »

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
Offline Z-Knight

Senior Member


Medals: 1



« Reply #8 - Posted 2011-10-04 21:44:12 »

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.
Offline Z-Knight

Senior Member


Medals: 1



« Reply #9 - Posted 2011-10-04 21:56:16 »

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:

Quote
-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!
Legends of Yore - The Casual Retro Roguelike
Offline Z-Knight

Senior Member


Medals: 1



« Reply #10 - Posted 2011-10-04 22:18:44 »

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!
Offline gouessej

« In padded room »



TUER


« Reply #11 - Posted 2011-10-04 23:16:42 »

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

Offline theagentd
« Reply #12 - Posted 2011-10-05 13:36:19 »

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

Myomyomyo.
Offline Z-Knight

Senior Member


Medals: 1



« Reply #13 - Posted 2011-10-05 16:35:19 »

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.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2011-10-05 16:58:34 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline theagentd
« Reply #15 - Posted 2011-10-05 18:27:59 »

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

Myomyomyo.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (48 views)
2014-04-15 18:08:23

BurntPizza (44 views)
2014-04-15 03:46:01

UprightPath (60 views)
2014-04-14 17:39:50

UprightPath (42 views)
2014-04-14 17:35:47

Porlus (58 views)
2014-04-14 15:48:38

tom_mai78101 (82 views)
2014-04-10 04:04:31

BurntPizza (140 views)
2014-04-08 23:06:04

tom_mai78101 (240 views)
2014-04-05 13:34:39

trollwarrior1 (200 views)
2014-04-04 12:06:45

CJLetsGame (207 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!