top of page

IK Solvers for humanoid characters



The goal of a character is for the player to get immersed into the characters shoes. To not only relate to them but also be able to believe in a way that they are alive. There are a lot of different stuff you can try to achieve that effect. But one of those that I want to dive deeper into is the different IK solvers.


Having characters who you can play as, that interact with the world around them goes a long way into making the character more believable. One of those examples can be a character who's feet match the ground, or a character that turns their head to look at a specific object.


I am gonna show you two different examples to help you visualize:


Without IK solvers


with IK solvers

As you can see in the two examples above, the first example is without IK solvers. The character just floats in the air and doesn't react to the wall or even try to look at the red sphere. It doesn't in any form try to match the environment it currently is in.

This might not seem like a big issue but it makes the world and the characters feel less dynamic and alive. In contrast with the second example, which uses my implementation of the IK solvers. You can immedietly tell how much more natural the charater is standing and you could even say the character feels much more alive as it is interacting with its environment.

This is a topic I've always been interested in and one I want to dive deeper into. 

So what steps do we take to achieve this?

We should start by first establishing what a IK solver is. In simple terms an IK solver essentially "solves" a part of a body, so that as an example the characters arms actually touch the wall when the character is near a wall. Another IK solver could be a solver thats "solves" the issue of the characters feet adjusting correctly to the ground.

How will we manipulate the characters arms and legs?

The second important thing to establish is how will we manipulate the different parts of the body? We will do that by using IK which stands for inverse kinematics. Its an algorithm that rotate the bones of an arm or leg towards a target, which we ourselves decide.


There are many algorithms for IK like FABRIK or CCD. But for my implementation I will be using FinaIKs "limb IK". Which has implemented one of the following but with a major advantage, it also solves so that the legs and arms bend correctly. As you can see in the examples above. This is a huge benefit and is the reason why I chose to use it.

Goal of specialization

There are many different solvers but my goal will be to implement only 3 of them:

IK Ground Solver 

IK Hand Solver

IK LookAt Solver

I will also create custom editor for all of them, to make adjusting variables and assigning the bones much easier.

IK Ground Solver


What does the IK Ground Solver solve?

The IK Ground Solver places and orientates the characters feet to best match the ground it is standing on. While also adjusting the characters hips to match the feet. 

What I learned and the issues I faced

I learned something very valuable when it comes to implementing IK solvers like the IK Ground Solver. And that is to preserve the original animation as much as possible. We don't just want to completely override the original animation when we enable the leg IK. Both the leg IK and the animation should go hand in hand to create that final image.

Using only the leg IK on its own, doesn't work as the leg will just be stuck on the ground, which means we will have to figure out a way to move the leg on our own. But that misses the point for this particular IK solver.

Preserving animation might not be that obvious at first, when it comes to this particular IK solver. I myself came to this conclusion after a lot of trial and error. Consulting with my teacher and looking at FinalIKs implementation of the IK Ground Solver was when it finally clicked for me. 


I also learned that the animators have already given us all that we need by the root bone. When they animate their characters, they use the root bone as the ground, so when doing walk animations they make sure that the foot never goes under that root point. We can use that to our advantage and each frame sample the vertical offset from the foot to the ground. At the image above you can see that we calculate the difference between the foot and the root bone (the root bone is the red sphere).

IK Ground Solver Editor


The image above is how the IK Ground Solver editor looks like. There is a few settings you can change, my goal with the editor was to make it as easy as possible to change the most important settings and make the user experience as smooth as possible. 

Improved user experience


If you assign a root bone you can even search after a specific bone between all the bones under the root bone. This can save tons of time, as you don't need to open up the whole hierarchy of bones to find the one you need. Now you can just search after it. You can also drag and drop a bone and ping it by clicking on it once or double click it to select that bone in the hierarchy.

Improvements for the future

Even if the final result can look quite good, there is a few edge cases with this IK Solver where it completely goes crazy and looks weird. As an example you can very easily tell when going up stairs, that the toe of the foot goes inside the stair step. This is because we are only raycasting a specific point on the foot and not the whole foot.


One solution for this would be to use a capsule collider for the whole foot and use that to find the point of contact. I would imagine using unique animation for the stairs and making the movement speed much slower would help it look better. 

IK Hand Solver


What does the IK Hand Solver solve?

The IK Hand Solver places the hands on the nearest wall to give the illusion that the character is trying to stop itself from walking into the wall. 

What I learned and the issues I faced

When talking about the IK Ground Solver I went into the topic that the animation and IK has to go hand and hand. But in this particular case and IK solver, we don't have to take into consideration the animation that is played. We just want to override the animation completely. 

My first implementation was to cast a few rays in a arc, starting from the characters forward. And if any of the rays would hit anything it would stop the arc. I would than calculate the hit point and move the hand there.  This worked great but the characters hands would only be placed on those specific ray hit points. 


I than got the idea from a collegue to try and find the middle point from all the rays that hit a wall. With this approach I would get a more natural placement of the hand.


In the image above you can see gray lines, which represent all the rays that we are using. The black lines represent where in the ray we hit the wall and the green line represents the final position for the hand. 

IK Hand Solver Editor


The IK Hand Solver Editor is very similar to the IK Ground Solver Editor. Only difference is the settings the user can adjust. Like if the arms should have an offset from the wall or the max rotation for the hands.

One important setting the user can change is the Left Hand Axis and the Right Hand Axis. Not every character will have the same forward and up axis, as they might not be made by the same person. For this reason I made it possible for the user to set which axis should act as the forward and up axis so that the solver can orient the hand correctly to the wall.

IK LookAt Solver


What does the IK LookAt Solver solve?

The IK LookAt Solver rotates the spine and head to look towards a target. 

What I learned and the issue I faced

I started by taking the heads forward direction. I then determined the angle between the forward direction and the direction to the target. We can then apply that angle to the head. This worked suprisingly well when only using one bone but I quickly realized that this was the wrong approach.

The issue was that while the head might look great on it's own, adding another bone, like the uppermost spine would cause the head to overshoot and look beyond the target. The reason this happend was because the uppermost spine affects the head bone aswell.

This forced me to change up my approach, where now I had to take the previous bone's forward direction into consideration. Let's say we started at the uppermost spine bone. After calculating the angle between the spine's forward direction and the direction to the target, we move on to the head. Instead of using the head's forward direction, we use the uppermost spine's forward direction, that we calculated previously.

Now with this new forward direction we calculcate the angle between the new direction and the direction to the target. Then, finally we apply the angle to the head. When put into practice this solves the issue I previously encountered.


Another issue I faced was that the character snapped back when it stopped looking at the target. I solved this by having another variable save the rotation each iteration and smoothly rotate towards the final rotation of the bone. This replaced the snapping to a more natural and smooth movement. 

IK LookAt Solver Editor


The IK Look At Solver Editor is similar to the other two solver editors. The only difference is the fact that the user can change the weight of which the bone looks at the target and the maximum angle the bone can rotate to.


This was a very interesting topic to dive into and I came out of it having learned alot about IK solvers and animation in general. There is alot of improvements that can be made to all of these solvers but I think they look great for being implemented in only 5 weeks.

Fun that comes from IK Solvers

Before I go I want to showcase some of the fun gifs I took while working on this.
Hope you enjoy!



FinalIK for the inspiration and the Limb IK algorithm. I also used the FinalIK model to do most of my tests!
My collegue sitting next to me and for his help and inspiration! Felix Dunmar (

bottom of page