I’m just curious about the maximum coordinates? How big can objects be? I know, that the z-buffer will be very coarse then, but can I tell the near/far clipping plane to be e.g. 1e20 and put a 1e19 sized cube in it?

# Maximum size of coordinates?

As long as you keep your coordinates inside the valid range of a float/double, I see no reason why it shouldn’t be OK.

And concerning Z-buffers. The projected Z-coordinate are normalized by the projection matrix to the range [0.0, 1.0], meaning 1.0 always refer to the far plane, and 0.0 to the near plane. So the Z-buffer won’t loose any precision because you want huge values for your near/far planes, as you stated

I think that there is a problem with using large numbers in some situations. I posed a similar question in http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/002210.html . My problem manifests itself in a disturbing jitter of my scene when I use large coordinates such as those normal in the Earth Centered Inertial (ECI) reference frame. When I subtract the coordinates of the scene center from all of the coordinates (effectively centering the scene around 0,0,0) the problem goes away.

I did receive an email from Waleriy Sokolov of Bridges Software Company suggesting that I look into the glDepthRange() function however, I have not yet had the time to do so.

If you find any answers here I would sure like to hear them.

[This message has been edited by pleopard (edited 03-05-2001).]

Hello,

it’s far more likely to be floating point issues than glDepthRange stuff. According to the IEEE spec on floats,

a + b = a

for very large values of a and relatively small values of b =)

its to do with, <er, thinks back to numerical methods lectures> representation issues. uhm, like if

a= 100 000 000 000 000 , and

b= 0.000 000 000 000 001

then a+b is

100 000 000 000 000.000 000 000 000 001

but if you can only store 9 digits of the mantissa, then you’re going to lose the 10^-15 and just get:

100 000 000 * 10^6

er, so, when you subtract everything to get the scene based towards zero , then it sounds like you’re bringing all your numbers relatively close to each other, uhm, or something. <sheepish grin>

cheers,

John

John I think you hit the nail on the head. It is a precision problem. In my original question I was wondering if the glu calls were implemented using floats even though the parameter lists used double numbers.

In the case where I subtract the scene center coordinates from all of the scene coordinates, my range of values is less than 500,000.