Trees in the holodeck

All right, actually they are slender cylinders. The problem is,
they're growing through the cabin furniture.

???

Anyone seen anything like this? I've seen the problem on two
platforms, now--Mac OS 10.2 and Pentium 4 Linux.

Randolph

Hi Randolph,

I believe there's a bug either in the code that determines rotation angles for cylinders in src/common/rglsurf.c or many OpenGL implementations. I suspect the former, but need to do some further investigation to figure it out for sure.

-Greg

···

From: Randolph Fritz <[email protected]>
Date: Fri May 23, 2003 10:10:09 PM US/Pacific
To: [email protected]
Subject: [Radiance-general] Trees in the holodeck
Reply-To: [email protected]

All right, actually they are slender cylinders. The problem is,
they're growing through the cabin furniture.

???

Anyone seen anything like this? I've seen the problem on two
platforms, now--Mac OS 10.2 and Pentium 4 Linux.

Randolph

Thanks. The two OpenGL implementations are XFree86/x86 Radeon 7000 VE and Apple X11 (beta3), Radeon 9000. It's possible that the Radeon drivers have bugs.

Randolph

···

On Saturday, May 24, 2003, at 09:28 AM, Greg Ward wrote:

I believe there's a bug either in the code that determines rotation angles for cylinders in src/common/rglsurf.c or many OpenGL implementations. I suspect the former, but need to do some further investigation to figure it out for sure.

Well, I spent a couple of hours on this, and I did find a bug for some vertical cylinders, but apparently this isn't the bug causing all the problems -- at least on my Mac OS X X11 server (Apple's public beta). I still get out-of-place cylinders, and when I look a bit closer and isolate the problem cases, they render just fine. It's only when there's a whole bunch of geometry that the glu* routines in OpenGL seem to go whacky. I've given up at this point. If the bug is mine, I have no idea where it is or how it's coming about. I'm reluctant to cop out and call it an OpenGL bug, but I don't think the quadric rendering routines are all that well tested, so it's a distinct possibility. In any case, I'm giving up on it. The glrad program also seems to be broken under OS X, and I have no idea why. I wish there were some debugging tools for OpenGL, but it's all trial and error and too much error for me at this point.

-Greg

···

From: Randolph Fritz <[email protected]>

On Saturday, May 24, 2003, at 09:28 AM, Greg Ward wrote:

I believe there's a bug either in the code that determines rotation angles for cylinders in src/common/rglsurf.c or many OpenGL implementations. I suspect the former, but need to do some further investigation to figure it out for sure.

Thanks. The two OpenGL implementations are XFree86/x86 Radeon 7000 VE and Apple X11 (beta3), Radeon 9000. It's possible that the Radeon drivers have bugs.

Randolph

Hmmmm...hey, thanks for the effort. If the fix gets in soon enough I'll try to make some time to try it on the PC, though I worry about spending the time. It occurs to me it could be the same OpenGL code; if Apple is using the XFree86 OpenGL code, it would be.

Randolph

···

On Saturday, May 24, 2003, at 11:16 PM, Greg Ward wrote:

Well, I spent a couple of hours on this, and I did find a bug for some vertical cylinders, but apparently this isn't the bug causing all the problems -- at least on my Mac OS X X11 server (Apple's public beta). I still get out-of-place cylinders, and when I look a bit closer and isolate the problem cases, they render just fine. It's only when there's a whole bunch of geometry that the glu* routines in OpenGL seem to go whacky. I've given up at this point. If the bug is mine, I have no idea where it is or how it's coming about. I'm reluctant to cop out and call it an OpenGL bug, but I don't think the quadric rendering routines are all that well tested, so it's a distinct possibility. In any case, I'm giving up on it. The glrad program also seems to be broken under OS X, and I have no idea why. I wish there were some debugging tools for OpenGL, but it's all trial and error and too much error for me at this point.

-Greg

From: Randolph Fritz <[email protected]>

On Saturday, May 24, 2003, at 09:28 AM, Greg Ward wrote:

I believe there's a bug either in the code that determines rotation angles for cylinders in src/common/rglsurf.c or many OpenGL implementations. I suspect the former, but need to do some further investigation to figure it out for sure.

Thanks. The two OpenGL implementations are XFree86/x86 Radeon 7000 VE and Apple X11 (beta3), Radeon 9000. It's possible that the Radeon drivers have bugs.

Randolph

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Sorry if this is old news (I have only the 3r1p20 source installed at
the moment). I had a quick look at src/common/rglsurf.c and I think there
are some missing "glPopMatrix()" calls:

