Ragdoll best practice

[zak]

I have downloaded r1487.
Because my wrapper has a define to Newton2 o Newton3,
first of all i have compared Newton2 with Newton3 exact solver.

1) Newton3 exact solver is 50% faster than Newton2 one.

2) When ragdoll is on two legs, with Newton2 after two seconds physics time starts slowly and constantly to grow up to 2 times or more.
With Newton3 this not happens.

Hei julio, fantastic job!

Now i intend to experiment further, also with iterative and with hybrid solutions.

[Julio Jerez]

yes overall Newton 3.10 is about twice as fast as all previous versions.

as all of the self appointed experts who every year write papers to compare older version of Newton to later version for all other engine
because is the only way the can validate their preconceived confirmation bias Fallacies.

Joe I added a better heuristic for spawning chunks, it is much better but it still can generate chunk that could be stocked index the fracture compound.
this is because the new heuristic issue chunk that can them self be colliding wit the compound, and does not deal with recursion.

I could make recursive, but I do no think I will do that because that could degenerated of some pathological destruction.
Next I will add logic to prevent recursion,
and also next the logic for braking large compound pieces.
I also need to come of with a heuristic tor creation Crack patterns, no just small derbies.

[JoeJ]

When destroying the crate, at the end it happened that some cells was in compound, but one cell was not connected to the others - there was air in between.
(...If this isn't the problem you mean). But it's nice the interior stays intact while the outer shell gets destroyed faster.

Good news is my scaling problem disappeared (remember i was talking about bodies behaving like wrong inertia when scaled).
Seems you've fixed it the last 1-2 moths.

Also the penetration problem (feet sink into ground / get pushed up cycle) is 'fixed'.
It's still there, but the recover velocity is slow and all happens very smoothly (no more 'micro jitter'), so i expect no more problems with this

[Julio Jerez]

When destroying the crate, at the end it happened that some cells was in compound, but one cell was not connected to the others - there was air in between.
(...If this isn't the problem you mean). But it's nice the interior stays intact while the outer shell gets destroyed faster.

yes that's what IO was talking about. as piece are detached for the graph, it Is possible that some island do not get format with no connection to the root.

this is the same problem that garbage collected memory manage has, the solution is to walk the graph from the root in a death first search coloring with a value.
then is a second pass anything the was not painted is an orphan island that ne to be spawn as new chunks
I will add that next.
and I will make so that it will spawn new compounds and single chunks. that way will look like recursive destruction down to the last chunk.

[zak]

Com to target error: 5cm / 2cm

What do you mean by "com" ?

[JoeJ]

Center of mass of the whole ragdoll.
i wanna place it at some target position, and if joints would be total stiff it would match that point exactly, but in reality it does not.
I have some ideas to reduce the error, but because error feedback typically produces other problems i'll see how far i can get without it first...

Can you say something about performance? You tried to run 22 ragdolls with exact solver and it's fast enough?
I never made serious measurements up to now.

[Julio Jerez]

But it's nice the interior stays intact while the outer shell gets destroyed faster.

yes that's cool, That is really a remarkable behavior, the reason for that is that the point pattern that I use for creation the voronoi cell is a regular grid where each point is translated by a random small value from the ideal position.
This is called as a Poisson distribution, and is should generate one of the strongest structures in nature. is generate a hexagonal cell arrangement, honey cones follow that arrangement.

and the remarkable part is that it behave as expected, a structure where only the corner are weak because they have the least number of links, after the corner are removed then the neighbor became the weakest and so on.
king of a natural layering layout.

however as cool as that is, it is only for testing the correctness of the feature. there are few different point pattern than lead to structures that are less strong and show more desirable destruction pattern.
for example a pseudo Gaussian distribution for a center point generate a structure that random weak point evenly distributed over the surface.
this is better for game, because chunk can peel off form at any hit point in the solid.

I just tried that, and it look more like game play feature.

I will now add one more Plane Crack way to peel off chunks. Basically this is finding and flag all the cells that cross a user plane.
the for each flagged cell, remove the link between them and any neighbor cell that is on the positive side of the plane.
this too generate two structure that can be separated freely.

this is cool for structure that break on pieces that are also structures.

[zak]

Can you say something about performance? You tried to run 22 ragdolls with exact solver and it's fast enough?
I never made serious measurements up to now.

Performance are excellent: (core2 duo, visual studio 2008)

physics time:
-20 running ragdolls 4 hinge (no arms)
exact: average 0.6 ms peak 0.8 ms - iterative: average 0.5 ms peak 0.6 ms
-20 running ragdolls 8 hinge (with arms)
exact: average 1.1 ms peak 1.5 ms - iterative: average 1.0 ms peak 1.1 ms

-40 running ragdolls 4 hinge (no arms)
exact: average 1.2 ms peak 1.6 ms - iterative: average 1.1 ms peak 1.2 ms
-40 running ragdolls 8 hinge (with arms)
exact: average 2.2 ms peak 3.0 ms - iterative: average 2.0 ms peak 2.2 ms

Exact solver is very close to iterative.
performance are almost linear both with the exact and with the iterative,
both with 20 ragdolls and with 40 ragdolls,
both with 4 hinges and with 8 hinges.

I'm investigating various other configurations.

Julio, is post correction applicable with exact solver or only with iterative one?

[Julio Jerez]

Julio, is post correction applicable with exact solver or only with iterative one?

yes it is agnostic to the solver, but I have not implemented the post correction for all joints.

This is not that easy, basically to correct the error after the integration velocity integration and before the position integration the joint nee to calculate the expect velocity,
so that is does not violate geometry of the constraint this si impelmenet by function
void CustomJoint::ProjectError () const

calculating the partial derivatives is not that simple, because for each joint definition, chain rules have to be define to see how the velocity will chine when the joint axis rotate or translate.
Even with tool like Mathematica it becomes difficult. The reason is that many time what seem intuitive is in fact not.
what I do instead is that I do using forward derivatives.

save the joint axis before integration,
do the integration to get the velocity at t + dt,
and the cancel the error by projecting over the joint axis.
even that is no that simple, but yield a very good result.

In the near future, I will change the code a little, because the solver do not have provision for letting the application to apply the correction,
the solver integrate the velocity and position,
therefore I the correction need to remember the position of joints.
I will make the change so that the solve call the application in between the velocity integration and position integration.
the way the correction will be more correct, because only velocities need to be adjusted.
This should provide zero drift for all joints

so far I did the Hinge and the universal joint because those are the joints used by the Forklift demo.
the more degree of freedom a joint has the harder the code is.

[JoeJ]

Thanks for the timings, seems i don't need to worry too much about performance, but...

-20 running ragdolls 4 hinge (no arms)

So you make running ragdoll using only hinges at hip and knee ?
I assume you use an external force (or up vector joint) to keep the ragdoll upright then?
Because if all hinges can move only forth and back, there's no way to move left / right? I'm curious...

I use 21 bodies and 20 joints. Only ellbows, knees, and toes are hinges, the rest are ball socket with powered rotation about any axis.
There are some mathematical issues (3 angles, but no specified order of rotation), but it works well in practice if i dont make them too stiff.

[JoeJ]

Haha, running jusing only ONE joint

... nothing new, but i hope i can learn something more about the dynamics of legs that can change length.
First thing i've learned is that running seems simpler to simulate than walking.

Can't get the video to work inside post:
http://www.youtube.com/watch?v=dmIjMEbs0Ww

[zak]

I studied BasicRagDoll demo to try to understand the post correction technique using only Newton C interface.

This is what I understand:

Let's imagine a simple chain of 4 bodies connected with 3 hinge joints.
body[0] (the root body)
joint[0] (body[0] parent, body[1] child)
body[1]
joint[1] (body[1] parent, body[2] child)
body[2]
joint[2] (body[2] parent, body[3] child)
body[3]


First of all call NewtonUpdate()

Then iterate from joint[0] to joint[2]

For each joint call the code as in CustomHinge::ProjectError()
Here we have three phase that correct and changes matrix, omega e velocity of child body respect to joint configuration
1) Calculate the exact matrix of child body and apply with NewtonBodySetMatrix()
2) Calculate relative omega, correct error than calculate global correct omega and apply it at child body with NewtonBodySetOmega()
3) Calculate relative velocity, correct error than calculate global correct velocity and apply it at child body with NewtonBodySetVelocity()

