Physics and Animations - How to Marry the Two?

Started by
5 comments, last by Cornstalks 12 years, 5 months ago
I've been googling this for days and haven't found a particularly pretty solution. Here's the deal, I'm making a 2D game and am using Box2D for handling my physics. It's not really a platformer, and it's got a heavy emphasis on the physics simulation aspect, so I do need to try and get some "realistic" physics going on here (or at least faking the physics so they're realistic enough). Everything is fine and dandy, except for the fact that I'd like some object's/characters to be animated and I'd like to have boxes/other-objects respond accordingly to the physics of the animation.

Here's an example: Imagine some character is walking to the left (and he's got big dangly arms that swing) and a trapdoor opens above him and spills a bunch of little boxes all over him. I want these boxes to bounce and roll off of him, and for his big, dangly, swinging arms to knock the boxes they hit out of the way. If he kicks a box, it should move, but if he steps on a box it shouldn't squish it to death, but rather he should just be standing on the box (or a pile of boxes, should he step on a pile of them).

I've thought of using kinematic bodies and just setting their position/rotation data, but this doesn't work well (because the character can't stand on a pile of boxes, as the kinematic body pushes them out of the way, plus objects tend to tunnel through moving kinematic bodies, even at low-ish velocities). Using regular bodies with a really high mass/density and setting their position/rotation data doesn't work well either, as it has the same problems as kinematic bodies. Using regular bodies with normal mass/density and setting their position/rotation data doesn't work well because it causes too much tunneling, even at low velocities.

What are the common solutions to this problem? Are there any common solutions?

The only one I can really think of is customizing Box2D. I think I'd have to add a little bit of logic that would detect if it's a box/other-object colliding with an animated object, and then apply all the corrections in the solver to the box/other-object and not to the animated object. Though I'd have to add some special logic for dealing with gravity and an animated object standing on a box so he doesn't just squish the box to death and cause it to tunnel through the ground or through his foot. But before I go through the nightmare of customizing Box2D I want to see if there's any better solutions.
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
Advertisement
Um, can't you just use forces/torques instead of setting the position data on the character's joints to control its animation? This would mean that the character is affected by the environment. I don't know if it's a problem gameplay-wise. And of course, making the animation would be quite tricky, maybe you'd have to write a custom animation importer that coverts the kinematics to forces.

Maybe you could play around with the mass/inertia of the body parts to make it look good, or you could use different values when animated or in "ragdoll" mode. Or you could constantly recalculate/scale the forces/torques on the character's joints to somehow match the desired kinematics as closely as possible even when heavily affected by the environment.

EDIT: so basically use force driven animation instead of kinematics driven animation (I don't know much about animation, maybe that's fundamentally flawed)

Um, can't you just use forces/torques instead of setting the position data on the character's joints to control its animation? This would mean that the character is affected by the environment. I don't know if it's a problem gameplay-wise. And of course, making the animation would be quite tricky, maybe you'd have to write a custom animation importer that coverts the kinematics to forces.

Maybe you could play around with the mass/inertia of the body parts to make it look good, or you could use different values when animated or in "ragdoll" mode. Or you could constantly recalculate/scale the forces/torques on the character's joints to somehow match the desired kinematics as closely as possible even when heavily affected by the environment.


Thanks for the reply. Sorry, yeah, I should've covered that case in my OP. I've thought of doing it the first way you mention, but I'm worried it would really complicate the animations. Game-play wise, I might be able to work around it (I'm trying to think of an instance where that behavior would be incorrect, but can't, which may be a good thing :)). Converting the animation kinematics to forces wouldn't be too bad, but the thing I'm scared of is kick-back from external objects. What if something knocks the arm? Do I move the arm? If so, do I play a particular sprite animation? How can I be assured that the limbs will be in the correct places for a particular animation sequence? Do I stop an animation sequence if a limb gets out of place?

I wouldn't mind (and in fact would probably desire) if the character as whole responded physically to other objects. That is, something hits the arm and the whole character moves back, rather than just the arm moving in response to the collision. That way the sprite animations wouldn't have to change, but the character would appropriately respond to external forces (i.e. if it were standing on a bunch of boxes).

I've thought of modifying Box2D so that corrections from the solver to animated objects get applied to the animated object as whole, rather than just to the individual limbs. Then I'd animate the object by converting the kinematics to forces.

I've also thought of scaling forces/torques, as you mention. I'll have to investigate that further though. I'm not sure how computationally expensive it is, particularly for chained limbs/joints (i.e. shoulder to elbow to wrist to hand), or how accurate it usually is. Do you, or anyone, have any particular experiences with this method so I can know what I can/can't expect from this solution?
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
Sorry, I didn't know you use sprite animation. Well, that makes things much harder. Maybe you could use different sprites for the different parts, then "re-spritize" the character

For scaling forces to mach kinematics: I don't think you have to be that accurate. I guess no-one would notice if one or more limbs are a bit off.

But these may be totally stupid, I never worked with animations...
Do you want to animate many characters? If not, I wouldn't be too scared about computational expensiveness.
You could use forces to try to move the limbs to the positions of the current animation, if they get hit theyll just take longer to get there. Not sure if that looks very great though.

o3o

So your character is made of multiple, linked components -- e.g., torso, arms, legs -- and each is rendered as a sprite? So it's more-or-less a skeletal animation system? If so, the following applies:

My understanding is that the link in physics-based animation between the animation data and the input forces is, as in the real world, a feedback controller.

The idea is that your animation serves as the reference input for your feedback controller (e.g., a PID controller for each joint), and that these controllers generate the actual forces or torques that are used by the physics simulation.

How exactly you specify your reference trajectories will partly determine how this works. You could specify joint angles, or you could specify the positions of points on the characters (think of the markers on motion-capture actors). With the latter representation, a "computed torque" (aka Inverse Jacobian) feedback controller would be reasonable. A Jacobian-Transpose controller could also do the trick, which is mathematically equivalent to just attaching the points on the character to the reference points by invisible springs and dampers.

This last fact may provide you with the most helpful mental image: Imagine that, in addition to the character that you display and that interacts with the world, there is an "invisible" copy of the character, which, apart from bulk translation and rotation, does not interact at all with the world, and which you animate. Now imagine that the two are connected by a system of springs and dampers. If the "invisible" character lifts his hand through a ceiling, then the "visible" character will lift his hand up to the ceiling only until it makes contact, after which the spring connecting the visible and invisible hands will simply stretch. And if the "ceiling" is actually a movable box, then the force that is exerted on the box in the process will cause it to move, as part of the overall physics simulation. I think that sums up the spirit of the idea.

So your character is made of multiple, linked components -- e.g., torso, arms, legs -- and each is rendered as a sprite? So it's more-or-less a skeletal animation system?


Actually, it's the other way around. Each object/character is a single sprite, with a set of fixtures defining it's physical body that interacts with the rest of the world. Sorry, I should've said that in the beginning. But still, that was helpful information that I will probably need in the future, whether in this project or another, so thanks for the feedback!

I think I'm going to try taking some of the ideas you've all mentioned and some ideas I've thought of, experiment with them all, and write a blog post about what I find. It'll probably take me awhile to do it all 'case of school and all, but I'll post back here with a little link saying what I've found. If anyone as any additional ideas to contribute, I'm all ears!
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

This topic is closed to new replies.

Advertisement