Collision missing

[zak]

I have two dynamic bodies with box shape. Sometimes, when the boxes collide, the engine misses the collision and even OnAabbOverlap () is not called.
The bug occurs when the two boxes collide with a certain orientation and does not occur with other orientations. It is always reproducible.
I checked the values m_minAABB and m_maxAABB of ndBodies and OnAabbOverlap() should be called and instead it is not. What other parameters should I check to help fix the bug?
(the problem is not present on 3.14)

[Dave Gravel]

Maybe you can make a little video for show the orientation to get it happen,
And write here the values that you use for get this orientation.

[zak]

And write here the values that you use for get this orientation

I am trying to do this.

I have positioned two overlapped dynamic bodies without any velocity and omega. In the first step of simulation i returned false in OnAabbOverlap() but from the second step OnAabbOverlap() is no longer called and the two bodies remain overlapped for ever. I think there is something wrong with this.

[Julio Jerez]

I have not seen a bug like that in a while. But could be posible.

You say it is reproducible. Could you post here the code you use to reproduces the error?

Maybe hack it in in one of the demos.

[Julio Jerez]

I have positioned two overlapped dynamic bodies without any velocity and omega. In the first step of simulation i returned false in OnAabbOverlap() but from the second step OnAabbOverlap() is no longer called and the two bodies remain overlapped for ever. I think there is something wrong with this.

Are you saying that if two bodies overlapped and you return false in the onBody overlap.
That you do not get any more sub sequence calls? And the bodies do not collide?
The expected vehavior is that the bodies should not collide as long ar you return false, but as soon as the call back return true the should collide.

My guess is that since you said the velocity is zero, and they are not moving, the bodies are put to sleep by the solver if the gravity is zero. This is because there are not forces acting on the body.
Did I get that right?

Also if you are going to make a repro, please make sure you sync, I just made some changes to make some freelist allocator thread safe.

[zak]

The expected vehavior is that the bodies should not collide as long ar you return false, but as soon as the call back return true the should collide.

This is not happening.
I place two overlapping bodies with velocity and omega zero, no forces and torques applied, autosleep set to false. This is what happens:
1) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
2) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
3) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
4) and so on
the two bodies remain overlapped for ever, and OnAabbOverlap() is no more called, so i cannot return true.

[zak]

I synced the latest version and ... wow! bug is fixed.
Bug is present in yesterday version so it was fixed by changes in the last 6 commits.

The expected vehavior is that the bodies should not collide as long ar you return false, but as soon as the call back return true the should collide.

This is not happening.
I place two overlapping bodies with velocity and omega zero, no forces and torques applied, autosleep set to false. This is what happens:
1) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
2) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
3) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
4) and so on
the two bodies remain overlapped for ever, and OnAabbOverlap() is no more called, so i cannot return true.

This however is still present. It is not related to boxes, it also comes with sphere shapes.

My guess is that since you said the velocity is zero, and they are not moving, the bodies are put to sleep by the solver if the gravity is zero. This is because there are not forces acting on the body.
Did I get that right?

Yes, i have seen that is related to sleep. I have setted bodies with SetAutoSleep( false ) but bodies go to sleep equally. So i have seen that if i call SetAutoSleep( false ) every step bug is gone!
1) Shouldn't be SetAutoSleep( false ) called once and always be active, so that body never goes to sleep?
2) Shouldn't be OnAabbOverlap() called even if bodies are in sleep state?

I have also noticed that AABB values are greater in each dimension by 0.125.

[Julio Jerez]

Ok the good thing is that at least some part are working better since last commits.
Yes this week I started to change some of the sequential branching logic from 3.14 and lower with more streamline passes that are probably slower and use more memory, but that scales better with multicores and are more lock free.
One such change is the status of a sleeping body.
In newton a sleeping body is one that is not under the influence of external forces and has zero momentum.
This definition is great because matches what the laws of physics defines for a body in equilibrium.
At least one special case, because a body with constant linear momentum is also in equilibrium but more on that later.

The state of equilibrium of a body is determined only by the solver and integration step. And there is a flag that keep track of that.

Bodies in equilibrium can be excluded from the solver.
In the early days of newton this was done only for performance reason, but we figured out that excluding sleep bodies from the solver is not only good for performance it is also even more important for accuracy.

The reason is that let us say we have a pile of objects of interconnected bodies, like a wall.
When the wall is at rest, all bodies are at rest.
But let us say something perturbed few bodies in one end.
It is simply not true that the bodies on the other extreme will fell the effect. This is because in nature bodies are elastic and it takes energy to Transmit the motion from one end to the other, so if the perturbation is not very big, the enery dissipate.

In a rigid body simulation elasticity is not present so the entire is activated.
But this is a huge problem since the condition number of the mass matrix of the system is a funtion of how many row are in the matrix.

