Floating point precision issues

The problem isn't necessarily relative. If you scale everything down by 10x (including the OVRCameraRig), then you should get 10x more range. However, it could cause precision and acceleration issues with PhysX. If you are using Rigidbody components, you may need to divide gravity by 10 to counter the shrinking of the objects. You may also have to tweak other physics settings such as the default contact offset to reflect objects' new sizes. See http://docs.unity3d.com/Manual/class-Ph ... nager.html for more detail.

"vrdaveb" wrote:
The problem isn't necessarily relative. If you scale everything down by 10x (including the OVRCameraRig), then you should get 10x more range. However, it could cause precision and acceleration issues with PhysX. If you are using Rigidbody components, you may need to divide gravity by 10 to counter the shrinking of the objects. You may also have to tweak other physics settings such as the default contact offset to reflect objects' new sizes. See http://docs.unity3d.com/Manual/class-Ph ... nager.html for more detail.

Thanks again and sorry to keep hitting you with questions.

I read this article http://www.davenewson.com/dev/unity-notes-on-rendering-the-big-and-the-small
that indicated that scaling things down won't fix the issue though I've heard both sides of the argument. An engineer at work thought scaling wouldn't help as well as once rendered the problem is no longer absolute but relative, so the increase in inaccuracy in floating points wouldn't matter. E.g. If the ship was 1 meter long and you introduce a 1 centimeter positioning error on render it will look the same to the player as a 100 meter ship with a 1 meter positioning error. I've also heard the argument that while relative the change in scale will matter as floating point numbers are "farther apart" as you increase value. Though I suppose it may depend on where the inaccuracy is being introduced, positioning or in the rendering pipeline.

Is your experience that the smaller scale does fix the issue despite the above? I can build a small test to see what happens, as this will take some time to make the change across the actual project.

Thanks again.

I did a test with scale, though its hard to tell for sure from what I can see scaling does not have a lot of effect. Looks like I'll need to move toward a solution that repositions objects to the origin.

Odd scaling will also wreak havok on the stereo camera and physics engine.

"hoesterey" wrote:
I suppose it may depend on where the inaccuracy is being introduced, positioning or in the rendering pipeline.

Exactly. The article you linked does a nice job of explaining the multitude of effects scale and FP precision have on Unity's different subsystems. If it was a camera projection issue, you would see unexpected objects missing or on top of others. If it was a physics issue, it would be more apparent when you had Rigidbodies colliding or reacting to forces.

"hoesterey" wrote:
I did a test with scale, though its hard to tell for sure from what I can see scaling does not have a lot of effect.

Judging from the behavior I saw when I moved all the GameObjects in OVR/Scenes/Cubes.unity 10000u from the origin, it looks like the head pose is losing precision when it gets multiplied into Unity's transform hierarchy. If the loss of precision is an issue with our math, or if it's a physics issue, such as quantization in the broadphase collision detection system, it may help to scale down ALL of the GameObjects (including the OVRCameraRig) equally. If eyes' modelview matrices are just spreading FP precision too thin, then you're right, scaling won't help. Either way, moving the origin will probably help. If it's hard to tell, try using a 10x larger number. It was pretty obvious to me at 10ku, but rather subtle at 1ku.

"cybereality" wrote:
Odd scaling will also wreak havok on the stereo camera and physics engine.

It really depends on what's being scaled and whether it's being accounted for in the physics and graphics settings (near clip, far clip, gravity, contact offset, light attenuation, etc).

A little youtube video of some scale tests.
https://www.youtube.com/watch?v=JHjKFnvEfM4&feature=youtu.be

Before the pause everything is scaled to 1 and offset by 30000

After the pause everything is scaled to .1 and offset by 3000

Looks like the scaling does get rid of rendering artifacts but not the Jitter. When using the OVR controller anything over 1000 does seem problematic, this is a really low number. Also I want to avoid warping things to 0,0,0 if at all possible as you can't move static objects, and moving things in general is performance heavy and error prone.

I found a solution that I think will work for my project though. (NOTE some of the graphical artifacts int he below video are due to my computer having SLI for a multi mon setup and/or some forward/deferred mix issues that I need to fix. ignore the bloom flares and black pops.)

In the first video everything is offset by 10,000 and jitter is bad.
https://youtu.be/Devy1qJ9Kvo

(in these next two videos you will notice the GUI floats separated from the ship a bit. This I believe is caused by the bug in 5.3.1p2 where a 2nd OVR controller will not match rotation with the first)

In the 2nd video everything is offset by 10,000 except the close small objects. They are placed at 0,0,0. It seams it is a relative issue. The jitter of big objects such as the ship and people isn't very noticeable even at this offset, while the small close objects now feel solid.
https://youtu.be/syXujF-8pZE

The 3rd video is the same as above except everything is offset at 9999 except the GUI (close small objects) that is placed at 0,0,0. The extra decimal gained at 9999 seams to make the ship alot more solid.
https://youtu.be/IfCLdZRk2w0

While I will lose consistent lighting on the GUI I think we can solve that with smart artistic design and some trickery. Feedback on the above solution welcome, I hope this helps someone.

Thanks again.

That jitter is consistent with what I was seeing. I was able to reproduce it despite scaling the world, so you are right - it does appear to be a relative issue. I'll see if we can do anything differently in our math to avoid the jitter when you are more than 3k units from the origin. In the meantime, thanks for sharing the workarounds you have found.

"vrdaveb" wrote:
That jitter is consistent with what I was seeing. I was able to reproduce it despite scaling the world, so you are right - it does appear to be a relative issue. I'll see if we can do anything differently in our math to avoid the jitter when you are more than 3k units from the origin. In the meantime, thanks for sharing the workarounds you have found.

You Rock! Thanks so much.

Hate to necro an older thread, but... Running into this issue as well when the camera gets ~500 units away from the origin. The fact that it's at 500 instead of 999 is kind of weird. Is there something going on in the math that makes this the magic number for noticing jitter?

I've got a floating origin solution in the works, so getting around the problem is doable. Just curious about why we are seeing this as our boundary.

As with other game engines, Unity's physics, lighting, and animation systems involve various calculations that depend on Transform.position. Floating point numbers can only represent so much range and detail. Typical applications are interested in details as small as 1e-4 and ranges as large as 1e4, but the FP representation can run out of numerical precision even before those limits. For more discussion and ways of dealing with the related issues, see http://davenewson.com/posts/2013/unity-coordinates-and-scales.html and https://forum.unity3d.com/threads/unity-able-to-manage-full-scale-stellar-systems.38782.