Solver Accuracy

Gaming and Visualization Technologies APIs Physics Modeling (closed)
#1

Hi everybody,

I want to use phyx to simulate the ragdoll effect.

I have a character skeleton, and I made each bone of this character as a “sphere dynamic actor”, then use “D6 joint” to link them together, first I tried the eLocked flag, made each degree( translation or rotation ) locked, the constraint solver is perfectly, then I changed the rotation( swing & twist ) flag to eLimited, and set up the twist and swing limits, now the artifacts appeared, the bone actor appeared has no constraint,they are jitter and flying around, I have no idea why this happened, because I have tested the D6 joint in the SDK “samplebridge” demo, and they are stable in the demo.

Then I read the document, and found this:

void PxRigidDynamic::setSolverIterationCounts(PxU32 minPositionIters, PxU32 minVelocityIters);

this API can set the solver iteration count for each bone actor, and in the samplebridge demo, it is used:

setSolverIterationCounts(8,8).

“8,8” is OK for this demo scene, but is not in my application scene, I then tried some other values, eg. 32, 64, 128, 255, the greater the value, the more stable the joints, yes it is very stable when I set the count to “255,255”, I think I should use this value, cos it is so perfect for my simulation, but the document saied that “If you find a need to use a setting higher than 30, you may wish to reconsider the configuration of your simulation”. I guess the greater the value, the less effecient the simulation. YES, it is the case, when the amount of joints is large enough, the FPS of my application drops rapidlly, so I can’t use this value.

Now the question is :

  1. Why “8,8” is suitable for the “samplebridge” demo, but not for my application. In samplebridge demo,I use D6 joints to connect the planks, and the phyx scene settings of the demo and my application is the same, also the tolerance scale, the gravity, etc.

  2. 255 is not effective for application, but it can make solver stable. “you may wish to reconsider the configuration of your simulation”, but configure what? I don’t know, the doc has no hints about it.

  3. If there is no regular way to make it stable, should I use some other methods ? for example, seperate the single skeleton joint chain to multiple joint chains, and each chain contains a few actors and joints. because the fewer the joints, the more stable the solver.

Thanks!

#2

The SDK DOC said,
"The behavior quality of joints in PhysX is largely determined by the ability of the iterative solver to converge. Better convergence can be achieved simply by increasing the attributes of the PxRigidDynamic which controls the solver iteration count.However, joints can also be configured to produce better convergence.

the solver can have difficulty converging well when where a light object is constrained between two heavy objects. Mass ratios of higher than 10 are best avoided in such scenarios.
when one body is significantly heavier than the other, make the lighter body the second actor in the joint. Similarly, when one of the objects is static or kinematic (or the actor pointer is NULL) make the dynamic bodythe the second actor.
"
I must say,

  1. All the bone sphere actors in my application have the same radius and same density, so they are the same mass, the mass ratio is 1:1.
  2. All the bone sphere actors are dynamic actors.
#3

Confusing! I think there must be something wrong in my application, but I don’t know what is it.

I tried a D6 joint chain with only 6 dynamic actors ( like a bridge ) in my application. The scene configuration and the dynamic actor settings are the same as the SDK samplebridges demo, and the limits of the D6 joints is also the same, BUT the constraint solver is still unstable.

I wonder why ? Why the samplebridges demo is OK, but my demo is not ?

Is it due to the call to the simulation() and fetchResult() ? But I use fixed simulation step, the step size is 0.01666666s(second), and the max step count is 8, all is the same as the SDK sample.

This problem is confusing me for several days, and I have to admit that PHYX is not easy to grasp, the paramter settings is so much, and there is no expert to tell you what is the proper value you should set if you want the simulation stable.

#4

And the forum seems has no admin, does anybody know some other forums that I can find help? thanks.

#5

… Expecting an answer within three days from an open forum is not very realistic …. Especially not when there is an extensive and detailed story where crucial information is missing:
-which engine did you use? (PX2 or PX3) and which version of it.
-what are the settings for the solver(s)? e.g. the forward timestep that the solver needs to calculate (not the time it takes to calculate that timestep!) (PX2 and PX3); the # of substeps the solver takes within each timestep (PX2); the scenescale(PX3); the friction model(PX2 and PX3); the PCM (PX3); ect.
-what are other settings that can eat calculation time? E.g. Skinwidth (PX2); cone friction (PX2); contact correlation distance (PX3); ect.

For now I can tell that your guess on the mass ratios is correct, 1:1 is best. Also try to keep the inertia ratios (within and between actors) comparable helps. Further you might try to keep a good order with the actor assignment to the joints. The first actor should be a main body (e.g. the torus) the second the distant actor (e.g. the upper arm). In the next level of joints you assign the upper arm as first actor and the lower arm as second actor. I did not truly verify if this order matters, but in the past I had some instable behaviour when I did not pay attention to the order.

In the meantime (possibly I won’t visit the forum again within two weeks) you can also check your scene in the PhysX Visual Debugger (PVD). You need connect to it from the code and run in debug mode. In de PVD you can check if all joints are placed correctly. Perhaps you mis-positioned some frames. You can also record the scene and post it on the forum so that we can see what you are trying to tell.

If all fails, you can try Articulations joints. I never experimented with them, though they should be more stable in large chains.

Good luck