5

I'm writing a space exploration application. I've decided on light years being the units and have accurately modeled the distances between stars. After tinkering and a lot of arduous work (mostly learning the ropes) I have got the camera working correctly from the point of view of a starship traversing through the cosmos.

Initially I paid no attention to the zNear parameter of gluPerspective () until I worked on planetary objects. Since my scale is in light year units I soon realized that due to zNear being 1.0f I would not be able to see such objects. After experimentation I arrived at these figures:

#define POV 45
#define zNear 0.0000001f
#define zFar 100000000.0f
gluPerspective (POV, WinWidth/WinHeight, zNear ,zFar);

This works exceptionally well in that I was able to cruise my solar system (position 0,0,0) and move up close to the planets which look great lit and texture mapped. However other systems (not at position 0,0,0) were much harder to cruise through because the objects moved away from the camera in unusual ways.

I had noticed however that strange visual glitches started to take place when cruising through the universe. Objects behind me would 'wrap around' and show ahead, if I swing 180 degrees in the Y direction they'll also appear in their original place. So when warping through space, most the stars are correctly parallaxing but some appear and travel in the opposite direction (which is disturbing to say the least).

By changing the zNear to 0.1f immediately corrects ALL of these glitches (but also won't resolve solar system objects). So I'm stuck. I've also tried working with glFrustum and it produces exactly the same results.

I use the following to view the world:

glTranslatef(pos_x, pos_y, pos_z);

With relevant camera code to orientate as required. Even disabling camera functionality does not change anything. I've even tried gluLookAt() and again it produces the same results.

Does gluPerspective() have limits when extreme zNear / zFar values are used? I tried to reduce the range but to no avail. I even changed my world units from light years to kilometers by scaling everything up and using a bigger zNear value - nothing. HELP!

Curious Coder
  • 51
  • 1
  • 4
  • "had noticed however that strange visual glitches" what were your camera coordinates in the world when that happened? i suspect that these problems are caused by the precision of float's. you might be able to fix this (slightly) by scaling your world smaller, but it wont fix it perfectly. – Rookie Sep 07 '11 at 18:03
  • Well one obvious glitch occured when crossing the Z axis from positive to negative. I couldn't see why this would happen if the code worked before until the zNear dropped down. So I thought a quick-fix would be offset all coordinates so that they remain positive. That didn't help so I assume the crossing mentioned was just a coincidence. It happens in other places. I'll get specifics if required. – Curious Coder Sep 07 '11 at 19:08
  • Your next problem will be that while `float` can represent enormous distances, it has very little resolution out there. It's a binary version of scientific notation with a fixed number of significant digits. If you have a star 4.0LY away and a planet 1.5e-5LY away, the location of the planet is 4.0-1.5e-5 = 4.0LY away, oops. – Ben Jackson Sep 11 '11 at 03:38
  • Yeah, the others have answered it all, but I'd like to throw in that what you're writing seems really cool and I'd like to see the finished product. Keep it up! – Cosine Aug 29 '13 at 18:52

3 Answers3

5

The problem is that you want to resolve too much at the same time. You want to view things on the scale of the solar system, while also having semi-galactic scale. That is simply not possible. Not with a real-time renderer.

There is only so much floating-point precision to go around. And with your zNear being incredibly close, you've basically destroyed your depth buffer for anything that is more than about 0.0001 away from your camera.

What you need to do is to draw things based on distance. Near objects (within a solar system's scale) are drawn with one perspective matrix, using one depth range (say, 0 to 0.8). Then more distant objects are drawn with a different perspective matrix and a different depth range (0.8 to 1). That's really the only ways you're going to make this work.

Also, you may need to compute the matrices for objects on the CPU in double-precision math, then translate them back to single-precision for OpenGL to use.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • I had assumed this may be the case and tried to have two perspectives in place as you suggested. So when near a star system just switch to new values which will make all the stars disappear (not ideal but it is the behavior I'd except, so that's ok). I tried the different parameter approach, got odd results. At the top of my head I tried: 0.0000001f to 1.0f for close 1.0f to 100000000.0f for far But that didn't resolve the confusing orientation; when approaching an object, its distance reduces and then increases, whilst the object arcs off center! I'll try your suggested values. – Curious Coder Sep 07 '11 at 19:21
  • Your values worked better and to my surprise the stars don't disappear when changing to the star system mode. I discovered the odd behavior was _NOT_ pixels being displayed incorrectly but the corresponding text label using `glRasterPos3f()` and `glutBitmapCharacter()`. I'm at a loss as why that behaves like that when the `zNear` / `zFar` ratio goes through the roof! Any pointers will be appreciated. – Curious Coder Sep 08 '11 at 00:13
  • @CuriousCoder check the OpenGL FAQ for Z buffer and Google "znear zfar", it should all be clear. – kaoD Dec 05 '11 at 19:50
3

OpenGL should not be drawing anything farther from the camera than zFar, or closer to the camera than zNear.

But for things in between, OpenGL computes a depth value that is stored in the depth buffer which it uses to tell whether one object is blocking another. Unfortunately, the depth buffer has limited precision (generally 16 or 24 bits) and according to this, roughly log2(zFar/zNear) bits of precision are lost. Thus, a zFar/zNear ratio of 10^15 (~50 bits lost) is bound to cause problems. One option would be to slightly increase zNear (if you can). Otherwise, you will need to look into Split Depth Buffers or Logarithmic Depth Buffers

fintelia
  • 1,201
  • 6
  • 17
  • This is the answer that gets closest to the heart of the matter: zNear and zFar are not just clipping parameters: They're used to scale the z-buffer. – Ben Jackson Sep 11 '11 at 03:36
1

Nicol Bolas already told you one piece of the story. The other is, that you should start thinking about a structured way to store the coordinates: Store the position of each object in relation to the object that dominates it gravitatively and use apropriate units for those.

So you have stars. Distances between stars are measured in lightyears. Stars are orbited by planets. Distances within a starsystem are measured in lightminutes to lighthours. Planets are orbited by moons. Distances in a planetary system are measured in lightseconds.

To display such scales you need to render in multiple passes. The objects with their scales form a tree. First you sort the branches distant to close, then you traverse the tree depth first. For each branching level you use apropriate projection parameters so that the near→far clip planes snuggily fit the to be rendered objects. After rendering each level clear the depth buffer.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Thanks for your suggestions. Fortunately I realized that smaller scale objects should be relative to the larger, it makes it easier with working in their own units and should the bigger one move, the smaller follows it for free, perfect behavior for the universe! Your suggestion about multiple passes and depth buffer will be helpful when I get there. I sort of got things working on the bigger scale but there are problems on the smaller. I found navigation works best relative to 0,0,0 - anywhere else its unpredictable! Have I managed to somehow 'pivot' around those coordinates accidentally? – Curious Coder Sep 08 '11 at 00:03
  • @Curious Coder: Hard to tell without seeing some actual code. Order of operations matter and which matrices you start with. – datenwolf Sep 08 '11 at 06:33