Spring RTS Engine

Since people tend to bring up IK in situations where it doesn't belong I suspect too many people have no idea what IK means so I'll explain it here.

Inverse kinematics means forming the animation from influences in an order that does not follow the direction of the hierarchy. Or in more practical terms: IK lets you move the hand or foot of a skeleton and automatically rotates the arm/leg bones to allow that position without scaling the bones. IK includes things like constraints (bones can only move in certain arcs, e.g. no backwards elbows) and indirect links (e.g. making a cable that connects to two parts of the model without being the parent of either part).

If you just move your bones to certain angles that's forward kinematics (FK). For a predefined animation you can bake an IK solution into FK keyframes, the result will have a static solution for the IK chain but unless you're altering the animation later on that bake will still be accurate and not require the processing time to solve the IK again.

For games you use FK almost exclusively. IK solvers are extremely rare in games and that's in a large part because they make no sense there. I'm uncertain if ragdoll or cloth simulations count as IK but I don't think so (since they only perform FK and a bit of upward force propagation, not solving the chain to get a certain end point). IK in games can be seen e.g. in Doom 3 to make the character's feet always stay on the ground no matter how the ground is shaped (e.g. on stairs the feet will have different heights). IK does NOT include aiming a weapon at something, that is simple FK with some rotation offsets, the base pose points the weapon straight forward and that pose is modified by rotating the spine bones like a turret.

I think some of the really advanced TA walkscripts also include IK to keep the feet planted on the ground no matter how the unit moves but almost nobody does that for units used in Spring mods.

In conclusion, when talking about Spring IK is most likely irrelevant and will only appear in your animation software before you bake it into FK keyframes if Spring ever gets a proper skeletal animation system.

just a note: starcraft 2 uses IK for spidery units exactly for what you said doom3 uses it for, or so i heard. (hence my gsoc proposal.)

Are there any good IK libraries, codebases, books to look at? I'm trying to code.. something.. using it.

It can also be used for roboter arms, so maybe google for those.
http://www.mathworks.de/products/fuzzyl ... pad.html#1 etc

IK does not have one universal solving method. Depending on the degree of liberty*, there may be none or more than one solutions. So you can't just code or plug in an algorithm straight from the book, since what kind of solution to choose when it's not unique is an aesthetic choice, depending on each particular model.

For exemple just take a simple two-segment robotic arm with a shoulder and an elbow, both being axle allowing movement along the same axis: For the everything inside arm reach, there are two solutions (elbow left and elbow right). For everything outside, there is no solution. Throw a couple more joints, and you soon have whole multi-dimensional spaces of solutions. Which constraints to add to limit the solution to one is pretty much arbitrary. For human bodies, you have some references (we prefer our knee to bend backward, our elbow to rest low, ..), but for TA robots, there's no way an automated program could guess what kind of animation the player would like.

It's kinda more complicated, especially when there's loops instead of just chains

I think the Blender IK solver just takes the first solution it finds.

Most of the time you compare the solutions with your current state and use the one with the least change.

jK wrote:Most of the time you compare the solutions with your current state and use the one with the least change.

Which again, turns into a really nice problem once you have enough degrees of freedom to make the parameter space of solutions multi dimensional :)

Also, if your just moving said joints from A to B, you may even forget to take into account the limited joint forces of each joint, in which case your running into the even uglier inverse dynamics problem.

jK wrote:Most of the time you compare the solutions with your current state and use the one with the least change.

Interesting point. There is still lot of liberty about what to consider "least change". Let's say you have a long multi-segmented arm, would the least change be a little rotation on every joint, or a larger rotation on just the last joints? Or maybe the user has to give "weight" to each joint to tell the IK how "costly" their rotation is? Or some function making each degree increasingly more costly the further from rest position? The choice of cost measure is limitless!

One way to get such a solution is by following the gradient
(means you will never get more far away with the tip from your target)

This tutorial explains this gradient algorithm:
http://freespace.virgin.net/hugo.elias/models/m_ik2.htm

But this gradient method isn't ideal, with more complexe joints it's possible that the tip will never reach the target, instead it reachs just a sink.
Also it will just minimize the solution itself and not the way to it, so as the article already said there might be better/faster/cheaper ways to the target.

There's the obvious sink issue, there's also the issue of not being sure the path and end position you get by following the gradient will be aesthetically pleasing. And adding the "uncomfortable position penalty" to the distance like he does in the article doesn't sound right, from a dimensional analysis point of view. I'd like to know how he picks the W1 and W2 that he uses to makes a penibility homogeneous to a distance.

This is generally a robotics problem. You can find papers relating to it more often in robotics than in computer simulation.

hey guis

KDR_11k wrote:I suspect too many people have no idea what IK means so I'll explain it here.

IK means all the unit animation suddently get pretty. IK is magik. With IK you don't have to write animation yourself, you just plug the model in the engine and bam it finds the animation for you. Not only that, but a better, smoother animation that which you could have written.

As for the technical mumbo-jumbo, leave it to the devs, that's what they're unpaid for.

I want IK now! If the 10 years old cavedog 3do look ugly, it's only because those lazy dev haven't coded IK yet!

When talking about skeletal animations with the devs one of them believed it requires IK, we resolved that back then but I get the feeling that there are still many people left who are misinformed.