In o_cone (and o_ring) is this sequence (line 266 in my file):

   glPushMatrix();
                                   /* do base translation */
   glTranslated((GLdouble)o->oargs.farg[0], (GLdouble)o->oargs.farg[1],
                    (GLdouble)o->oargs.farg[2]);
                                   /* compute height & rotation angle */
   h = sqrt(dist2(o->oargs.farg,o->oargs.farg+3));
   if (h <= FTINY)
       return;

If this test returns 1 (ie. a "flat" cylinder) glPopMatrix() is
never called but the system is already translated. This will at least
misplace all of the following objects (up to the next "glLoadIdentity")
and it should raise an error when buffers are swaped. IIRC "Pushes"
and "Pops" have to match up.

I only used OpenGL via Python bindings (one year ago) and I'm not at all
C literate so I didn't dare looking at the rotation calculation :wink:

I think sometimes this _could_ cause this sort of display problems.

Thomas

···

On Sat, May 24, 2003 at 09:28:36AM -0700, Greg Ward wrote:

Hi Randolph,

I believe there's a bug either in the code that determines rotation
angles for cylinders in src/common/rglsurf.c or many OpenGL
implementations. I suspect the former, but need to do some further
investigation to figure it out for sure.

From: Thomas Bleicher <[email protected]>

Sorry if this is old news (I have only the 3r1p20 source installed at
the moment). I had a quick look at src/common/rglsurf.c and I think there
are some missing "glPopMatrix()" calls:

In o_cone (and o_ring) is this sequence (line 266 in my file):

   glPushMatrix();
                                   /* do base translation */
   glTranslated((GLdouble)o->oargs.farg[0], (GLdouble)o->oargs.farg[1],
                    (GLdouble)o->oargs.farg[2]);
                                   /* compute height & rotation angle */
   h = sqrt(dist2(o->oargs.farg,o->oargs.farg+3));
   if (h <= FTINY)
       return;

If this test returns 1 (ie. a "flat" cylinder) glPopMatrix() is
never called but the system is already translated. This will at least
misplace all of the following objects (up to the next "glLoadIdentity")
and it should raise an error when buffers are swaped. IIRC "Pushes"
and "Pops" have to match up.

Brilliant, Thomas! I don't know why I didn't spot this when looking at the code last night -- I did check my push and pop calls, but neglected to look at the error returns. Indeed, this is a serious bug! Unfortunately, it doesn't seem to be the one causing all the troubles, as I hopefully tried a fix to it this morning and came up with the same misplaced cylinders in my renderings, but maybe Randolph will have better luck. I have uploaded both fixes to the CVS tree.

Thanks a lot!
-Greg

I tried it on my Mac with a Radeon 9000 card, and the forest has gotten considerably smaller--I'm down to two "trees", both much shorter. Does anyone have non-ATI OpenGL hardware for a check? Also, looking at the code, I wonder--wouldn't that comparison with FTINY be unreliable where the arguments of dist2 are very large? Would that occur under any circumstances, perhaps with angles near the quarters?

Randolph

···

On Sunday, May 25, 2003, at 09:12 AM, Greg Ward wrote:

From: Thomas Bleicher <[email protected]>

Sorry if this is old news (I have only the 3r1p20 source installed at
the moment). I had a quick look at src/common/rglsurf.c and I think there
are some missing "glPopMatrix()" calls:

In o_cone (and o_ring) is this sequence (line 266 in my file):

   glPushMatrix();
                                   /* do base translation */
   glTranslated((GLdouble)o->oargs.farg[0], (GLdouble)o->oargs.farg[1],
                    (GLdouble)o->oargs.farg[2]);
                                   /* compute height & rotation angle */
   h = sqrt(dist2(o->oargs.farg,o->oargs.farg+3));
   if (h <= FTINY)
       return;

If this test returns 1 (ie. a "flat" cylinder) glPopMatrix() is
never called but the system is already translated. This will at least
misplace all of the following objects (up to the next "glLoadIdentity")
and it should raise an error when buffers are swaped. IIRC "Pushes"
and "Pops" have to match up.

Brilliant, Thomas! I don't know why I didn't spot this when looking at the code last night -- I did check my push and pop calls, but neglected to look at the error returns. Indeed, this is a serious bug! Unfortunately, it doesn't seem to be the one causing all the troubles, as I hopefully tried a fix to it this morning and came up with the same misplaced cylinders in my renderings, but maybe Randolph will have better luck. I have uploaded both fixes to the CVS tree.

Thanks a lot!
-Greg

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general