Determinism problems and bodies that go to sleep too soon

[Sweenie]

Hi.

It's been a while since I resynced to svn and now I see some behaviours i didn't see before syncing.

First time I run my scene containing a stack of boxes tipping over, they fall a certain way.
If i now reset the scene(by destroying all bodies but not destroying the world) they fall another way and if i keep resetting the scene they fall the same way over and over again(like they should since I always assumed Newton is deterministic).
So the question is why they fall a different way the first time the scene is set up? It never behaved like that before.
Tried the box stack demo in the sandbox by setting scene 8 as default but it always behaves the same. Do you create the NewtonWorld once when the sandbox application is starting or do you create a new world for each demo?

The second behaviour that is odd is that my bodies seem to go to sleep too soon. Some boxes never falls flat to the ground but instead tilt a little bit on their side.
I was suspecting the autosleep function first but after turning autosleep off and they still behaved that way I tested the box stack demo in the sandbox.
If I display the contact points in the sandbox I noticed that some weird contact points are created. Run the box stack demo and drag one of the tall wood boxes so that it's standing tall.
Now gently tilt the box back and forth without tipping it over and notice the contact points and the bottom of the box. Should it behave like that?

[Julio Jerez]

The sand body make a new work, for each time a demo is run.
I may have some pointer that is casing that behavior, The sand box will not replicate that, but maybe a
you can recreate a small test of the falling stack using this test.
C:\Development\newton-dynamics\applications\tutorialsSDK300\NewtonTutorials

the second problem, not that should not happen, there has being lot of work done with the contact caching,
my guess is that some contact are reported as cached, and since the are in global space,
the old code did a expensive test to validate contacts, it was testing all contats, the new one only use the matrix the objects and velocities.
My guess is that a small change does not imply contacts same contact.

did you make your one demo for the sandbox, or did you test this with an existing demo. if so which witch one?
can you make a you tube video, so that I can see how you test this?

[Sweenie]

Here is a video showing the sleeping(or contact point?) bug.

[Julio Jerez]

Oh I see, let us do this test, to see if it goes away

on this file:
../newton-dynamics\coreLibrary_300\source\physics\dgNarrowPhaseCollision.cpp

find this function:

Code: Select all

dgInt32 dgWorld::ValidateContactCache (dgContact* const contact, dgFloat32 timestep) const
{
   dgAssert (contact && (contact->GetId() == dgConstraint::m_contactConstraint));
..


and change to this

Code: Select all

dgInt32 dgWorld::ValidateContactCache (dgContact* const contact, dgFloat32 timestep) const
{
return 0;
   dgAssert (contact && (contact->GetId() == dgConstraint::m_contactConstraint));
..


this will invalidate the contact cache every time, I suspect that error is there.

[Sweenie]

No sorry, didn't help.

[Sweenie]

Regarding the determinism problem...
I modified the tutorial code to create a stack of 5 boxes, ran the simulation for 600 steps and recorded the position of the top box.
Then I delete the stack of boxes and create them again the same way and ran 600 steps again recording the same box.
This is what I get... using this code http://www.svenberra.net/main.cpp


Now if I instead call NewtonUpdate once right after creating the ground collider but before adding the stack of boxes, I get this result.

Code: Select all

   // create a static body to serve as the floor.
   NewtonBody* background = CreateBackgroundBody (world);

   NewtonUpdate (world, 1.0f/60.f);


So I need to run NewtonUpdate once with at least one body in the world before running the two simulation runs to get the same result both runs.
I guess the first call to NewtonUpdate initialize something that affects the results.

[Sweenie]

Found something that made a big difference to the "autosleep" bug.
In the file /trunk/coreLibrary_300/source/physics/dgCollisionConvexPolygon.cpp
at revision 1168 you made this change.

Code: Select all

                //penetration = dgMin (penetration, DG_IMPULSIVE_CONTACT_PENETRATION);
                penetration = dgMax (penetration, DG_IMPULSIVE_CONTACT_PENETRATION);


If i change it back to dgMin it behaves much better again.
It still autosleep too easily if balancing the box on the edge but now the box vobbles as it should. With dgMax it's like the body is in water(or have a large angular damping)

[Julio Jerez]

Ok now I am debugging this, I could not would yesterday,
fisrt I hack the box stack demo, to make it happen more easily, and it is very bad, her is a capture

badImage.png (777.17 KiB) Viewed 9159 times

the bar is tilted on a non equilibrium state and that is wrong

the line you think maybe the bug, can not be. because penetration is a positive value,
changing the penetration to the min between DG_MIN_PENETRATION and the actual shape penetration result on bodies never recovering from interpenetration.
That may contribute to that but it is certainly not the bug, I will step line by line to see what is wrong.

That one of eth fiel that has change a lot, basically the collision with plane was change all together from doing contact calculation on global space to:
- transforming the polygon to the local space of eth shape
-calculate contacts
-transform back the contact

this is a significant change for accuracy because calculation of the space of one shape work for convex shapes but only yield good accuracy when the contact are generated around the center of the collision trees,
when face are far away form the origin of the tress, then the contact has lots of inaccuracy. this has a small cost, but it is worth.

some where I made a mistake, and I have to find out.
This explain why in the fork lift demo after a drive for a while the when appear to sync to the floor, and I though is was a bug in the chamfered cylinder, but instead is a bug in convex polygon.

that was a good catch
thank you, for the debugging,
let see what is wrong.

let us fix the penetration bug first,
I suspect that parabolic different is dues to the same problem, we see after I fix this bug first.

[Julio Jerez]

ok I found the going to sleep when not in equilibrium bug and I fixed.
The but was no on the contact function, it was here
../newton-dynamics\coreLibrary_300\source\physics\dgWorldDynamicsSimpleSolver.cpp

Code: Select all

void dgWorldDynamicUpdate::CalculateReactionsForces(const dgIsland* const island, dgInt32 threadIndex, dgFloat32 timestep, dgFloat32 maxAccNorm) const
{
   if (island->m_jointCount == 0) {
      ApplyExternalForcesAndAcceleration (island, threadIndex, timestep, 0.0f);

//   } else if (island->m_jointCount == 1) {
//      CalculateSimpleBodyReactionsForces (island, rowStart, threadIndex, timestep, maxAccNorm);
//      ApplyExternalForcesAndAcceleration (island, rowStart, threadIndex, timestep, maxAccNorm * dgFloat32 (0.001f));
   } else {
      dgWorld* const world = (dgWorld*) this;
      if (world->m_solverMode && !island->m_hasExactSolverJoints) {
         CalculateForcesGameMode (island, threadIndex, timestep, maxAccNorm);
      } else {
         dgAssert (timestep > dgFloat32 (0.0f));
         // remember to make the change for the impulsive solver for CC
         CalculateForcesSimulationMode (island, threadIndex, timestep, maxAccNorm);
      }
   }
}

if you look at the code, at some point I commnetd out the solver for small set of joints. That solev was a special case of the exact solver,
which is a line search algorithm for find the forces.
In theory that solver for one join sodu find the solution is one step (constant time), in pratice
I found that because the contact usually do not no sow a condition know as eigenvectors clustering, the function was taking a number of passes equal to the number of different unique eige vectors of the system matrix.

what the mean is the following, say you collide with a flat polygon or with a convex shape.
the collision system find foru contacts. each contact has two friction rows so the total number of row in the system matrix is 12

the contact normal will point on the same direction, so three, an singular value decomposition of the system matrix will find those four row to have the same eigen vectors,
the friction rows if the body does no have angular velocity, 4 friction contact will have the same direction, and the other 4 for also the same direction perpendicular to the first friction and the normal.

so the SBD will find only three different Eigen vectors. this mean that the exact solver will find the solution in three iterations, in practice it will do the equivalent of four because the initial set up step count as one pass.
the Is the absolute best that can be done.

In practice bodies do have angular velocity all the time, which means that each friction row will have his own unique direction, plus most objects collide with different polygons of meshed (differenct normal directions),
in general a collision between a box and a collision trees will have 12 or more rows, all with different Eigen vectors. which means at most 12 iterations but guarantee more than 4
That makes the exact solver also slower than the iterative one even when the iterative one takes many mare cheaper iterations.
I decided to comment out that special solver. an see how that worked for core 300.

The was all good, however my mistake was that I forget the exact solver uses very small tolerances, since in theory it should calculate exact values.
it turned out that the iterative solver with good initial guess is also very good specially with small number of joints,
so by using small tolerances with the iterative solver when the number of joint is 2 or less, that should make it almost identical to the exact solver.

please sync and try again let us see if the problem is fixed.

also please try the bounce bug again after you sync, I know do not think these are the same bug.
this

So I need to run NewtonUpdate once with at least one body in the world before running the two simulation runs to get the same result both runs.
I guess the first call to NewtonUpdate initialize something that affects the results.

should not be necessary, but it is a good observation,

verify again with the ne code please,
I will also check what is up with that.

[Sweenie]

Hmm, unfortunately it didn't make any difference.
The bar still freezes while tilted and the bodies still bounce differently the first time. I double checked that svn synced correctly and it did.

[Julio Jerez]

are sure? I test again and is not happening here.

I checked BoasicStack.cpp demo with only on box, please see if you make it happened.

[Julio Jerez]

never mind I see it, it still happens, there must be some other place that I need to add the check

[Sweenie]

Yep, still happens... I can balance it perfectly still on it's edge even though autosleep is off.

[Julio Jerez]

Ok try again please, see how that works.

That's no a final solution is jsu to see if it make it better, I need to actaullt fix that in teh contact between a face and a plogon rutine.
basically the funtion asumes all intetastion will inteset the plane, whoever that no alway the case, ther cosul be lien and point contats.

I am fixing that now.

[Julio Jerez]

Ok Sweenie I think I found the secung bug and fixed.

Yes you were correct call a newton update changes the scene,

the reason is that the broaphase does an increment update of the the special data structure that keep the location of bodies.

when you call the update the scene organize the broadphase, and since the next bolides were very close, the second update di no organized the scene again.
that arrangement produce and array of contacts in certainty order.

when you clean the scene and you add the bodies again now the contact are generate on a different order. and that make the solve produce different result.
to fix that I has to re enable the function NewtonInvalidateCache ,
what this does is that is clean up all of the cache contact, sort the body list by ID, and body types, and sor the joint joint list. and also clear the history

you use like this:

Code: Select all

   NewtonBody* const background = CreateBackgroundBody (world);

   NewtonBody* obj1 = CreateBody(world, 0, 25);
   NewtonBody* obj2 = CreateBody(world, 0, 24);
   NewtonBody* obj3 = CreateBody(world, 0, 23);
   NewtonBody* obj4 = CreateBody(world, 0, 22);
   NewtonBody* obj5 = CreateBody(world, 0.6, 21);

   NewtonInvalidateCache (world);

basically you call it when you modify the work by adding or removing bodies.

do no call it on before every Newton Update, because first the function is expensive, and even worse
cleaning the contact history, and the broadphase history make the contact phase of the engine quadratically expensive.

please sync and try again, see if this solve that secund bug.