Joints stiffness

[JoeJ]

no hurry just noticed that the joints are a little more "elastic" in 2.13.

Can you describe your test case?

I did the update so i can compare the joints behaviour later after the stiffness change.
I do that using 'Download Zip' button on github - sadly there is no proof that this is really the latest.
The former Version i was using is nearly a year old - 3.xx.

To me the joints look stronger:

I can smash the ragdoll around and bodies do not seperate much.

I use some helper joints for powering (e. g. min distance from hip to foot).
Now i can disable those joints, but ragdoll is still able to balance on moving platforms.
I dont think this was possible a year ago.

EDIT:
Going back to the 1-year old and repating the tests again:
I was wrong and there is no difference large enough i can be sure about - sorry.

[arkeon]

About the "sticky" behavior, if newton can simulate this, maybe a default material param for sticky factor could be implemented ?

for example when you define a "scratch" or "glue" material just like you set the friction or elasticity coef and other stuff ?

[arkeon]

@JoeJ no the problem was just because of the solver iteration count change.

[Julio Jerez]

Guys so that you know, I finally have the solver modification that solve bilateral exactly.

wow, when I derived the math on paper the formulation looked simpler than I though I was going be. I implemented it twice. on the third try I decided to go for a less optimized, but that is almost like the same symbolic derivation so that I can have it working first.

The first commit is not going to be as efficient it is just to have as a point of reference for the optimize one. The thing is that without a reference to use as baseline it is difficult to know if matrix operations has a bug or not.
maybe a couple of more day. But I believe the is going to kick ass for articulate bodies.

for example inverse dynamics by extracting key frame for animations become trivial.
I would be quick simple to pug and PID of a fast respond control to the joints for controlling the joint torques, so that a character an animation system while doing space time constraint at the same time. This something the is hard to do with soft joints, but with hard joint is quite simple.

[AntonSynytsia]

Thank you, Juleo.

[JoeJ]

Can't wait to do some tests for practical use case

The video shows the ragdoll balancing itself, but it also can play back animation.
The best test will be to stand still at static ground, bend upper body and measure the offset from COM to its target position (white dot at pelvis + offset line in video).



The powering is done by

NewtonUserJointAddAngularRow (joint, 0.0f, &axis[0]);
NewtonUserJointSetRowAcceleration (joint, relAccel);
NewtonUserJointSetRowMinimumFriction (joint, -angularFriction);
NewtonUserJointSetRowMaximumFriction (joint, angularFriction);
NewtonUserJointSetRowStiffness (joint, stiffness);

The rest is usual point to point constraint like in your ball socket.
Let me know if there is something change.

[Julio Jerez]

I finally got last bug fixed, I still nee to add some more functionality and a few demos.

Lie I said you get the system going I use the old exact solver, but after the functionality is all in and I am sure it working the will optimized. rag doll demo the new system and it is about 50 % slower,
I am guess the final will be 50% faster, in fact I we can have tow systems, one the handle internal loop and one the handle acyclic skeletons.

I run a couple of test but making a change of ball and pulling the last balling the mouse.
with o the option all the joint dismember with eth new option zero disjontement even if it goes into a tail spins, in pass these tail spins led to explosion, but so fat in all the test no explosion, so I am veg happing.

you test My guess should be a walk in the park, because if it can handle polling with the mouse, the is can handle any natural force. The mouse force picker generate incredible forces that can brake almost anything, but it s no bearing this.
If I am correct I think the is going to be the most advance feature on the engine. No more soft joint regardless of mass ratios.

[arkeon]

Awesome
I'll check that new feature asap.

[Julio Jerez]

al right I just check in the fist implementation.

It it slower than I was expecting to, but that is no problem because lie I sad I use the old exact solve to get the prove of concept.
The final version will be around 15 to 30 time faster believe or no.
The reason this is slower is because it takes too 32 passes passed, by the final version will onel take one pass the is twice as long. so the speed factor is about 15 to 30.

anyway I did no make any demo, I simple added to class CustomArticulaledTransformManager this was I automatcally get one vehicle and the rag doll demo for free.

this is independent of the joint library, basically after you unmake you rig of bodies and joints. all you nee to do is:

NewtonSkeletonContainer* skeleton = NewtonSkeletonContainerCreate (NewtonWorld* const world, NewtonBody* const rootBone);
and add al the children using function

void NewtonSkeletonContainerAttachBone (NewtonSkeletonContainer* const skeleton, NewtonBody* const childBone, NewtonBody* const parentBone);

and after all the bone are added, the call
void NewtonSkeletonContainerFinalize (NewtonSkeletonContainer* const skeleton);

and that's it, now that array of bodies and joint will be result exactly.
I see if I make a simple and a more complex demo. demo

for now, I will seat of the unit is is tested and I get feedback, before I do the linear version, and I will do the sticky contact and Collsion aggregates.

collision aggregate is another feature I was thong for 3.14.
basically this is like compound collision but for bodies. Compound collision is very good by is has a problem, imagine a rag doll with 21 or 25 body parts, the body part can no be compound collision without doing too much work. This present a problem.

