Precision

Anybody have any ideas?

Well I have no idea, but if you''re doing something so complex that it requires that level of precision, you''re probably better off making your own vector and matrix classes, and handling all the math yourself. It makes much more sence just to leave OpenGL doing what it is really meant to do, which is rendering images.

quote:

---

Original post by Nemesis2k2
Well I have no idea, but if you''re doing something so complex that it requires that level of precision, you''re probably better off making your own vector and matrix classes, and handling all the math yourself. It makes much more sence just to leave OpenGL doing what it is really meant to do, which is rendering images.

---

I would *love* to (in fact I do have all of my own math classes). The problem lies in the fact that the __glMatrixRec, __glCoordRec, etc... (OpenGL internal structures) are all floats! So, even though I pass a vertex (or whatever) as a double precision number, it''s turned into a single precision number.

I don't see why that matters. You should only need the extra precision if you're performing successive calculations on the numbers, in which case you'll can store them as doubles anyway.

It shouldn't matter what OpenGL does with the numbers on a per-frame basis, rounding to the closest 32-bit float should be adequate as far as rendering is concerned.

[edited by - benjamin bunny on May 20, 2003 12:28:29 PM]

The issue is precision movement in a rather large database.
Let''s take the Earth for example. On the surface of the Earth, I''m at about 6371.0 KM. So, I''ve already eaten four digits of precision. Now, if we assume that we can successfully get 6 digits out of a float (at best 7), I only have two more digits for motion. That would give me 10M jumps! Ouch!
Now, I''m not trying to fly from Jupiter to a Gnat''s rump, but I need a little more precision than 10M.

Perhaps you shouldn''t throw your whole universe at OpenGL all at once. Nothing''s stopping you from rendering really far objects (such as distant planets) using a different coordinate system to near objects, say, measuring units per 1000km rather than per metre. You could render the far objects, clear the depth buffer, then render the near objects. This way, you have all the precision you need, and you still get to use the Z buffer (which is limited to 24-bit whatever your implementation).

____________________________________________________________
www.elf-stone.com

Hmmm... intriguing idea. What kind of additional overhead would I incur per frame?

What if I had a process whereby macro movements were made to move the entire scene near zero, then make finer movements with the "camera". Thereby, perhaps creating an overlap of precision. Here''s the idea in fuzzy math from my coffee filled mind (the numbers represent digits of precision in a float):

Macro Movements
     123456     <- "Global" movement - Continental
         123456 <- "Local" movement - Blades of grass
Micro Movements
 

The trick would be to keep the "56" of "Global" and "12" of "Local" in sync.

Does this make sense? Or, am I nuts (which might be besides the point)?

The extra overhead would come from clearing the depth buffer an extra time. You could probably avoid that by changing the near and far depth mappings with glDepthRange instead.

quote:

---

What if I had a process whereby macro movements were made to move the entire scene near zero, then make finer movements with the "camera". Thereby, perhaps creating an overlap of precision. Here''s the idea in fuzzy math from my coffee filled mind (the numbers represent digits of precision in a float):


Macro Movements
123456 <- "Global" movement - Continental
123456 <- "Local" movement - Blades of grass
Micro Movements



The trick would be to keep the "56" of "Global" and "12" of "Local" in sync.

Does this make sense? Or, am I nuts (which might be besides the point)?

---

That would probably work. Even if the global and local models didn''t line up perfectly, the local model would overwrite the global, and it would probably look okay anyway. I guess the only way to tell for sure is to try it, but in theory it should work.

It would be an interesting idea to pre-render your global model to a skybox cubemap, then only update once every 100 frames or so (since global movement is miniscule relative to local movement).

The only problem is deciding how to partition your global and local meshes.

quote:

---

You could probably avoid that by changing the near and far depth mappings with glDepthRange instead.

---

I''ll research that. I have not used that function before.

quote:

---

That would probably work. Even if the global and local models didn''t line up perfectly, the local model would overwrite the global, and it would probably look okay anyway.

---

Yes, the local model would definitely overwrite the global. However, I would need to have the models line up as I leave the Micro Zone (I could define a spherical space) and enter into the Macro Zone.

At a certain distance I could start to translate the "camera" back towards the origin as I start to transform the scene as a whole. A mathematical function could describe the relative motion of the two Zones based on distance. Or, would it be better to just transform them in one frame?

To avoid any mathematical pops and jumps, would I want to keep all of my information (matrices, etc...) as double precision? That way, at least mathematically, I could describe the blades of grass *and* the planet.

I see the biggest challenge to be making it look seamless (the ever-present goal) to an interactive user. Not only seamless, but completely useable and navigable.

quote:

---

It would be an interesting idea to pre-render your global model to a skybox cubemap, then only update once every 100 frames or so (since global movement is miniscule relative to local movement).

---

This has potential to be an interface between the Zones... Again, the transition would have to align well. I''ll research this as well.

quote:

---

[AP]
I think most video cards actually use less precision than a float, so don''t count on having full standard float precision. But if you are trying to render a whole planet, then 10 meters is really insignificant unless you are rendering it at some incredibly high resolution.

---

Less than a float? I suppose 10^-5 is less than a float, isn''t it? Need to do more research on this one. It''s not so much resolution as it is motion precision.