Cube stuck on its edge

[FSA]

In the demos, the cube seems to get a little bit stuck on its edge. I would expect it to be stable at one point, but in the video you can see, that I rotated the cube a little bit further and it is still stable.
Is that expected or considered a bug?

Video: https://youtu.be/DYmxgG-hc00

[Julio Jerez]

Um, that should not happens not.
The probability that a cube state on its edge in real life is not zero, but in practice it is impossible for a sharp cube.

In the engine the probability is much higher because the contact points of two colliding shape is the intersection.
Since the intersection is always a polygon, when if is is the case that the cube center of mass land inside the contact polygon, plus it's linear and angular velocities are zero, then the solver bring it to sleep.

Here we know that the cube velocity are zero because the pick joint guarantee that, but the contact polygon should be a line instead of a polygon. So the probability should be way less than we see.. But you seem to make happen quite frequently, so I guess the bug is in the contact routine.

In newton 3.14 the type of contact is report back so when the contact are calculate it check if it is point, line of face, and each feature is handle appropriately, my guess the bug is there.
I will verify later.

Can you do this test?
please enable the option show contact point, then when it happens, get a close up, and see if there are more than two contact point.
Second when it happens go to the menu option and disable auto sleep and see if it still rest on the edge.
Those two test can show where the problem might be.

[Julio Jerez]

ok fixed now.
that was a bug that I carried from 3.14
in 3.14 when the acceleration of a body was too small, it is clamp to zero.
this is done in the integration routine.
when the code was ported over to 4.00 I left that check there.
but the an improvement in 4.00 is that the sleeping loop and the integration loop are separate passes. When I separate them, I left that part in the integration routine, that was the bug, because the sleep routine check if the body velocity and acceleration, but accelration was already zero. so teh rest code kick in base of teh velocity only.
moving the clamping of acceleration to the sleeping loop fixes the bug.

one heuristic that is applied is that if the body is part of a very small island than the acceleration threshold is made for time smaller. there is not physical reason for that but the is a practical one.

when bodies are part for a large island of connected joints, the acceleration reduces very gradually to zero, and in fact some time it never fall below some small value. this is an inevitable consequence of discretizing the equation of motion and solving it with a iterative linear system plus a numerical integration. on the other hand for small islands, the solver can drive the acceleration to a much smaller value. so I make use of that practical fact and use an arbitrary number called small island size to make the check to use different accelration thresholds.
also as I said before there accelration is not zero. in fact is a value far from zero. about 0.015 m/sec2

I am one of those people that if a value is 1000 smaller than another, then that value can be neglected. so 0.01 is much smaller that normal gravity.

what this means is that there is the possibility that box land on it edge is not zero, but it is also far larger that a real life cube doing the same thing. if you try real hard and the acceleration and velocity both fall below that threshold for more than one frame then sleep system will freeze the body and it will not get mode updates.

having said that I dare you to make it happen again.
if you sync I set the demo as the default.

[FSA]

I was able to do it again, however the cube is much more sensitive now. I think this is expected?
Video: https://youtu.be/zYqwL4lyz_U

[Julio Jerez]

I think that's a reasonable behavior. remember in teh projection of teh center of mass over the floor fall on teh edge, and is just happens that the velocity and accelerations are zero, the the cube will state there. that's the ideal case, but there are many variations of that.
thing like a round or bevel edge a soft surface can also provoke teh cube go to rest on the edge.

let us leave like that for now and if it happen too frequent you can make more restrtive

ther check happen in function void ndDynamicsUpdate::UpdateIslandState(const ndIsland& island)
line 1130.

you can see that for a very small island teh rest accelration is made 0.25 the rest accelration of a larger island. that can be made a define. but I think thsi is good enough for now.

you can experiment making even smaller say (0.125^2)
but remember doing that at the expense of the engine do much more work when many small loose bodies are moving around.

[Julio Jerez]

This was fixed and should not happen as frequent.

Remember, the case of a body resting on and edge is a physical possibility in nature.

All you need is that the center of mass rest over the contact and the velocity of the contact to be contant and the acceleration to be zero.

It just happens that it is an even with very low probability, but low probably does not means impossible.

It just happens that a numerical simulation has to make approximations.
For example the contact is rare a single point, instead is a small polygon. The integration is discrete, so constact velocity not longer constant criteria but within some threshold for some period of time, same goes for contact acceleration.

All these things make the probability of resting on and edge higher for a numerical simulation.

But not withstanding those limitation I believe it is quite good now.

[FSA]

Did you change something since the fix in January? For me the behavior is ok. It's an extreme corner case anyway, and should not really happen, unless the player really tries to balance the cube.

[Julio Jerez]

Oh probably not, I was revisting the generic solver fir making a opencl version and I saw a note about the tolerance for sleep, and I remember this question.