Large vertex coords get corrupted

[sansan]

Hello all!

I'm really embarassed by a strange effect I'm getting with my OpenGL scene.
The scene contents is really simple: it's a box with side length = 1.0. If I just draw the box, everything is fine - see the first snapshot below.

http://s50.radikal.ru/i129/1006/72/76e54a860134t.jpg (http://radikal.ru/F/s50.radikal.ru/i129/1006/72/76e54a860134.png.html)

But what I need is slightly different. The box should be located at point (1e+6, 1e+6, 0.), not at the WCS origin. Actually the vertex coordinates come from an external file, so they are translated already by the above-mentioned values, and I just need to move the view CS so that the box is inside the viewing volume.
The result is shown on the second snapshot.

http://s09.radikal.ru/i182/1006/67/8ca67d1b4e31t.jpg (http://radikal.ru/F/s09.radikal.ru/i182/1006/67/8ca67d1b4e31.png.html)

Obviously, the vertex coordinates are corrupted. It becomes even more obvious when I rotate the model: vertices do not move smoothly, they "jumps" in the scene as if they were snapped to some invisible "grid" with some rough step.

The first idea that came to my mind is that the coordinates are large (about 1e+6) and after applying the translation to "move" the box into the viewing volume there are some round-up errors. Does my idea have any connection to the OpenGL reality?
What is the internal representation of vertex coordinates? Is it usually a 4-byte float? Is it hardware-dependent?

But I was really surprised when I imported the file with the box into the third-party 3D modeler that was used to build the model...and the system displayed it correctly!

If I'm right and some loss of precision takes place, how can I manage this to make the box look fine in my application? Note that I have to draw the model coming from a file "as is", I cannot recalculate its geometry to shift it back to WCS origin.

Otherwise, what might be the potential reasons for this effect?

Thank you a lot in advance for hints!
Sergey

[ZbuffeR]

The first idea that came to my mind is that the coordinates are large (about 1e+6) and after applying the translation to "move" the box into the viewing volume there are some round-up errors.
Knowing that glTranslate is deprecated, how do you apply the translation ?
Most 3D hardware can not handle double, so if you need more than 6 decimal digit of precision, do it yourself with double precision.


Note that I have to draw the model coming from a file "as is", I cannot recalculate its geometry to shift it back to WCS origin.
Too bad, because that would probably solve the problem. And should be how the third-party modeler do it.

There has been quite a few discussions about this topic in the last month, you should be able to find more detailed information on this forum.

[Aleksandar]

I'm really embarassed by a strange effect I'm getting with my OpenGL scene.
In fact it is a very common effect. It is quite normal if you are "playing" with such huge numbers.


If I'm right and some loss of precision takes place, how can I manage this to make the box look fine in my application? Note that I have to draw the model coming from a file "as is", I cannot recalculate its geometry to shift it back to WCS origin.
How comes? You should not recalculate geometry. When you read coordinates from the file, just calculate the bounding box and "shift" its center into appropriate position according to viewer position (subtract bbox center from the vertex-coordinates).

If you really want to deal with huge numbers, GPU RTE is ultimate solution. :D

[sansan]

Knowing that glTranslate is deprecated, how do you apply the translation ?

Still using OpenGL 1.x and good old glLoadMatrix. We have to.



Most 3D hardware can not handle double, so if you need more than 6 decimal digit of precision, do it yourself with double precision.

That's what I was afraid of...thanks for confirmation!



Too bad, because that would probably solve the problem. And should be how the third-party modeler do it.


Then I have to do the same things in my app, as there seems to be no other way to resolve the problem.



There has been quite a few discussions about this topic in the last month, you should be able to find more detailed information on this forum.

Found this post so far:
http://www.opengl.org/discussion_boards/...true#Post278464 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=278464&Searchpa ge=1&Main=53746&Words=precision&Search=true#Post27 8464)

a sort of similar problem when float precision is not enough - and the conclusion is: "Do everything yourself until you get the numbers that fit float precision - and then pass them to OpenGL". Do I understand it correctly?

[ZbuffeR]

My bad, I meant months.
This one is quite detailed :
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=273980&page=1



"Do everything yourself until you get the numbers that fit float precision - and then pass them to OpenGL". Do I understand it correctly?
-> exactly.
There are other ways such as hinted by Aleksandar, GPU RTE or even true double precision hardware (costly and not very powerful currently).