To solve that, we introduce the internal damping adding a small diagonal relaxation on the left side and penalty on the right side.

You can see that behavior by turning the debug display and see how bodies switch color from white to blue even when they are part of the same island.

This introduces a far more comple logic to keep track of sleeping bodies. Because like I said, if you set a body to non sleeping the system to build huge island simply because a body part of a pile of bodies.
This is what explain that the sleep flag is on after the first step even when the body is set to autosleep off.

This leave us with two mode of operations.
The first is when the body is set to auto sleep.
In that case the behavior you described below is what is expected

I place two overlapping bodies with velocity and omega zero, no forces and torques applied, autosleep set to false. This is what happens:
1) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
2) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
3) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
4) and so on
the two bodies remain overlapped for ever, and OnAabbOverlap() is no more called, so i cannot return true.

And you saw that is correct now.
What is not correct is that you are setting not autosleep but the bodies are acting the same way, and that is indeed a bug.

The expected behavior should be the same but you should get the onaabboverlap call every tick

I will fix that today.

[Julio Jerez]

The secund part is that you see the aabb of a body been 0.25 larger than a tight aabb.
Yes this is correct.
This is an optimization that prevent churning of creation and destruction of contact joint as bodies goes from equilibrium to active in the same island.

As I say before a body can be sleep or awake, but that state change a lot when they are part of a large set of bodies.
If the aabb was so tight this causes lot of activity on the Collison system for not reason.

To solve that, a body is represented by a quantized box sleeping on the broad phase.
A body is box sleeping if it does not crosses the quantized aabb after the new aabb is calculated.
This reduces the number of pair that the scanner has to search each time a body is active.
It add more inactive joints, but for that we also add the comcept of active/inactive joint.

[Julio Jerez]

ok if you sync again you soudl get the thsi have behavior when setting auto sleep off

1) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
2) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
3) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
4) and so on

and this when auto sleep is on
1) Wordl.Update() - OnAabbOverlap() called - false returned - bodies remain overlapped - OK
2) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
3) Wordl.Update() - OnAabbOverlap() is not called ! - bodies remain overlapped
4) and so on


on this

1) Shouldn't be SetAutoSleep( false ) called once and always be active, so that body never goes to sleep?
2) Shouldn't be OnAabbOverlap() called even if bodies are in sleep state?

again, the concept of sleep is newton 4 is more sophisticated than a flag the
SetAutoSleep( false ) mean teh body get the inputs, teh callback, and get integrated. but the solver determine of the body is part of the solution or not. onel bodies that are not in equilibrium are part of the solution. this is diffrent than earlly version 3.xx where autosleep of meant a body is part of teh island. but the latest version of 3.xx (3.12 and 3.14) this new concept started to be added and is a major part of the new ways of 4.00

OnAabbOverlap(). no, if they are sleeping and in equilibrium them is not not called.
I know that it seems that is should be called simply because they are overlapping, but that impose such a huge penalty in the engine for a very small payoff, that I decide it is better this wasy.

you can check this by looking at file ..\newton-4.00\sdk\dCollision\ndScene.cpp line 1490

you can see that when the engine is going to performe the scene scan, if first determine how many bodies in teh scene are not in equilibrium.

if more that 2/3 of the bodies in the scene are sleeping and in equilibrium
the then engine does tow sweep and prune scans. on teh active bodies.
if not is does a sweep and prune on all bodies.

when doing a single sweep and prune on all bodies this check all pair. and because contact are generated onle when aabb overlap, the, teh app get the onAabbOverlap

then the solver find that the bodes are are rest, and next time the check find that less that 1/3 are active (zero in teh case) so is does the tow pass scans.

the two pass scan is one from left to right when is check each active body versus the scene, but as you can see, is start with an active body.

you can check this by hacking uncomment line 1505 in same file, and you will see that you will get teh callback each time.

the 2/3 is because of profile testing in scene with few hundred bodies. it seem that threshold should be 1/2 but liek every thong on computers, my empirical test shows that on large scenes most of the time more than 2/3 of the bodies are at rest. so doing this only when a smaller that 1/3 of the bodes are active result on the partial scans been more than 90% of the way of operation.

yes I know that if we did this huge performance collapsing demos or pyramid of gazillions bodies that is will do full scan, but I am no longer interested on those kind of test.

so to summarize you are right, ideally OnAabbOverlap sould be call, but for newton 4.00 that's a limitation we have to live with untill we can find a better way.

notice that thsi does no change the behavior, is you result true the first time time, the behavior will be as expected.
plus the application can do a test like.
return dOverlapTest(rootNode->m_minBox, rootNode->m_maxBox, boxP0, boxP1) ? 1 : 0

so i tis not like is a show stopper bejavior.