Copy the bodies matrix in the mesh to render (no transform callback)

Done.
(This is how I can see in CustomArticulatedtransformController::PostUpdate() )

Is it right?

[Julio Jerez]

yes, you also need to correct the relative position error.

you need to do it I tow passed just like the Fhtersto algorithm does.

the first past is a bottom up, first pass start form each leave body, and calculate the local relative velocity to its parent, and the locate relative position.
during this pass the local velocity error and position is clipped relative the constraint definition.
the second pass art for the root, and relatable the fix global position and velocity, for each child body

The lead to very goo result because the integration error on reach time step is small and linear. since each joint has a specific geometrical definition this allow the joint to truncate the error.
this means that the truncated error is not be integrated on the next step.
the fine result is that the error is bound to one time step. rather that being acculturated

[zak]

yes, you also need to correct the relative position error.

I thought this was done in the first phase of ProjectError() ending with NewtonBodySetMatrix()
In fact this is just the part that I have not yet well understood.
In this phase it seems that a local matrix with only pitch angle to be obtained with CalculatePitchAngle(),
than transformed to obtain the global expected joint matrix on child and than child body matrix, that is assigned with NewtonBodySetMatrix()

But if it's so how CalculatePitchAngle() can obtain a similar matrix?
If the two global joint matrix contain yaw and roll error to cut, it seems to me tha CalculatePitchAngle() cannot do it and can produce erroneous results.

