I know 3.814697e-06 equates to 0.000003814697, and I know I can use (float)System.Math.Round(value,2) to fix it.
I don’t know why two project print different result. I’m sure neither projects use Math.Round and scripts are same.
I print velocity during my hero jump and fall, it print 3.814697e-06 when hero touch ground and keep move horizontally.
Is there something I’m missing? Maybe somewhere I can change setting in unity editor?
EDIT:
I found rb2d.velocity.y switch between 3.814697e-06 and 0 when hero move on the plane.
I notice that though I set rgbd2d.velocity = new vector(8f, 0f) in fixedUpdate**,** but it prints (8.00001 , 0) in update.
When I set rgbd2d’s gravity scale to 0, the problem does not occur, and I get nice float value.
If I set Geometry Type in Composite Collider 2D in Tilemap to Polygons, and the problem does not occur too.
Does that affect you at all? If you’re comparing two floats with == you’re doing it wrong anyways. You should be using Mathf.Approximately if you want to compare floats. Otherwise, there’s no point in fixing it.
Thanks for replying. I have updated question.
I know it’s wrong to compare two floats with ==. I just feel strange that rb2d.velocity.y is 3.814697e-06 instead zero but it supposed to be zero.
yes, you’re right. I know it’s scientific notation.
It’s just weird that I can’t get a nice zero while other tutorial project I am learning can.
Also I notice that though I set rgbd2d.velocity = new vector(8f, 0f) in fixedUpdate**,** but it prints (8.00001 , 0) in update.
And if I set rgbd2d’s gravity scale to 0, the problem does not occur, I get nice float value.
If I set Geometry Type in Composite Collider 2D in Tilemap to Polygons, and the problem does not occur too.
I think the missing piece here is something you might not want to understand but in-case you do, you need to read-up about how floating point is implemented and how it doesn’t have infinite precision. It can/does produce different results on different CPU/devices/platforms (choose your name) which is why software that uses floating-point cannot be 100% deterministic even if it’s close enough in most cases.
The reason why you don’t compare floating-point values is the reason why you cannot expect an exact value everywhere on every CPU/device/platform. Often you are not aware of this but it becomes very apparent when the result of one calculation is fed back into the calculation for the next result. A small change results in a potential larger change next time. Physics algorithms do this but so do other systems, including (potentially) your own scripts.
Just type “floating point precision” or “floating point arithmetic” into Google; it’ll give you all you need to know.
So don’t fixate on this, it’s irrelevant and something you should always expect. Always compare values using an approximate comparison like Mathf.Approximate as mentioned above. Even physics uses such a thing to decide if a Rigidbody2D is not moving and can go to sleep: Physics2D.linearSleepTolerance.
Also, a Rigidbody2D moving along a horizontal surface doesn’t have exactly zero vertical velocity. It’ll go up/down slightly (very slightly) as gravity pushes it into the surface and the solver moves it out of the surface. It’s a balancing act. Technically this is what you do if you were to slide along a horizontal surface, you’re always slightly going into the surface and being pushed out of it; this results in friction.
Hi, MelvMay. Thanks for replying!
Can’t agree more! I know I should not fixate on this and I won’t.
Allow me to ask one last question:
Can I set Composite Collider 2D’s Geometry Type to Polygons to deal with this problem?
Well, I also curious why set it to polygons can make rigidbody2D have zero vertical or horizontal velocity.
This isn’t a “problem”, there’s no need to fix it. It’s nothing whatsoever to do with colliders.
You’ve found a way to give you zero using a specific option on your device so you’re assuming it’ll always be zero when you use that specific option on any device and it doesn’t work like that. Again, ignore it.
