Floating point precision

imperativity said:

Hi,

See this forum post here: https://forums.oculusvr.com/developer/discussion/740/floating-point-precision-issues

Thanks, i had a look at the post before. There is some good info. But i still dont understand realy why there is such difference in jitter since the precision should be 1000 units same as in 9999 to three decimal points. I must have it wrong, since it just dont work as expected. It just seems to me strange that i should be limited to 2000 units world size otherwise there is noticable jitter.
 Moving whole world seems like realy crazy solution to me. But perhaps its common practice ?

One thing I noticed when I ran into this issue was that the precision error was just a lot more noticeable in VR. While errors in the mm range might be ignored in non-vr applications, they are extremely jarring in vr. You basically need precision down to micrometer to ensure that calculations are accurate.

The common method for getting around this is to have a floating origin (see http://wiki.unity3d.com/index.php/Floating_Origin) if you are dealing with objects that move dynamically (i.e. things move in response to the user pushing a movement key/button).

In our application, floating origin doesn't work as our airplane follows a fixed animations for its taxi/takeoff paths. Limitations to Unity's animation system meant that shifting the origin mid-animation would breaks the animation, so we ended up using a different approach. I separated the user and its immediate area (an airplane) from the terrain and apply rotational changes to the plane, and all translation to the terrain. We apply the opposite translation to the terrain (player moving forward is terrain moving backward). I wrote a script to split animations designed as though the plane had both rotation/translation.

Our hierarchy (simplified) looks like:
Plane_Parent <--- Rotation transformations applied here
|--Plane_Geom
|--Camera
Terrain_Parent <--- Translation transformations applied here
|--Terrain_Geom

There's still potential FP error with this solution, as the terrain is still potentially placed too far a distance from the origin. However, the error is not visible to the user at that point. We also cover it up slightly through the use of fog.

delphinius81 said:

One thing I noticed when I ran into this issue was that the precision error was just a lot more noticeable in VR. While errors in the mm range might be ignored in non-vr applications, they are extremely jarring in vr. You basically need precision down to micrometer to ensure that calculations are accurate.

The common method for getting around this is to have a floating origin (see http://wiki.unity3d.com/index.php/Floating_Origin) if you are dealing with objects that move dynamically (i.e. things move in response to the user pushing a movement key/button).

In our application, floating origin doesn't work as our airplane follows a fixed animations for its taxi/takeoff paths. Limitations to Unity's animation system meant that shifting the origin mid-animation would breaks the animation, so we ended up using a different approach. I separated the user and its immediate area (an airplane) from the terrain and apply rotational changes to the plane, and all translation to the terrain. We apply the opposite translation to the terrain (player moving forward is terrain moving backward). I wrote a script to split animations designed as though the plane had both rotation/translation.

Our hierarchy (simplified) looks like:
Plane_Parent <--- Rotation transformations applied here
|--Plane_Geom
|--Camera
Terrain_Parent <--- Translation transformations applied here
|--Terrain_Geom

There's still potential FP error with this solution, as the terrain is still potentially placed too far a distance from the origin. However, the error is not visible to the user at that point. We also cover it up slightly through the use of fog.

Would something like having whole game under one parent object and then moving that parent to the origin work ? Ie if all your transforms and everything is child of this master parent, then just moving that should work theoretically right ?

I just can imagine there would be infinite amount of issues, like particles being spawned in global space would not move with the world, how about static objects and batching, what if you move them like this, does it still work ?

It seems like this could get out of hands.

imperativity said:

@CosmicSeizure

Here is some feedback from our integrations team regarding this:

"It's not about the number of
decimal points (log base 10), it's about the number of bits (log base 2). The
larger the number, the higher the exponent and the larger the steps between
successive significand (AKA mantissa) values. See https://stackoverflow.com/questions/2100490/floating-point-inaccuracy-examples."

So the problem is because the numbers are in binary and in binary 1000 and 9999 are different size, right ? That at least makes sense why it would be happening and getting worse.

CosmicSeizure said:

delphinius81 said:

....

Would something like having whole game under one parent object and then moving that parent to the origin work ? Ie if all your transforms and everything is child of this master parent, then just moving that should work theoretically right ?

I just can imagine there would be infinite amount of issues, like particles being spawned in global space would not move with the world, how about static objects and batching, what if you move them like this, does it still work ?

It seems like this could get out of hands.

Yeah, you should be able to just move that parent object. However, as your pointed out, things like particles and physics can break. The script I linked to takes some of that into account, but it might need to be tweaked.

Static batching will not work with this, as you can't change the transform of a statically batched game object. 

delphinius81 said:

CosmicSeizure said:

delphinius81 said:

....

Would something like having whole game under one parent object and then moving that parent to the origin work ? Ie if all your transforms and everything is child of this master parent, then just moving that should work theoretically right ?

I just can imagine there would be infinite amount of issues, like particles being spawned in global space would not move with the world, how about static objects and batching, what if you move them like this, does it still work ?

It seems like this could get out of hands.

Yeah, you should be able to just move that parent object. However, as your pointed out, things like particles and physics can break. The script I linked to takes some of that into account, but it might need to be tweaked.

Static batching will not work with this, as you can't change the transform of a statically batched game object. 

Good to know with static batching.

I tested having the whole scene under one parent and moving just this parent. That unfortunately does not seem as viable solution. Even tho in world position the objects are at origin, the local position is still for example 10 000, so it still messes up some things. It got slightly better, but there is still some jitter present. So it seems that only solution is probably to move each object separately.

Is it possible for you to restrict the local movement of objects such that they don't go outside the precision range? Maybe you just need more parent nodes that get marked for moving instead of trying to move one uber parent.