Joints stiffness

[JoeJ]

I should have no cycles, but maybe some helper joints are still being created but not in use and that causes problems. Need to go to work now - will look later...

[Julio Jerez]

Ok, when you get to it again, when I do is they I add the parts one at a time,

One rule that si important now si that parent child relationship, I have to add utility functions do assist the client when cratering the joint.

Oh another point is that there can no be static bodies. if you root is static, the just link to the work with a fix joint that is not in the skeleton, later I will add the feature the it can tale a static root. but for now it inly handle dynamics bodies with no zero mass.

I know is sound like a lo of restrictions, but once you get use to it you will see that is quiet powerful

[Julio Jerez]

ok I think I know why you got and explosion
the create interface is not smart to figure out the parent child relation,
since joint are by definition undirected, I will fix that and also I will add another inferface for
make contrition simples

Code: Select all

NewtonSkeletonContainer* NewtonSkeletonContainerCreateFromJointArray (NewtonWorld* const world, NewtonBody* const rootBone, int jointCount, NewtonJoint** const jointarray);


this will sue a depth first search to build the hiercahsi and will figure out the breaks but the depth first search rule. for any acyclic skeleton it will be perfect, for skeletons with cycles the breaks will be at the deepest branch of the forest,
in the end you were right branches may confuses the contrition, but will be fixed.

[JoeJ]

Ok, i'll try that when it's done.
I'm almost sure my child / parent ordering is correct - i have visalization for that and checked double times.

Ah - now i've got it:
It works now when simply reversing order for each joint
(Interesting: With the old version this made newton crash during setup - maybe oll my previous results are based on wrong setup)

Ragdoll can now balance again, micro-jitter is gone and it looks very good,
but it seems the additional stiffness from the old version is lost:
Arms fail to keep the T-Pose like they did in the last youtube i've posted.

It seems additional stiffness is lost for the powered joints,
but the unpowered ball socket looks great.


There is one huge improvement:

Picking powering T-pose ragdoll on arm body and holding up to air it comes to rest now.
I did not succeed on my own physics engine, but i know how hard it is to achieve this.
Awesome work, Julio!

[Julio Jerez]

Ah - now i've got it:
It works now when simply reversing order for each joint
(Interesting: With the old version this made newton crash during setup - maybe oll my previous results are based on wrong setup)

that is what I was saying before, her system is kind of irreducible complex, you need the the component before you can see any results. that was why I use the old solve to get the system implemented. since the old solver work on an undirected graph, the order of joint was no important.
This solver only works on directed graphs, so the order of joint will make blow up.

Since a direct graphs is basically a tree, a graph were each child can only have one parent then it is possible to sort the graph to get the correct order. I am adding that functionalist to the Finalize functions. also there are still a couple of bugs. that need to be resolves but all in all is common alone.
for motors and limits they are soft still because they are still using the iterative solve, but they will also be solved in next update. The coolest part is the system works seamlessly with every things.

[Julio Jerez]

Ok Joe, when you have a chance try again please
I added these function
void NewtonSkeletonContainerAttachJointArray (NewtonSkeletonContainer* const skeleton, int jointCount, NewtonJoint** const jointArray);

It will figure out the correct root, even when no passing the correct skeleton node.

this is cool because it allow for camping tow different skeleton and simple connote any two node, and it will figure out the new root.
Game do that king of stuff special fighing game when the need to make a plane play is animation as the child of some node of another character, anther example is, imagine a vehicle and a player border by simple connection the play sketon some atachement not in the vehicle, and running finalize then the tow thong paly as one.

anyway I also fix a bug that I think was making the arms of you play feel soft.

I think I will have to add some sanity check caps, because It blow up a few times,
I think this is because the methods I am using for matrix inversion is simple gauss Jordan, when is
and the matrices are losing the DPS property because of the condition numbers.

I will debug that ove the weekend, and also add more functionality.

[JoeJ]

