Hmm, can you give me a sense of how complicated your ragdoll is? To a certain extent, this is just the nature of the beast when it comes to iterative solvers. When I switch to a fixed frame rate of 60hz and fling the ragdoll around it actually does start
to separate a bit. In other engines, some people have proposed having your torso as the "master location/orientation" of the model being displayed and then only copy the orientations to the extremities of the model. Of course, that only works when
the ragdoll is attached to a single model with bones and stuff; not if the limbs are rendered independently as in Holodeck.
Try playing around with the VelocityIterations and PositionIterations settings and see if setting them to very high values makes any difference. Increasing PositionIterations can cause a lot of instability which can sometimes be compensated for by lowering
the PositionCorrectionFactor value (i.e. more iterations each applying less of a correction factor). If you find a set of values that keep the parts from separating, we can work backwards from there. I've had up to 200 iterations going before when trying to
get box stacking to be stable.
For rigid bodies and animation, I understand that inverse kinematics can be a tricky beast. A WorldPointConstraint combined with a WorldAngleConstraint may in fact work. I'd be curious to find out whether they would be sufficient as-is, or if they'll need
a MaximumForce property to prevent objects from going crazy if an animation says they're supposed to inter-penetrate with the environment or something. I'm not sure if a force limit would work in conjunction with the position correction part; there would probably
need to be a switch to use purely velocity-based correction in that case.
I hadn't thought about an angular spring yet, were you thinking about implementing this as a force(torque) generator or as a constraint? I know some engines implement springy behavior right in their constraints, but I'm unsure of how that would work with