Basically the body is kinematically driven by setting the state at everyframe and then the solver is called.
Wouldn't the solver overwrite the angular velocities in this case or can we assume that the velocities will satisfy the constraints - at least more or less?
i tried that approach in a acceleration based method, i solved the inverse dynamics problem in order to get the forces from the accelerations and they were passed to the solver as applied forces.
a simplified way to think about it is probably to imagine a static pose like in the press up case with a weight on the character back. What would the equilibrium configuration be? with a force based approach it would depend on the applied weight so it will be physically correct and visually playsibile. By setting directly the velocities the rest configuration would be the same, this because there is no notion of torque limit. So a character could raise a car by a single hand!:)
then again im not proposing such approach so im not the best person to answer these questions. I just had bad experiences with everything that isn't formally correct so typically i stay away from the "i feel lucky" approaches:)
cheers,
Antonio
Last edited by Antonio Martini on Wed Dec 05, 2007 3:45 pm, edited 5 times in total.
We're currently working on this in 2D (or, we were and will be, other work is interfering at present) using a PBD solver which handles large mass ratios very well.
We're still experimenting with different ways to formulate position-based motors; currently we're using finite-mass motors (i.e motors whose state is subject to relaxation along with the bodies) in order to achieve force-limit-type behaviour, and setting the motor states to correspond to the desired pose. So far this works pretty well, however it's pretty ad-hoc in that some types of motorized behaviours really seem better represented on the velocity-level.
One issue which is never mentioned is two-way interaction between animations and physics; what I mean by this is that rather than blindly playing an animation and using its current pose to set motor targets which are used to drive the pose of the simulated body, there needs to be feedback where the current pose of the simulated body influences the "playhead" position of the animation. Without this you get weird effects: a foot collides with something and as a result not be able to track the movement of the animation, which keeps playing oblivious to the foot's collision.. sometime later, the obstruction is removed and the foot "shoots" over to where the animation wants it to be. This makes me feel that physics-based animation blindly driven by kinematically-driven target poses (that just keep playing forward ignoring the physics) doesn't seem all that much better than simply eschewing physics and sticking to kinematic animation.
raigan2 wrote:
This makes me feel that physics-based animation blindly driven by kinematically-driven target poses (that just keep playing forward ignoring the physics) doesn't seem all that much better than simply eschewing physics and sticking to kinematic animation.
in fact you should have sensors that can inform you on what happened and switch to a compatible behaviour.
something on the lines of:
the ability of following an animation is a core functionality, like it could also be IK , but alone they dont do any magic. You still need to write the behaviours code and the logic that orchestrates them. Without mentioning the blend-in-out animation<->behaviours. Here the discussion is a bit more focused on the required basic functionalities i believe.
i think that the main problem is the quality of the resulting behaviours. I have seen very few behaviours that i like. a slightly drunken balancing and stepping make a nice technical demo but in terms of pure quality a motion captured animation looks 100x better.
Antonio, I just looked at the Havok demos you mentioned. It pretty obviously shows that all, but the stiff chain solver looks very bad or doesn't work at all in my opinon. Though it appears you might get away with a stiff solver for joints only and handle limits and (if needed) motors in a relaxation loop. So Featherstone might be an option as well.
Dirk Gregorius wrote:Antonio, I just looked at the Havok demos you mentioned. It pretty obviously shows that all, but the stiff chain solver looks very bad or doesn't work at all in my opinon. Though it appears you might get away with a stiff solver for joints only and handle limits and (if needed) motors in a relaxation loop. So Featherstone might be an option as well.
a stiff sub-solver would be needed for joint/motors, but when you have motors then you have the limits as well it just changes the way you use motors when limits are violated.
In general we want soft limits because real human limits are soft to some degree. Of course in a stiff solver limits can be softned by changing the ERP etc... or we can have a smooth transition function for the maximum motor force so that limits dont make ragdolls to look like robots.
i tried Featherstone + motors with PGS and i wasn't pleased with the results, i still needed many iterations. an idea would be to extend Feathestone to deal with motors, i think i mentioned this in a older post on this forum. However why research this option when there are already available solutions and we have limited time and considered that there are other problems to be solved? it would make sense only if we wanted to "invent" a new method in order to publish a paper/thesis about it.
cheers,
Antonio
Last edited by Antonio Martini on Wed Dec 05, 2007 12:04 pm, edited 1 time in total.
I'm the author of DANCE. Just for clarification, DANCE uses PD controllers in combination with torque limits to create controllers. In my experience, the difficulty with this type of control is determining good stiffness/damping values for the PD controller to use, especially when using chains that simulate legs and arms. My colleague at UCLA, Brian Allen, discovered a way to automatically figure out these stiffness/damping constants simply by keyframing poses. His algorithm automatically determines what stiffness/damping constants to set at every timestep in order to meet timing constraints. It's worth a look if you are working in this field:
The algorithm is able to handle perturbations during movement (character unexpectedly gets hit but needs to still meet position/timing constraint, so it is able to correct itself, etc.).
Hi and thanks for replying, i will have a good read at the linked paper later on...
ashapiro wrote:In my experience, the difficulty with this type of control is determining good stiffness/damping values for the PD controller to use, especially when using chains that simulate legs and arms.
however for real-time applications the other major problem is numerical stability as it's possible to end-up with stiff controllers and with an explicit integrator we are forced to decrease the time step. Is there any reason why you are using explicit PD controllers rather than motors? the way i see it in simple terms is that explicit PD controllers are penalty methods that try to enforce a constraint, while motors enforce the same constraint by solving the relevant equations directly and so are more robust and far easier to tune.
The original motivation for using PD controllers was compatibility - DANCE started using one dynamics simulator (SD/FAST) and then switched to ODE and I needed to maintain a generic interface that was compatible with any/most simulators. The problem with motors from a system development perspective is that they vary greatly between simulators. Also, motors act differently from PD controllers, which seem to have more human-like behavior under perturbation (positions aren't achieved under perturbations, joint torque limits emulate human strength limits, etc.). I haven't spent nearly as much time working with motors as with PD controllers, so take this with a grain of salt.