Say was want 100 rag doll in the scene. at 25 body part a piece, that 2500 bodied in the broad phase.
however the entire rag doll is a very tight array of bodies. if we make a co[pound collision that take bodies as Childers, just lie the broad phase, that the broad phase will be delay wish 100 nodes, and for each node the self collision of 25 nodes.
this is much fasters that a broad face that has do \to \deal with 2500 nodes.
The will be very useful for vehicles, rag doll and in generate any kind of articulated se to bodies.

so after I do the sticky contacts, I will do that aggregate next, then I will write the optimal bilateral solver.

[JoeJ]

Tried it but it makes no difference for the powered ragdoll. Test is standing ragdoll spreading arms like T-pose. Because of missing stiffness each joint misses a fraction of the target angle and the hands end up lower than they should be. This effect is the same if i use the skeleton container or not.

Is there internal difference between a powered joint and a hard limit joint, and should the new method improve both of them?

Maybe there is something else necessary like CustomArticulatedTransformController, like you use in your ragdoll demo?

I am not sure new method is really running (throwing around unpowered ragdoll seems a lot more stiff but there are still temporary gaps, so i'm not sure).

One other idea i have to reduce the gap problem is:
Instead of using parent body orientation to do the point to point constraint, use gramm schmidt along the gap error if error is large. This improves kinematic joint, so it should work for eyery other too.
I'll try this first...

---

There are some interesting differences between exact / iterative solver:
Using exact solver the balancing ragdoll moves very smooth. Iterative has some micro-jitter / flickering motion (small enough it can be filtered for graphics).

But a big downside is that exact solver adds much more energy.
You can see this in your ragdoll demo if you disable cone limits making it a pure ball socket (i did by commenting the limits code in joint lib).
Then when you pick a ragdoll, lift it up and keep it hanging in air, the end bones (hands, feet, head) begin to spin and jitter - entire ragdoll never comes to rest.
(It seems the new method makes this effect worse in my demo)
Things like that would justify a hacky fix if possible (something like damping per skeleton - conserving whole skeleton energy, but reduce relative vleocity between bones?)

For this reason i never was very interested in exact solver, but now - because of the smooth motion - now i am

[Julio Jerez]

There are some interesting differences between exact / iterative solver:
Using exact solver the balancing ragdoll moves very smooth. Iterative has some micro-jitter / flickering motion (small enough it can be filtered for graphics).
But a big downside is that exact solver adds much more energy.

yes that is want of the differences, ne new solver will calcite huge forces to keep the joint together.
In theory these huge force should add zero energy since the constraint forces should be workless, in practice the is no the case because I use the iterative solve to get the thong going.

what happen is that with this huge forces if tow body part for some reason move away by some small values, then reaction forces are no longer workless and that's where the energy comes from.
is a huge force acting on a small distance, for the energy to be zero the body part can not separate not even by a small amount. this why late I need to implement the exact solver.

It is counteractive the huge forces should no generate energy, by is quite easy to see, huge force time small distance is some non zero work. therefore the distance most be zero.
It may even have to add a second pass to cancelling the separation because may be even the exact force solver may not prevent two body part for separating a small amount.

But lie I said this is just to get the ball rolling, with this I can now use it to implement the part two an use this as reference for correctness. once these is in the motion should be vey smooth and almost perfect.

do your balancing dolls act better or worse?

[Julio Jerez]

Tried it but it makes no difference for the powered ragdoll. Test is standing ragdoll spreading arms like T-pose. Because of missing stiffness each joint misses a fraction of the target angle and the hands end up lower than they should be. This effect is the same if i use the skeleton container or not.

on this yes that is expected, this is because the solver has some limits for now.
I do no want to explain now because later I will fix that, but the is part of the second face of the solver. The second install should solve that issue too

to check is the new method is running you can set a break point here

Code: Select all

dgFloat32 dgSkeletonContainer::CalculateJointForce(dgJointInfo* const jointInfoArray, const dgBodyInfo* const bodyArray, dgJacobian* const internalForces, dgJacobianMatrixElement* const matrixRow) const

[JoeJ]

Cool! In the meantime i've wrote this:

Things like that would justify a hacky fix if possible (something like damping per skeleton - conserving whole skeleton energy, but reduce relative vleocity between bones?)

Because i already have this i tested it again.
It works this way:
1. For all bodies of the ragdoll calculate a virtual compound body and its linear / angular velocity.
2. In FT callback add forces / torques to match this "unified" velocity.
If done correctly (hard, but pretty sure i did), this does not add / remove energy to the system.

Using iterative solver i need 1 % of those "damping forces" to get the hanging ragdoll to rest.
Exact solver needs 10%
Exact + stiff skeleton also 10 %

Maybe the same can be done better by simply adding a little friction to each joint,
but my idea was to use this to assist powering, now it's still an interisting way to measure simulation error.

[JoeJ]

to check is the new method is running you can set a break point here

Ok, it's NOT running - that's good news

I added breakpoints in Setup and Finalize code, those are hit.

So there must be something more necessary than this:

Code: Select all

void EnableStiffJoints (NewtonWorld *world)
   {
#ifdef NEWTON_STIFF_JOINTS
      newtonSkeletonContainer = NewtonSkeletonContainerCreate (world, bodies[HIP]);
      //and add al the children using function

      for (int i=0; i<joints.size(); i++)
      {
         NewtonSkeletonContainerAttachBone (newtonSkeletonContainer, joints[i]->body0, joints[i]->body1);
         //NewtonSkeletonContainerAttachBone (skeleton, joints[i]->body1, joints[i]->body0); // would crash
      }

      //and after all the bone are added, the call
      NewtonSkeletonContainerFinalize (newtonSkeletonContainer);
#endif
      //and that's it, now that array of bodies and joint will be result exactly.
   }


[JoeJ]

Ah - it is in iterative solver - i thought it's exact only forn now.

Running now & testing...