Hi, I have a scene with some objects (cubes and/or spheres for that matter) falling down in 2D (XY plane). I Locked the Z motion and checked "configured in world space", and it does seem to work - however there is a strange "bleeding" problem on the Z axis - the Z position changes - but with very small numbers ( -3.312148e-06 and so). Anyone knows why this happens?
Yes I am 100% sure of it aswell!
Floating point values are rounded
I am not sure if you are familiar with scientific decimal notation, please don't be insulted if I do explain, I just can not assume you do :)
-3.313148 * 10 ^ -6 just means the point moves 6 to the left -0.....and so on 3313148
ea
VERY VERY VERY small number
In astronomy this is very common where values are beyond your and my imagination and such notations are not even a choice (Even lightyears really aren't that big). Otherwise you would just run out of paper and pens.
This rounding value is done automatically. You just need to ignore it. The value is infinitesimal and will not have any effect. But I am not 100% sure it will pass a value = 0.0f check. You could check. If so just have a minimum domain of -0.00001f and a max of 0.00001f and clip every 0 measurement between that for the same effect.
EDIT:
That changes everything (see below comments). I can only speculate on the cause as your question mentions. Possibly drag on triangles ( wind will always have an effect on triangles with their flat surfaces, no matter how small you make them to build a sphere. 0.001 is definatly not a value to simply be brushed away as irrelevant in this situation I believe. If not so I would never blame rounding on a value this large at least. Well I don't have more answers. But I have an idea. Script a Z-Clip script like I did for rounding. Make the domain between whatever you find acceptable and FORCE the object to always remain in that position by nudging it back.
I can't explain it. There shouldn't be anything modifying the Z component given the Z starts in 0, and is falling without any velocity or force in Z. It just shouldn't happen. I doubt it is rounding alone because even operations like normalizing the velocity would set Z to 0, since it was 0 to begin with. 0 / whatever is always 0. I think it might be something with the joints code that attempt to maintain its position. Or it can be rotational forces acting on it.
I don't know if this fix or breaks anything for you but you can try manually setting z to 0 in FixedUpdate.