Hi. I've been using Unreal Engine 4 for a while now. It has some really nice built-in features, but the IK system is probably the worst you will find out there and I have been looking for a way to improve it for months now. I looked around for plugins. There's one or two in the making, but I don't know if or when they will be available. I had a look at commercial and non-commercial IK solutions and even asked the guy who made Final IK for Unity to do a port. I tried understanding the code from some projects I have the source code of, and I keep staring at the wikipedia article for Inverse Kinematics and some other pages about it. It is hard to admit, but I guess I am way too stupid to ever code my own IK, unless, maybe, someone would explain it to me (like you would to a child of slightly below average intelligence) step by step with pseudo-code or something. That's what I'm hoping for... or maybe a link... or even just a fancy name of an algorithm I should try to understand (or at least copy).

The biggest problem with UE4's IK is that it doesn't seem to know any kind of rotation limits for the joints of a humanoid (or any...) body, which results in unnatural twisting.

I guess all I need is some code to "solve" a chain of joints to have a specified bone reach a target location AND rotation, without any of the joints exceeding their rotation limits. The rest I hope I can figure out myself. If the whole thing would also look "natural" and allow me to set the "preferred weighting" of the joints (for example: only turn the head if possible vs. try to evenly apply rotation from pelvis to head to get the final head rotation), that would be even better. For different chains "pulling" on the same root or any shared joint, it would be nice to be able to apply a weighting here as well, so that, for example, the feet touching the ground has higher priority than the hands touching whatever. And it should be fast, of course.

A dream come true would be if someone has the link to a C++ library that can do all this already without the need for me to understand it...

Reading your second paragraph it seems you already know what to do, so i recommend you do it yourself.

This stuff tends to produce unexpected results and it's easier to fix this in self written code.

How hard this becomes depends mostly on the complexity of behaviour you need.

Keep this at a minimum, you can not expect to create an intelligent virtual living thing without making it a lifetime project ;)

The strategy i use is something like this:

It's advancing in small timesteps, so no need to calculate a exact final solution, just come a bit closer to the target.

E. g. reaching an ojbect with a hand:

Measure distance from shoulder to target, calculate ellbow angle so hand has same distance, calculate rotation of arm towards target,

If distance is larger than armlength, rotate sholder towards goal, otherwise away.

Eventually recursively repeat this through the entire skeleton, but do you really need to?

Most probably not, because the rest of the body is already busy with keeping balance, which is more important than grabbing object.

All this different steps towards goal don't need to know of each other, it's unlikely they work against each other, because the human bady is constructed in a clever way.

And if so, the next timestep will begin to fix it.

About joint limits:

Ignore them at planning motion, but if planned motion tends to violate them, slow motion down and finally stop it.

Probably other joints keep improving.

Highest priority is to prevent flipping cases.

Do this until you detect a real problem in practice and then think about how to solve it more likely at a higher level.

Up to now this is very fast and easy too, if you have solid experience working with transform hirarchies (which is usefull anyways so worth to learn).

I can not say much about animating natural looking velocities, because i calculate this from physical constraints (MUCH harder than IK).

I have developed IK solver for things like reaching targets with hands, but up to now i did nut use it, still busy with walking.

What should look good is to keep acceleration constant for an accelerating phase, and then switch to opposite costant acceleration for deacceleration phase.

There was i thread where i posted an code example for the leg IK solver: http://www.gamedev.net/topic/674831-any-information-out-there-on-physics-for-walkersmecha/

Thank you for your reply. That's a very interesting project you are working on. I've followed pc gaming for about 20 years now and I often thought how cool it would be to have actual intelligent ragdolls. I guess at some point in the future, when processing power can handle it, maybe there won't be a need for switching between animated and ragdoll-mode anymore. But for now, IK is probably the best compromise.

So, after stating the obvious, I'm afraid it's like you say. If I want it to look decent, it's probably gonna be a lifetime project. And frankly, these things are better left to people who understand maths :/

I mean, if I had the equations that do everything I described in my original post, I would code it. But I can't spend half a year working on this, only to find that by the time I'm done, someone uploaded a package to the UE4 marketplace that can do the same, only better...

I downloaded the IKinema runtime trial version, which comes with full integration for UE4. But after learning how much a full license would cost, I'm probably not going to use it.

I've got another question. Sorry, if it's not exactly math-related anymore. There are lots of free and open source IK solver libraries to be found on the internet. But virtually all of them are meant to be used with actual robots. My question is: is there any reason why those libraries shouldn't be used for virtual animation ("gaming"...) as well? Are they generally slower or something? Probably nobody knows, but I thought I'd ask anyway. I found this for example.

But virtually all of them are meant to be used with actual robots. My question is: is there any reason why those libraries shouldn't be used for virtual animation ("gaming"...) as well?

Give it a try. I assume those libraries do much more than necessary, at least for my needs. But if you can figure out how to use it in reasonable time, why not?

Personally my worries would be that using those libraries requires knowledge that i don't have.

Maybe you get a better answer or a library recommendation in a robotitcs forum?

I guess at some point in the future, when processing power can handle it, maybe there won't be a need for switching between animated and ragdoll-mode anymore. But for now, IK is probably the best compromise.

The processing power is no issue. My walking ragdoll is not much slower than a regular dead ragdoll - but i need to run the entire physics with at least 90 Hz.

The Newton physics engine is very accurate and stable so i don't need tiny timesteps or many sub iterations like research projects do.

Also i don't need to use a custom torque solver for the joints, i just use out of the box functionality.

(Keep an eye on it, it's developer plans to add characters soon)

Also there is Natural Motion used in games for years.

And frankly, these things are better left to people who understand maths :/

My math background is the absolute minimum, just self taught. IK Solvers kept me sparetime-busy for three weeks or so.

Doing a controller for a physical simulation is hard, but for animation you may eventually overestimate the problem.

If you want to improve / adapt / extend existing animation you should still consider doing it yourself.

If you want completely procedural animation including walking / running, then a IK library probably won't suffice and you need to look into physics as well.

To be honest the kind of IK used in games is easy to implement yourself, all you need is some trig knowledge and you're good to go!

Usually this goes one of two ways, either a closed-form analytic solution or an iterative solution.

The analytic solution is easiest when applied to 2 connected bones (think: upperarm and forearm, or shin and thigh). You just view each bone as a side of a triangle on a plane, decide where this 2-bone system should reach from and to, then apply some trig to calculate the angles and therefore the position of the joint/knee/elbow. Applying constraints might be done in a number of ways, for example by putting restrictions on where the target point is allowed to be set.


The iterative solution works for an any-length chain of bones. The algorithm is known as Cyclic Coordinate Descent. Basically you iteratively rotate bones (one after the other) to reach towards the target until you get close-enough to it that you consider it reached. Applying angular constraints can be achieved very naturally by just not rotating bones past their limits. You can also weight or dampen the angles to make certain joints more/less responsive, if needed.