Or is there other code related to post correction that i have not seen?
I mean:

(other code here?)
NewtonUpdate()
(other code here?)
Iterate from joint[0] to joint[2] and for each joint call code as ProjectError()
(other code here?)
Assign matrix to mesh for render

[zak]

ok, it should be so:

no other code related to post correction outside ProjectError()

Doubts remain on orientation correction in HingeJoint::ProjectError() made with CalculatePitchAngle()
Ad example, let imagine an hinge joint that have pitch zero but after NewtonUpdate() there is an error between the two pin and pivot matrices of 15 degrees of roll and then 15 degrees of yaw. If we apply the code

Code: Select all

        CalculatePitchAngle (matrix0, matrix1, sinAngle, cosAngle);
        dFloat angleMag = 1.0f / dSqrt (sinAngle * sinAngle + cosAngle * cosAngle);
        sinAngle *= angleMag;
        cosAngle *= angleMag;

        const dMatrix& identity = GetIdentityMatrix();
        dMatrix angleMatrix (identity);
        angleMatrix[1][1] = cosAngle;
        angleMatrix[1][2] = -sinAngle;
        angleMatrix[2][2] = cosAngle;
        angleMatrix[2][1] = sinAngle;


we have an angleMatrix with 4 degrees of pitch!


Wath about so:
1) make a copy of each body matrix before update
2) NewtonUpdate()
3) Set before update matrix to each body with NewtonBodySetMatrix()
4) ProjectError() only for omega and velocity, no orientation and position
5) Integrate position and orientation for each body with NewtonBodyIntegrateVelocity()

Ok, there is a little too overhead, but is it more precise?

In the near future, I will change the code a little, because the solver do not have provision for letting the application to apply the correction,
the solver integrate the velocity and position,
therefore I the correction need to remember the position of joints.
I will make the change so that the solve call the application in between the velocity integration and position integration.
the way the correction will be more correct, because only velocities need to be adjusted.
This should provide zero drift for all joints

A before position integration callback would be the best place in wich operate post correction: best precision, no overhead and even TransformCallback could be used again.