koobas.hobune.stream
"bleeding" when using configurable joints
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?
I feel this is related. $$anonymous$$aybe it can serve to help you a bit. http://answers.unity3d.com/questions/31877/limiting-physics-to-x-and-y/31879
I created a small demo scene to replicate this "error" - now in this one the Z drift is ranging between e-3 and e-6 - to all objects. I locked all moving objects with Z motion and angular X and Y motions. Drag and Angular Drag are set to 0. If anyone is interested - it can be downloaded from : http://www.speedboxtech.com/test4.zip (390$$anonymous$$B)
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.
Number rounding alone doesn't really explain why it'd drift in Z though. What am I missing? You seem pretty confident about your answer. Things like these bug me all the time.
$$anonymous$$y apoligies if that offended you, I got a bit excited, I usually doubt answers to the point of brutal scrutiny, particularly my own. The movement I can not explain without understanding the causes of the motion. The number changes however on that small scale are (even if my answer is not correct) not of any effect to the object. $$anonymous$$aybe it could help to see if this occurs on specific parameters alone. Such as having a rigidbody or not.
Well , logically speaking , if you drop an object in a normal physics environment ( non - virtual ) can you expect it to fall down without having the slightest of course changes? Is there some drag applied? If so a non perfect sphere will have a millionth or so difference depending on the triangle amount it consists of will causes Z changes during the drop. Since you can not make a perfect sphere with triangles and current technology in any case, just mimic it to a depth of accuracy where it becomes far less relevant.
Yes, I know it is a very very small number but I was under the impression that when Z motion is locked, it will lock it to 0 without even the smallest drift..
@Proclyon "$$anonymous$$y apoligies if that offended you" > No, not at all. I just realized I don't know whats going on and since you said you were 100% sure why, I thought I wanted to know more. That's all :) I actually upvoted you. Your next comment is great in the sense that we shouldn't expect the world to be a perfect model, since it is way more complicated than we can model in a simulation. I couldn't agree less. It's a great way to accept the fact. However, for this particular case where we want to reduce one dimension and go 2D, it would actually help to ensure that Z movement is perfectly locked.
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.
I thought about manually setting the Z to 0, but was unsure how it will impact on performance .. if it's going to be 3.6e-6 it might be ok :)
