Precision Loss for very large positions in a level

A place to discuss everything about the Orxonox framework.

Moderator: PPS-Leaders

Post Reply
User avatar
youngk
Noxonian Warkmrghon
Posts: 16
Joined: Tue Sep 29, 2009 12:10 pm
Location: Zurich

Precision Loss for very large positions in a level

Post by youngk » Mon May 16, 2011 2:08 pm

Title explains everything.

For very large values of the in-game position all position dependent functions will lose precision (eg. aiming position or spaceship position and other). This in turn leads to a jittery effect.

To reproduce the problem, start earth.oxw and use the portal to travel to the Moon.

Positions are currently stored in Ogre Real format, which is of type float. This makes it very hard to increase the possible range of values for positions (ie. by using double format).

Either we commit to making small (positions and sizes smaller than 5th order of magnitude) levels, or we investigate in increasing precision to enable large levels.
Постич?

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Precision Loss for very large positions in a level

Post by x3n » Mon May 16, 2011 9:15 pm

Yeah that's really a problem. I kind of expected that, though not so early. I don't see an easy solution, since we use Ogre classes for position and stuff. I think Ogre Real could be defined as double, but I assume that wouldn't be compatible with the common Ogre packages. Additionally Reto converted all doubles to floats just recently because of some potential trouble in combination with directx (if I remember correctly)...

So there are basically two solutions I see after a very short thinking, but none of them is easy or nice.

1) Use different scenes - in every scene the portal is near position (0, 0, 0) - as long as the player stays close the center (close in terms of about a million units, so not a real problem) we won't get problems with precision. There are 2 problems though: A) WorldEntities can not move between scenes, you'd have to destroy and re-create the SpaceShip and all its attached entities. B) Scenes are completely separated, you can not place the earth in one scene and the moon in the other and still see both, you only see the objects in your scene

2) Attach the spaceship to the portal after jumping through it - that way the precision of the portal will still be inaccurate, but it doesn't move. The spaceship however which does move will use relative coordinates to the portal and as long as it stays close (definition see above) to the portal, precision may be ok again. But there are also two problems: A) Ogre will have to add the two floats in order to get the final position of the spaceship. There you get precision problems again, but the internal float representation of the CPU is more precise than 32 bit, so it could work out. B) You can not attach physical entities

So you see, not really a solution at the moment :(
Fabian 'x3n' Landau, Orxonox developer

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Re: Precision Loss for very large positions in a level

Post by greenman » Tue May 17, 2011 2:59 pm

hm, this sounds like a tough problem...

x3n, what does ogre use internally for absolute position computation if not "normal" floats? i don't really understand why these internal floats should be any different than normal ones ?!

why is it not possible to attach a world entity to a different scene, is that a technical limitation of ogre or just not implemented (by us) yet ? (i mean i can see various problem esp. with the network, but maybe we can solve these)
if we could use separate scene we'd have to place miniaturized versions of earth/moon in the according scene...
There are only 10 types of people in the world: Those who understand binary, and those who don't.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Precision Loss for very large positions in a level

Post by x3n » Tue May 17, 2011 6:14 pm

greenman wrote:x3n, what does ogre use internally for absolute position computation if not "normal" floats? i don't really understand why these internal floats should be any different than normal ones ?!
Well, I wrote "the internal float representation of the CPU is more precise than 32 bit", so it's not really something that Ogre does but rather the CPU. However I'm not sure if this is really true, but I think I read something along these lines and also wikipedia writes something about a "dedicated floating point processor with 80-bit internal registers" in the x86 architecture.

So in C/C++ we have floats (32 bit), doubles (64 bit) and long doubles (80 bit), but your CPU most certainly has only une FPU which operates with 80 bit. So if you're lucky and you add two 32 bit flots, you may still get a result with (long) double precision.

These are just handwaving arguments though, neither am I sure if this is true nor did I ever test it, but if we're really desperate this may be worth a try.
why is it not possible to attach a world entity to a different scene, is that a technical limitation of ogre or just not implemented (by us) yet ? (i mean i can see various problem esp. with the network, but maybe we can solve these)
Last time I checked (which is quite some time ago, so please check it again) Ogre didn't support moving scene-nodes or entities from one scene to another. I think that's mainly the case because you don't just create a scene-node and assign it to a scene, but you rather ask the root-scene-node of a specific scene to graciously create you a child node. Now of course our space-ship is neither a scene-node nor an Ogre entity, but it possesses both, so right know we would have to destroy the ship and spawn a new one in the other scene. We could do better though, but Ogre probably won't help us much.
if we could use separate scene we'd have to place miniaturized versions of earth/moon in the according scene...
Yes exactly, except that they don't have to be miniaturized, sizes should remain the same (but we can use low-quality models and textures)
Fabian 'x3n' Landau, Orxonox developer

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Precision Loss for very large positions in a level

Post by 1337 » Sun May 22, 2011 6:24 pm

x3n wrote:
greenman wrote:x3n, what does ogre use internally for absolute position computation if not "normal" floats? i don't really understand why these internal floats should be any different than normal ones ?!
Well, I wrote "the internal float representation of the CPU is more precise than 32 bit", so it's not really something that Ogre does but rather the CPU. However I'm not sure if this is really true, but I think I read something along these lines and also wikipedia writes something about a "dedicated floating point processor with 80-bit internal registers" in the x86 architecture.

So in C/C++ we have floats (32 bit), doubles (64 bit) and long doubles (80 bit), but your CPU most certainly has only une FPU which operates with 80 bit. So if you're lucky and you add two 32 bit flots, you may still get a result with (long) double precision.

These are just handwaving arguments though, neither am I sure if this is true nor did I ever test it, but if we're really desperate this may be worth a try.
There is a way to set the FPU precision permanently so that even double and long double are treated as floats when it comes to computations. Even though the FPU might be 80 bit, 32 bit computations are faster.
DirectX for instance sets the FPU precision to 32 bit at startup. It can be prevented by selecting a different FP model in the Ogre configuration dialog. But I don't see this a solution.
Instead we should focus on resolving the actual problem, not mitigating the symptoms.
However, I cannot produce a good solution here.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Precision Loss for very large positions in a level

Post by x3n » Tue May 24, 2011 2:00 pm

I just stumbled upon a page in the Ogre wiki which addresses the precision problem. The page lists features that are planned for Ogre 2.0. Support for very large worlds is part of it:

Development plan for OGRE 2.0 aka 'Tindalos'
http://www.ogre3d.org/tikiwiki/TindalosNotes
SceneManager redesign
* Very large world support (deal with precision issues at large coordinates)
Here's a thread where they discuss possible implementations:
http://www.ogre3d.org/forums/viewtopic.php?t=30250

Note however that this thread is from 2007 (!) and now we're in 2011 and Ogre 2.0 is still just a very rough draft, so I wouldn't expect this problem to be fixed soon. In fact I wouldn't even expect it to be fixed ever.

So for us this means we need to find a workaround.


Here's another thread in the Ogre forums about the same topic (also from 2007) with some proposed workarounds:
http://www.ogre3d.org/forums/viewtopic.php?t=29427

Then I found yet another interesting thread which sounds like there's already a solution for this problem, but only in the "Portal Connected Zone" scene manager:
http://www.ogre3d.org/forums/viewtopic.php?t=54392


Looks like we should try the possible solution using the "Portal Connected Zone" scene manager. If that doesn't work, we can use different scenes as a quick fix. Later we could try to implement some sort of paging for the world and whenever the player moves to a new "page", we move this page to the center of the world.
Fabian 'x3n' Landau, Orxonox developer

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests