Joints stiffness

[Julio Jerez]

just test the rag doll and there is still a bug, but I have to go now.
I check it out tonight.

[Julio Jerez]

Ok I found that one, is should be good now. Seems vey, very good so far.

[JoeJ]

If i set max friction for all 3 axis in the joint, my ragdoll explodes.
But i can set it for the single axis that does the motor.
Then ragdoll is stable enough to see a difference from before:
The arms hold the t-pose exactly - not hanging down anymore,
and i can pull the ragdoll with mouse and it will bend

Bhaviour is unstable - dances in tiny steps but keeps balanced for a few seconds.
Turning controller off and just hold t-pose shows a similar effect (sudden jumpy movements from time to time when throwing on the floor)

Seems it almost works...
Most worried about doing it for all 3 axis.

Edit:
Missed the last post but i think i am using the most recent version - will download again to be sure...
Guess you need to make a test case with CustomControlledBallAndSocket to reproduce the issue.

[Julio Jerez]

yes I saw the explosion, that was the fix I check in, please try again there was a bug that was transposing the wrong jacobians.

CustomControlledBallAndSocket I have commented pout I will check that again,
Last time I tried I had lots of problems, but with all the internal bugs I put it on hold until the solve was more predictable. I will try again that joint must work as expected.

[JoeJ]

Downloaded again but nothing changed.
It's not an explosion where all bodies disappear but they tumble around like crazy and all joints disconnect at the first timestep. they keep tumbling but stay together at a radius roughly equal to the height of the ragdoll.

[Julio Jerez]

that is estrange, I just tested the rag doll in the sand box, jsu one, I rattled around and seems to work. It could be another bug,
do you how to add serialization to you joints?

you say that is happen when you add more than on friction value? that was the bug I just fixed

[Julio Jerez]

Oh I know what happened, I did not checked in the fix, I did it a separated branch that I use to tryingg different features. I will do it tonight.

[Julio Jerez]

Ho Joe I now see what you mean, I was going to commit the changes, when I decide to test the ball and socket with friction and you are right as soon as there are more that on friction limit is behave really bad, there is still a bug.
There most be another place where the permeated Jacobean is assigned to the worn location.
I create a test to reproduce it and I am debugging it.
By I do not have time now, so it will be tomorrow.

wow, when I start the in paper look as easier than I though, but as usual the dibble is always in the detail. Bu I believe it is a huge improvement.
the addition of the unilateral constraint make is slower, because the reconstruction of the mass matrix. But give the flexibility this is actually very good

the 100 rag doll demo was 16 ms, now is 25. I thing I can do some improvement but I guess that is just about what is possible.

[JoeJ]

I just tested the new commit.
Happy to say it works now!

I have fricton in all angular rows, and it is stable for T-pose and also balancing ragdoll.
I was not able to provoke a expolosion or a jumpy move.

The reason it works for me is one difference about the point to point section of the joint i have forgot about.
I do not use 3 simple linear rows like in the sandbox code i gave, instead i do powering for them too (to make them less stiff and simulate some soft skin).
I set acceleration like for the angular rows and set stiffness to 0.9.

Now i tried to add max friction for those rows to: It becomes very unstable.
And if making them unpowered like in demo, i get a explosion without recover.

That's great! Even if you could not improove it any further, it works for powered ragdolls.
Whooo!

[Julio Jerez]

OH It will be improved. I just need to add the correct LCP.
there are tow method Danzig and Lemke.
Danzig I know well, and I do not really like it. Lemke I experimented a while back, and is very similar to the simplex method (remarkably the person who invented the Simplex method was danzig, yet he did not use for linear complementary problems)
The Lemke method is much faster than Danzig, however is very sensitive to rounding errors, and require more than twice as much memory.
If it was not for the problem that the method can terminate wit a horrible solution for systems that you know has a solution, is why make me hesitant to implemented it.

I will go for Danzig (the Baraff method is good for now the when we have a stable version we can try Lemke) I will work the weekend on that.

he thong is the is no so bad, because the trick is that the end use should minimize the number of friction joint by using smart designs. The reason when the Tal demo work and is stable that I unconsuslltly applied that rule. but as soon as I add the motors I see the Bug, and we can no have that.
Jus wait until the new version is finish, I am my old reading the Danzig and Cottle book again, but boy that book is hard to read.

BTW, I love that joint that made, the can be used to make poor man flexible bridged and stuff like that.
after I am finish the solver I will use your joint to make a flexible bridge for vehicle to go over

[Julio Jerez]

I now have clean up the pivot based Danzig LCP, I still have to add some code, because but it works for almost all cases.
I though I was going go to be able to have finish the weekend, but I always underestimate the amount of work. so it will take few more day.
This solver is no use for anything is will only be use to validate the solution of the Skeleton solver

