Why my object is moving/drifting towards Z direction with no reason?

Hello,

I noticed a very strange motion on my object! It's moving/drifting on Z axis with a very very small value even if no force applied on Z!

Circumstances:
- No gravity at all on the world (0 at project setting)
- No other object in the scene!
- The force is applied straight forward (realitve)
- No drag on rigidbody (I also disabled rigidbody gravity)
- If i disable collider on my object, the Z drifting still an issue

Details:
For a clean test, I started a new project (only camera + light there) and I created a simple cube with rigidbody. Turned off gravity on it (just to make sure nothing interact with this object) and also set zero to drag values (shouldn't be a problem anyway). I code a very simple script and attach to the object...

Code (CSharp):

1. using UnityEngine;
2.  
3. public class test : MonoBehaviour
4. {
5.     private Rigidbody rigidb;
6.  
7.     private void Start()
8.     {
9.         rigidb = GetComponent<Rigidbody>();
10.     }
11.  
12.     void FixedUpdate()
13.     {
14.         if (Input.GetKey(KeyCode.Space))
15.             rigidb.AddRelativeForce(Vector3.forward * 10);
16.     }

If I rotate 90/-90 the object (so I try other orientations) the result is same! The Z axis velocity is not zero... which increase only when I push n hold space (apply force).

Very strange right? If I rotate the object on Y with 90 degrees (so its forward is not point on Z axis anymore) and apply force the cube move on X axis (as this is the cube's forward now) which is fine of course! But it's also moving a bit on Z axis constantly (increasing when hold space key), but no reason to do this... no force on Z, no gravity.... doesn't matter where I rotate the object this issue still there!



I would appreciate if someone can help to figure out what is happening here!
Thanks!

 

Nobody? maybe this is a bug in the new version of Unity?

 

All tested in 2020.1.11f1

I think there are two issues caused by precision:

In the first case, with all rotations at zero, you have a small number for one axis and a large number for the other axis, functions that affect both axes will be exceeding the 7 places of precision that can be reliably maintained with a float, e.g. angle from the origin. I note that if you move the cube to 0,0,0 the problem goes away.

I believe the representation of zero is a special case that is maintained precisely, but when you rotate by 90 degrees quite a few things are happening, 90 degrees is turned into radians (90 degrees = pi / 2 radians) and then this is used as an orientation via quaternions. So it is very probable that the orientation will not remain absolutely square in the coordinate system.

You should consider that your deviation is a very small amount (a tiny fraction of a mm). I accept that under some use cases this deviation can become significant via cumulative error / scalar effects - if that is the case, you will have to catch it via code: e.g. after X physics cycles re-check absolute position and see if it makes sense relative to known positions / larger scale calculations.

Edit: I just realised I may have misunderstood the first part of your question - are you concerned that your object has drifted 0.01 mm in Z over a translation of 1 km in X? If you are, then you need to lower your expectations of single precision floating point calculations.

 

Thanks for your reply!

Probably precision is the problem, but not sure. If I put object on 0,0,0 and push it forward then I don't see any issue, but if I push it left/right or up/down then still moving on Z... of course when I move the object forward it's already moving on Z axis so it's not possible to notice the tiny difference, but I assume it's still there in this case as well.

I know this tiny drifting motion is looks negligible but it's a big problem for me! Firstly, if the ship move very fast to reach it's target in the distance (use planetary engines or something like this...) then it can greatly miss the target. Which is obviously a problem. May I can fix it by compensate the difference similar you suggested, but I would be really happy if it would be precise by default...

On the other hand, I just code an in-game function which is like a break system but with spaceships. If I press break it slow down the ship and finally it will stop the it. With the current velocity I calculate which "break thrusters" should fire to give an overall opposite force. It's quite difficult thing I don't wanna to go deep in details, you should understand what is the point of this system. It's not working perfectly if the ship always has an uncontrollable motion/rotation and cause inaccuracy.. Also, prevent the ship from full stop! I have some idiea to fix this but these would be "cheating".

Ohh, I almost forgot the explain what is the point of these things... So, if I get this inaccuracy issue when I rotate an objects/colliders, then if I want to rotate the ship (roll, pitch, yaw or the worst: mixed of these) then the rotation will not be "clear" and will cause undesired movement and rotation.. let I give an example:

If I strafe straight up, the ship start to rotate on X axis meanwhile it's moving upward... but I only applied force at the center of the mass straight up. It shouldn't rotate anywhere.. at this moment if I want to move forward, the ship start to move forward and down as it wasn't straight.. it was rotated on negative X a bit... an so on!

As you can see I don't need to travel kilometres.. the inaccuracy cumulative how I move/rotate. To be honest I don't know why the ship rotate when it shouldn't do this.. probably the same thing what you mentioned about the floating numbers and the rotations (as most of the thrusters rotated 90-90/180 degrees depend on where need to face).

Still a strange thing after we discuss it, as I never noticed this tiny inaccuracy before. Of course maybe I didn't watched this, as this is the first project where my eyes stick on velocity/position all the time as accuracy is very important here.

 

I think that's within the bounds of the physics accuracy in Unity. Note that values in the order of 1e-5 (0.00001) and below may be considered zero physics-wise. In your case the accumulated error escalates to 1e-4 (0.0001), which is still acceptable.

 

Yeah this was my though too, I have to live together with this thing... Thanks to came here to read this topic!