I'd say your probably right, and likely using some sort of physics API to generate a smoother after effect, especially when the skeleton is destroyed. I have to say thats a pretty cool looking game, but its probably done the same way most of the physic based 3D games are, just with a difference camera angle is all.

I am not so sure this is too terribly advanced, as good as it does look.
It’s a combination of IK, FK, and physics.

Basic animations such as swinging the arms are likely FK, but not run in a standard sense. Unlike standard FK, they get to the desired position within the animation by determining what physical impulse to apply to each joint to go from the current position to the desired position. Limitations on the sizes of impulses allow the movements to get off track from what was originally modeled in Maya without immediately jumping back on track on the next update.
This means if an arm gets hit while swinging, gets pushed down a bit, it has to get back up to its target position over a series of frames, resulting in much more dynamic and fluid motions.

The feet are IK, and likely use something similar to Sumotori Dreams to keep the player balanced and upright.
This is a bit advanced but not new (since it was already done in Sumotori Dreams). Since the only task is to keep the player upright it could actually be simplified greatly so that any standard IK algorithm could be applied (again, with impulses to drive the joints to their target positions).


Once the animations are using nothing but impulses to get to their target frames, any standard physics engine could then take over to run it. There is nothing special about the physics engine etc.

Of course breaking the skeletons means breaking the relationships between the joints of it and then using standard physics to repel them off the ball-and-chain.


All-in-all, very practical to implement. Only the way the animation system runs needs to be modified, and that modification is trivial, since it is extremely easy to calculate what kind of impulse needs to be applied to get from one orientation to another over a fixed amount of time.


L. Spiro

All-in-all, very practical to implement. Only the way the animation system runs needs to be modified, and that modification is trivial, since it is extremely easy to calculate what kind of impulse needs to be applied to get from one orientation to another over a fixed amount of time.

Could you explain how you would go about making those calculations? I'm considering implementing this and some other things...

Since we are only operating on joints and we assume them to be infinitely small (there is only one place on it we can apply any given force—this is unlike a box where applying a force to one of its corners almost always results in a different result from applying the same force to its center of mass) we don’t need to worry about where the impulse is applied in relation to the center of the joint. That simplifies things greatly.

Also we assume a fixed-interval time step here so that we can know the amount of time that will pass during the next update, because it is in that time that we want to reach the destination position.

So, for an infinitely small point with some mass, given an impulse over a given amount of time, the point will move by this much:
(F/M)*t
Where F is a force vector (and is 3D), t is time, and M is the mass of the object. Usually physics simulations store the inverse mass in order to avoid a division, and we are of course not accounting for friction or damping here (no need).

So you know where you are, you know where you want to be, you know your mass, and the amount of time you want it to take to get to the target.
D = 3D vector from starting point to end point.
D / t = How long it would take an object whose mass is 1 to get there in the given amount of time.
So if you have double the mass you need to apply double the force.
F = M * (D / t)


Of course you can then put a limit on F to make sure the arm (or whatever) doesn’t just jump to the target spot immediately, and this cap can be variable depending on how far away the target position is.
And all these equations should be done in joint-local space, otherwise you would have the hand trying to fly forward really fast when actually the rotation only involves the shoulder joint.
Convert the forces to world space afterwards.


L. Spiro

Hmmm... They're asking a LOT of money for a project of not well-known people. "We're... It doesn't matters really. Point is, we want a quarter million dollars please."

Though their project looks like it could require such amount of money, by that I mean it may be too ambitious.

Does anyone know how to implement the physics collision at 00:59 in this clip:
https://www.youtube....h?v=PvZchE30StQ

Fixed that for you. That's just standard rigid body physics. Nothing special. Pretty much any rigid body physics engine will do, and even then there are more impressive things. Exactly how he auto-generated the collision mesh from the graphical mesh, I'm not sure, but there are various methods (assuming he generates a poly-reduced mesh; he could be using the full mesh, but for high-poly models that's computationally expensive).

@L. Spiro: how costly (CPU-wise) are such animation/physics combinations?

I can really only estimate, but the extra overhead shouldn’t be too much, especially since you can avoid divides (inverse of time is a constant for the whole frame and should only be done once per frame).
Standard performance tips apply: Since it is per-bone, if it is too heavy, reduce the number of bones etc. But compared to what has to be done to the bones involving matrix multiples etc., this extra overhead will likely go unnoticed, so overall I would just say, “Negligible”.


L. Spiro