as a test I added code to compere to the Block base iteration by increasing the integration count really high, and I generated the exact same solution every time with the exception of round error.
this tell me that now I am one right track. this is in the dgPSDMatrix class

The good thing is that I do no believe the skeleton solve will be bad at all even when doing the full Pivoting steps.
I will take a break now.

[JoeJ]

but I always underestimate the amount of work

Nice to here others have the same issue - still no walknig ragdoll

Tested again, seems the problems has reversed.
Now the simple point to point is stable, but explodes with big external force.
And the version with acc and friction is unstable and explodes immideately.
Acc and not using friction still works.

I may become unavailable for 1-2 weeks.
Here's my point to point code, just for reference in case you can't reproduce...

Code: Select all

   static void AddFlexiblePointToPoint (const float invTimestep, const Body* const body0, const Body* const body1, const Joint* const joint,
      sQuat &cSpace, const sMat4 &matrix0, const sMat4 &matrix1,
      const float reduceError, const float linearFriction, const float stiffness)
   {
      sQuat q1; matrix1.Rotation()->ToQuat (q1);

      sVec3 pin0 = matrix0[3];
      sVec3 pin1 = matrix1[3];
      sVec3 diff = pin1 - pin0;
            
      sVec3 v0 = BodyGetPointVelocity (body0, pin0);
      sVec3 v1 = BodyGetPointVelocity (body1, pin1);
      sVec3 relAcc = (diff * reduceError * invTimestep - (v0 - v1)) * invTimestep;

      sMat3 basis;
      sVec3 mainAxis = diff;

      float sql = mainAxis.SqL();

      if (sql > FP_EPSILON2)
      {
         sVec3 align = q1.Unrotate (mainAxis / sqrt (sql));
         if (align.Dot(cSpace.XAxis()) < 0.0f) align *= -1.0f;
         sQuat q; q.FromVecToVec (cSpace.XAxis(), align);
         
         cSpace = q * cSpace;
         cSpace.Normalize();
      }

      basis.FromQuat (q1 * cSpace);// constraint space attached to parent bone


      for (int i=0; i<3; i++)
      {
         sVec3 &axis = basis[i];

         NewtonUserJointAddLinearRow (joint, (float*)&pin0, (float*)&pin1, (float*)&axis);
         NewtonUserJointSetRowAcceleration (joint, relAcc.Dot(axis));
#ifndef NEWTON_STIFF_JOINTS
         NewtonUserJointSetRowMinimumFriction (joint, -linearFriction);
         NewtonUserJointSetRowMaximumFriction (joint,  linearFriction);
#endif
         NewtonUserJointSetRowStiffness (joint, stiffness);

      }
   }



[Julio Jerez]

It jus need few more day to polish it now.
I have a local version now in which the block solve is replaces by the danzig solver

Hey Join I do no want to be too excited yet, but whil doing this I beliebe I found the way to make the solve twice as fast.
I just noticed that for mall joint say up 4 rows.

the inner look does and matrix 8 x 8 matrix multiply because if build the mass matrix each time it call the block solver, however the matrix is only 4 x 4
so If the ass matrix is saved
each iteration is one vector operation, while the does eight

for a 8 x 8 matrix is only 2 vectors operations
for a 12 x 16 is only 3 vectors operations
and for a 16 x 16 is only 4 vectors operations
...

while the correct loop is 8 for any case. so if we save the matrix then a switch case that solve each case upto the point where is no lobe efficient should cut the time by a lot.

I will experiment with the next week.


whiel the

[JoeJ]

Maybe there are some useful ideas:
https://hal.inria.fr/hal-01157835

[Julio Jerez]

well It took me the hold weekend and go back to read my Geoge B. Dantzig Linear Programming book.
but now believe I gave the full LCP working again.
I also implemented the Gauss Seidel solver to have as the controller.

after spending three the last tree weeks I was tented to just use the Gauss Seidel and then come back to it.
The I decide to implement my own Line Search Conjugate Gradient, but I could not let it goes.
So I decided not to do anything and go back to read the book.
Then last nigh I found out what I was doing wrong and the Danzig lcp Is 100% correct.

I turns out that for a 12 x 12 system (for contacts) and a error of 1e-6 Guass Seidel takes from 1000 to 6000 iterations (stating from a random start point) where Danzig only takes from 12 to less the 20 (worse I seeing). So for small systems Dantzig is mush better and always gives the exact solution.

The Conjugate Gradient should be even better because that one can take one 1 iteration an not more than the when the start point is very close to the solution, and is never worse that Dantzig the worse case.
But for now I can Just go back to implement the proper Skeleton solve using Danzig.
so maybe one more week.