Ragdoll best practice

[zak]

I am developing a soccer game based on ragdoll made with custom joints.
To now i used Newton2 and exact solver, then i have updated to Newton3.
Because in Newton3 exact solver is not ready yet, i am trying with iterative solver.
I have obtained nearly two times performance but poor precision.

Now i want to try the technique at the base of CustomArticulatedTransformManager.
I use C interface of Newton.h
This is how i intend to proceed:

1) call NewtonUpdate ( not use transform callback )
2) phase bottom up: calculate relative velocity, angular velocity and local position and orientation of child body respect to parent
3) phase bottom up: let custom joint corrects those values canceling errors
4) phase top down: beginning from the principal body calculate global velocity, angular velocity and matrix of child body using corrected local values
5) for each body call NewtonBodySetVelocity()
6) for each body call NewtonBodySetOmega()
7) for each body call NewtonBodySetMatrix()

Is this the correct way to proceed?

[Julio Jerez]

if you look at the file
../applications\demosSandbox\sdkDemos\demos\BasicRagDoll.cpp
you will see how a ragdoll is setup using the CustomArcticulatedTransformManager class.

has you looked at that?

[zak]

yes,
but i ever used only C interface and i don't know the C++ framework.
In BasicRagDoll.cpp too many classes are involved ( CustomArticulatedTransformController, DemoEntity ecc.. )
and i can't see the core of the tecnique.

Can you explain me the tecnique using only C interface?
Which of the seven steps described above are wrong?

thanks

[JoeJ]

There have been some discussion in the middle of this thread http://newtondynamics.com/forum/viewtopic.php?f=26&t=7731

I have not yet tried myself, because i have the same problem with the example code - i see a lot of setup but no 'core'.
I assume callbacks like CustomHinge::ProjectError are called from Newton during NewtonUpdate().
But i don't know other things involved or how and if it can be done with the C interface.

I'd like to start with a simple scene like 3 bodies and two hinges, then understand what i need to calculate and try to adapt to my own joints,
but i don't know how to start. I have not yet spent enough time trying to figure it out because physics of my ragdoll stuff are already good enough and i must focus on control problems... so just to give some additional feedback.


Zak, what do you mean by soccer game? Mapping traditional animation to ragdolls or simulate the whole movement?
My state is a self balancing ragdoll. I was unable to solve the 'standing on only one leg' problem for months, but hopefully can do it the next days.
Then a walking ragdoll should be possible, but i'm far away from a ragdoll playing soccer

[Julio Jerez]

I have not yet tried myself, because i have the same problem with the example code - i see a lot of setup but no 'core'.
I assume callbacks like CustomHinge::ProjectError are called from Newton during NewtonUpdate().
But i don't know other things involved or how and if it can be done with the C interface.

I do not understand when you gsy say not core.
also Zak hwo are you using the custom joints? those a c++ classes.

make I can make an exampel of a c inteface that conver a cuntom makeger to a c library

[JoeJ]

make I can make an exampel of a c inteface that conver a cuntom makeger to a c library

Great, that should do the trick Also don't forget callback interface for people like me not using the joints from dCustomJoints and implement their own stuff.

What i mean with 'core' is that i can't find the second part of the 'two pass' technique, but the C thing will clarify all confusion most probably...

[zak]

My project is a full physics ragdoll based soccer game.
I work on it by years because unfortunately (or luckily) my job leaves me little time.
For now i have selfbalancing ragdolls that walk and run.
When movements are slow all right. But when a ragdoll runs faster, legs move very fast, and ragdoll begins to disarticulate
With exact solver ragdoll can run faster without disarticulations than with iterative because it have more precision.

So i am very curious to see how this tecnique can help to obtain more precision.

I have ever used only C interface. I have my own C++ wrapper of Newton.
With custom joints i intend my own custom joints based on NewtonConstraintCreateUserJoint(),
NewtonUserJointAddLinearRow() ecc.

An example or a tutorial in C interface only (also without graphics) would be perfect.

[Julio Jerez]

I see if I can re enable the exact solve mode this weekend.
In newton 300 the exact solve can be mix with the iterative one, based of the joint count, so maybe that will give the speed

by I believe you can make the rag doll wi the iterative, using the post correction.

I will try the add two more tutotial to the c interface one for a joint, and one for the CustomArcticulatedTransformManager

[zak]

I see if I can re enable the exact solve mode this weekend.
In newton 300 the exact solve can be mix with the iterative one, based of the joint count, so maybe that will give the speed

Wow, that's fantastic!

by I believe you can make the rag doll wi the iterative, using the post correction.
I will try the add two more tutotial to the c interface one for a joint, and one for the CustomArcticulatedTransformManager

Oh, surely, with a Newton.h only tutorial i will study and try the post correction.

