Identical 3D cubes falling to ground don't have identical Y positions

[sszigeti]

Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

System information

Windows 11

Issue description

Some identical 3D cubes are falling to a ground, yet, upon landing they don't have the same Y position values.

I experience the same with the default physics engine and with Jolt too.

Steps to reproduce

Please check out the attached MRP, and the screenshot:

Minimal reproduction project

Godot_Cubes_Inconsistent_Y_pos-1.zip

Here's the public repo for easy reference: https://github.com/sszigeti/Godot_Cubes_Inconsistent_Y_pos

[Stwend]

It seems to me that the cubes are not identical. When opening cubes.tscn with a text editor, you can see the transform matrices are the same, but the origin points are different for each cube's Transform3D:

[node name="Cube" parent="." instance=ExtResource("1_nenpw")]
transform = Transform3D(1, 0, 0, 0, 1, 0, 0, 0, 1, 2, 1, 0)

[node name="Cube2" parent="." instance=ExtResource("1_nenpw")]
transform = Transform3D(1, 0, 0, 0, 1, 0, 0, 0, 1, -1, 2, 0)

[node name="Cube3" parent="." instance=ExtResource("1_nenpw")]
transform = Transform3D(1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 1)

//edit: Scratch that. I mistook Y for Z and didn't realize the bug was them not stopping at the same height when colliding with the ground.

[mathphye]

In computers simulations are not 100% accurate, the question is how much tolerance is allowed?

The difference between the 'cube' and 'cube3' is around 0.000002, which is good or bad? ... again (how much tolerance is allowed?)

The 'cube2' has a variation of 0.001 which could be considered high. Usually, for games precision is not mandatory. Even in the real world, you won't find that they end in the exact same y-value, as roughness or particle noise would add an error.

... To get better results you could double the bytes used for describing its position:

https://docs.godotengine.org/en/stable/tutorials/physics/large_world_coordinates.html#:~:text=Large%20world%20coordinates%20(also%20known,types%20is%20much%20more%20limited.

https://www.reddit.com/r/godot/comments/15r7i53/godot_and_double_precision/

[AThousandShips]

It looks like the two cubes are touching at the corner and that one of the cubes is slightly snagged, does this happen when the cubes are not close enough to interact? They also have margins around them that influence the physics

[sszigeti]

@AThousandShips, by "margins" do you mean the margin of the BoxShape3D inside the CollisionShape3D node? Its tooltip states that "This is not used in Godot Physics", so I wonder if this would be applicable here. By the way, I haven't changed those values from their defaults.

Setting them to 0 didn't make much difference, so perhaps this imprecision is just a question of allowed tolerance that @mathphye has mentioned, and this isn't actually a bug.

[AThousandShips]

I mean the solver bias, but can you confirm that this happens when they don't collide on the corner?

[sszigeti]

@AThousandShips : I moved Cube2 (the leftmost) away, and this didn't seem to affect that its Y position is "considerably" different as compared to the other two cubes, so I'd say it's about the same as it was before.

As for the solver bias, I have found this at physics/3d/solver/default_contact_bias, and it has the default 0.8. I have tried changing it to 1 and to 0.01 but I haven't seen a meaningful difference in the results. Perhaps I'm still not looking at the properties you've meant -- apologies for that, I'm still a noob at 3d.

[AThousandShips]

Please do not tag me when it's just us chatting here

You have it right on the shape, it's called Custom Solver Bias, right next to the Margin

However I can confirm this specific behavior, I suspect it has to do with the impact from elevation, unsure what causes it here

[sszigeti]

I see, thank you. I haven't touched any of the shapes' custom solver biases, they are all on 0, so they should use the defaults I've tried to tweak in my previous response.

[AThousandShips]

That is kind of off topic as it was related to the possibility of them connecting

It does seem to be related to penetration, where the box penetrates deeper when it impacts from a particular elevation

Edit: That is in fact the issue here, the difference is within the physics/3d/solver/contact_max_allowed_penetration margins

So not a bug I'd say, but within the normal behavior of the engine, and in this case that cube has the most correct position, where the others slightly penetrate the floor

To improve behavior try Collision Priority on the body, or physics/3d/solver/contact_max_allowed_penetration

[mathphye]

Surprisingly I got all the numbers equal (y position), using these settings:

• I suspect it increases instability, like making tiny gaps oscillate. So, be aware.