anyway I also fix a bug that I think was making the arms of you play feel soft.

I've tried for a long time to tune parameters and maybe you have made a bug there.
If i trun powering off, all is fine. (i'm using NewtonSkeletonContainerAttachJointArray now).
But with powering (no controller - just try to keep static T-pose), it behaves weired and explodes after approx. 20 timesteps.
Excluding nonimportant joints, tweaking stiffness or mass ratios... nothing helps.

Looking those 20 steps one after another (i can do timestep per button click and watch result), it seems powering is just wrong. It does not look like a growing oszillation while trying to converge, it looks like every motion of the ragdoll goes always in a wrong direction.
Maybe a simple math bug?

[Julio Jerez]

you are right there is a big bug some where still.
But I do not think it the math, it is float rounding in error.

I had buts like the a long time ago, where the math was all right, yet the calculations was incorrect.
basically what is happing it explained but this. https://en.wikipedia.org/wiki/Condition_number
it can be explained as follow, say you have a linear system expressed by equation

A * x = b

where A is a square matrix, the way you solve the problem Is by inverting the matrix

x = invert (A) * b

this implies the that

den (A) * det (inv(A)) = 1

where A is Identity matrix, however when A is very big the way a matrix is inverted is by doing what is called pivoting (linear combination of rows)
the problem is that if matrix has large float and small floats, the process of pivoting loses some bit of precision, so the bigger the matrix the more bit are lost.
where you end up is with and iverted matrix where the expression

sqrt (det(A) * det (inv(B))) >> 1;

the expression above is knows as condition number and the provide way to know if one the system is stable can can be solved, with f32 bit float the value can be as high as sqrt (1000000) = 1000 or so.
that about 5 to 6 digit which in the larger value the can be code in the mantiza of a float.

I am guessing I am getting condition numbers that can only be encoded with 14 or 15 digits
I have to write some code to verify that this is the case.

I see what is wit with the Motors. I will prbabl have to make test case to test motors.

[Julio Jerez]

Hey Joe, one want you can tell the cod is working is by looking at how the Rag dolls land on the terrain. They all land with style, not like the robbery feel you see on rag doll on other engines.

This si possible because the bone limits are more or less anatomically correct, so if the solve can handle then then all poses will be anatomical plausible.

[Julio Jerez]

Ok I move all the standard joint demo to use the new Skeleton Joint solver, It is unbelievable

I placed a define a the beginning of the demo #define _USE_HARD_JOINTS
by commenting that out and pick and dragging the parts with the mouse, you can see the difference.

With the define the bodypart dismember under force of the mouse, with the define the bodyparts state together, and it is the base that that dismember, but the is because the new solver does not handle infinite mass bodies. I connected the root to the world with a normal fixed joint.

This is going to be improve a lot with next commit, because I remove and feature the let joint use the exact solver, but sine the new skeleton solve doe no support infinite mass, I can bring that on back, in fact I can no make the default, since those e joint will be minimal.

After adding that part the everything thing will be strong: motors, limit and bilaterals.
I am very satisfied with the how this I turning out, and I already have a new feature that follows as an extension of the new one. This will blow everyone away.

Please let me know if you see any improvement?

[JoeJ]

Can't believe this - it works! F***!
That's the holy grail of physics simulation Awesome!

I modified jour joint demo to build a chain of 4 bodies from powerd ragdoll - stiff as a rock

But it still does not work for my stuff - i must have a bug - need to find it...

Code: Select all

static void AddPoweredRagDoll (DemoEntityManager* const scene, const dVector& origin)
{
   dVector size (1.0f, 1.0f, 1.0f);
   NewtonBody* const box0 = CreateCapule (scene, origin + dVector (0.0f,  9.0f, 0.0f, 0.0f), size);
   NewtonBody* const box1 = CreateCapule (scene, origin + dVector (0.0f,  9.0 - size.m_y * 2.0f, 0.0f, 0.0f), size);
   NewtonBody* const box2 = CreateCapule (scene, origin + dVector (0.0f,  9.0 - size.m_y * 4.0f, 0.0f, 0.0f), size);
   NewtonBody* const box3 = CreateCapule (scene, origin + dVector (0.0f,  9.0 - size.m_y * 6.0f, 0.0f, 0.0f), size);

   dMatrix pinMatrix (dGrammSchmidt (dVector (0.0f, -1.0f, 0.0f, 0.0f)));

   // connect first box to the world
   dMatrix matrix0;
   NewtonBodyGetMatrix (box0, & matrix0[0][0]);
   pinMatrix.m_posit = matrix0.m_posit + dVector (0.0f, size.m_y, 0.0f, 0.0f);
   CustomControlledBallAndSocket* const joint0 = new CustomControlledBallAndSocket (pinMatrix, box0, NULL);
   joint0->SetAngularVelocity (1000.0f * 3.141592f / 180.0f);
   joint0->SetPitchAngle (-45.0f * 3.141592f / 180.0f);
   joint0->SetYawAngle (-85.0f * 3.141592f / 180.0f);
   joint0->SetRollAngle (120.0f * 3.141592f / 180.0f);

   // link the two boxes
   dMatrix matrix1;
   NewtonBodyGetMatrix (box1, &matrix1[0][0]);
   pinMatrix.m_posit = (matrix0.m_posit + matrix1.m_posit).Scale (0.5f);
   CustomControlledBallAndSocket* const joint1 = new CustomControlledBallAndSocket (pinMatrix, box0, box1);
   joint1->SetAngularVelocity (1000.0f * 3.141592f / 180.0f);
   joint1->SetPitchAngle (45.0f * 3.141592f / 180.0f);
   joint1->SetYawAngle ( 30.0f * 3.141592f / 180.0f);
   joint1->SetRollAngle (25.0f * 3.141592f / 180.0f);

   // link next box
   dMatrix matrix2;
   NewtonBodyGetMatrix (box2, &matrix2[0][0]);
   pinMatrix.m_posit = (matrix1.m_posit + matrix2.m_posit).Scale (0.5f);
   CustomControlledBallAndSocket* const joint2 = new CustomControlledBallAndSocket (pinMatrix, box1, box2);
   joint2->SetAngularVelocity (1000.0f * 3.141592f / 180.0f);
   joint2->SetPitchAngle (45.0f * 3.141592f / 180.0f);
   joint2->SetYawAngle ( 30.0f * 3.141592f / 180.0f);
   joint2->SetRollAngle (25.0f * 3.141592f / 180.0f);

   // link next box
   dMatrix matrix3;
   NewtonBodyGetMatrix (box3, &matrix3[0][0]);
   pinMatrix.m_posit = (matrix2.m_posit + matrix3.m_posit).Scale (0.5f);
   CustomControlledBallAndSocket* const joint3 = new CustomControlledBallAndSocket (pinMatrix, box2, box3);
   joint3->SetAngularVelocity (1000.0f * 3.141592f / 180.0f);
   joint3->SetPitchAngle (45.0f * 3.141592f / 180.0f);
   joint3->SetYawAngle ( 30.0f * 3.141592f / 180.0f);
   joint3->SetRollAngle (25.0f * 3.141592f / 180.0f);

#ifdef _USE_HARD_JOINTS
   NewtonSkeletonContainer* const skeleton = NewtonSkeletonContainerCreate(scene->GetNewton(), box0, NULL);
   NewtonSkeletonContainerAttachBone(skeleton, box1, box0);
   NewtonSkeletonContainerAttachBone(skeleton, box2, box1);
   NewtonSkeletonContainerAttachBone(skeleton, box3, box2);
   NewtonSkeletonContainerFinalize(skeleton);
#endif
}


[Julio Jerez]

Isn't that cool? I do not even believe myself. I probably should paper about it,
when writing the Math, in my mind I am thing these should work, these how work, and after tow week implementation and looking for bug and numerical instability, I was starting to have second thoughts. On that process I made the implementation cleaner and in writing cleaner I found what than problem was. Basically is the same we have in nature.
Nature doe not solve rigid bodies, because rigid body is a very stringer abstractions.
if you connect a Chand of rigid dodoes in real life a perturbation of one link is no felt on the other extreme instantaneously, this is because elastic and they deform, This deform take time, so what you get is a wave propagating across the links.
however if the link were undeform able rigid bodies, the effect is felt instantaneously, so for the solve need to generate incredible large values that interact with incredible small values.
and the is the problems, so basically there is a limit as to how many bodies can be simulated. It is almost the engine is telling you that you can not cheat nature.

In the next few day I will see if I can incorporate stiffness as part of the algorithm, I try but I think I made a mistake, By I suspect that the incorporation of stiffness will produce a more reality elastic material behavior. There is a lot or potential in the


any way If you do not find the problems.
later I will extern the serialization to support the skeleton, that way you can serialize your set up and send to me for testing.

also, I will paste your script in the demos.

[Julio Jerez]

Oh I see you added more links, Niceeee

BTW Joe, remember when we talked about the rag doll joint that use small angular approximations.
That is that joint there.
I implement a while back but was no reliable because the solve was too soft, but now it does works.

Basically the joint allows to control three independent angles, the trade off is that it can only move at a max angular speed. the fastest the speed the more the inaccurate the trajectory.
But that is an acceptable trade off I think, because you can always increase the simulation rate,
so as long as the solve is strong enough then the joint is no an option. the same apply the Universal Joint, the joint was always wobbling because tow angular motions combine with and none uniform inertia matrix generate very strong Gyroscopic forces that an iterative solver can't cope with.

And Joe the bets is still to come. so seat tight my friend we are going to have this fix before supper.

[JoeJ]

I've replaced my ragdoll joint with yours, and got it working so far. Balancing on moving platforms works, but only slowly because this joint acts different than what my controller expects. Still looking for my bug...
However - looks really really good. I can confirm it works for the complexity of the human body

I implement a while back but was no reliable because of the solve was to soft, but now is does works.

Basically the joint allows to control three independent angles, the trade of is that the can only move at a max angular speed. the fasters the speed the more the inaccuracy.

Yes, thats the joint i'm using now. I'll see if i can get my own version (single axis angle) to work with the new skeleton. I have still doupts against the 3 angles because the arc of rotation and the speed are somehow unpredictable.

[JoeJ]

I got it stable by replacing the angular powered row of my joint with a linear row.

Some notes on my joint:
The joint has a target relative rotation between the bones and it should reach this at the next timestep.
The axis of this rotation is fixed using linear rows like in a hinge joint.
Then the powering:
The angle of rotation is used to add a angluar acceleration row (works if skeleton is not in use),
or to make two pins and bring them together using a linear acceleration row (correct only for very small angles, but works with skeleton)
Note that the angular row works for hinges + skeleton, probably because rotation axis is fixed,
but it does not anymore for free rotation joint.

Ragdoll is stable now so i can see that powering by setting acceleration shows improvement with skeleton.
It's not as stiff as using your joint (which does not set acceleration) but it shows better balancing behaviour and faster motion - yet no clear winner here.

I also see some strange things (let's ignore them for now):

Improved stiffness shows up only after i reset the ragdoll once (teleporting bodies to startpose and zeroing velocities).

Your solver magically detects what i want and helps me to cheet.
I have had situations where the ragdoll would surely fall in reality - but it keeps standing upright.



Confusing results.
But i think that the dreams of "stiff joints" and "powered free rotation joint" are tightly connected.
I'm not very happy that topic comes up now again - i thought that has been solved once and for all.

I'll add my joints to your demo. Should be a good testcase...