I can not wait to compare the two methods, or to try different combinations of these.
I could use exact for legs and iterative for arms for example.
Or exact for the ball to obtain more realistic behavior when bouncing and rolling and iterative with post correction for ragdolls.
Or... or.. etc.
With exact solver working and iterative post correction the possibilities are endless and I can not wait to try them!

[Julio Jerez]

Ok I did the easy part first.
I re enabled the exact solve mode.
this make joint a lot stronger, for the type of application that you are aiming to.
the joints also has a parameter that let you select whet to use exact solver mixed with the iterative solver.

Code: Select all

void NewtonUserJointSetSolver (const NewtonJoint* const joint, int solver, int maxContactJoints)

later I will expose that function in the customs joint
void CustomJoint::JointSetSolverMode (bool mode, int maxContactJoints) const;


this function let you mix exact solve with iterative solver mode, basically you set the engine to iterative mode, and what you add joints
you set that joint to be solved using exact or iterative solver mode.
this way only the part that you want more accuracy will be solve using exact solver and everything else will be iterative wit is faster.

[JoeJ]

Tried it out - max 20 contacts for each ragdoll joint, here is difference i see between iterative / exact solver:
Runtime debug mode: 60 / 16 fps
Release mode: 60 / 60 fps
Maximum percent of error to reduce, while keeping ragdoll stable balancing: 25% / 100%
Com to target error: 5cm / 2cm
Smash powered ragdoll to ground: Joints displace but come to rest and correct slowly / gain energy to explosion

It's the last point why i always liked the iterative more - it's less exact but does a better job at conserving momentum for me.
However, meanwhile i have methods that could prevent this energy gain, and using it only for legs might become useful...
To fight the com error problem i assume the post correction will be faster and maybe better, i'll stay tuned for that
Actually ragdoll can balance on one leg on a moving / rotating platform, but if i additionally twist leg about up vector, com error becomes too large.
Actually working on walking ragdoll

[Julio Jerez]

I just uncomment out the code, and change the functions that I need so that is use the dgVector class

I test once and saw it ok but after I tested the second time I saw some errors, I believe that there is a bug.
if I just put a simple but on the flat found it jitter, so there most be some error some where.

this may be because some change or optimization that I made for the iterative solve, that I di no make for the exact solver since it was commented out for so long.
the good news is that it eassy to reproduce, maybe it is eassy to fix too.
I will check that tomorrow.

[JoeJ]

this may be because some change or optimization that I made for the iterative solve, that I di no make for the exact solver since it was commented out for so long.

If i set exact solver for whole world, no energy gain.
If i set exact solver for every joint in ragdoll, no energy gain.
Only if i mix exact and iterative, the gain seems to happen.

EDIT:
This observation comes from lifting ragdoll up with a force based mouse pick - no collisions (ground or self) involved

EDIT2:
Hey, the voroni cells cube destruction demo is really nice. Maybe i'm wrong and all others are right, when they say destruction is more fun than creation

[Julio Jerez]

Hey, the voroni cells cube destruction demo is really nice. Maybe i'm wrong and all others are right, when they say destruction is more fun than creation

there is still tow more things I need to do to complete the feature.
the conetctivity graph is completed, however the code the figure out what peice to desconect by a naive algorithm.
right now it try to emulate an enegry wave.

-It start from the hit point, with some impact enegry.
-if the hit impact energy is grather than the glue energy the keeps the chuck conectedd, it detach that cell.
-it damp the impact energy by some factor,
-for each neigborg cell, repeat the proccess.

this works surpriscinlly well but if has two problems.
the first one is that it may detach cells that coul not move, and the make the solver generate singular contact joints.
this is eassy to fix with a small solver that bild the constatint matrix of the conctact point normals, and determine fhe matrxi is not singular.
if the matrix is singular it needs to get more neights to solve the singularity.
bascially that contact can be save with the graph, and the contact joint. and many precomputed values can be save as well.

the secund bug is that as teh struture si destruied in may leave peieces that has no conection to the root.
this is also eassy to solve, this is the exact same problem that garbage colletec languae solve fo rmemory manager.

it can be solve by three way colloring or or by a sweep and collor face, which is iterate teh graph for a root, colloring each cell one color.
each cell.

the in a secund pass, for each cell tha wat not collor, that become either a single chunk, or a new fractured compound structere.
this will make so that you can have a buidling and you shot the columen and the celling fall when tehy has not support.

there are so many things I want to do in the engine, but unfortunally I can not spend the time because of a 9 to 6 job.
some people are lucky they get pay to do what the like, some aren't

[JoeJ]

Unfortunately the laws of luck are harder to understand than the laws of physics.
Or is it both just a question of... relativity?