Inverse Kinematics Using FABRIK
Motivation
As you can see in the GIF, the character first plays an animation when unlocking the door. This isn’t an issue and feels quite fitting. However, when the character goes to open the door by pushing it, you can see that they get stuck in a pose holding their hand forwards, but not necessarily in a natural position against the door.
For my specialization, I decided to go with implementing inverse kinematics in our game engine R.O.S.E to solve this issue.
Which method to use?
As I researched which algorithm to use, FABRIK (Forwards And Backwards Reaching Inverse Kinematics) stood out to me as being both popular among beginners and simple to implement.
This algorithm works iteratively in two stages. These two stages are run as many times as wanted or until the system reaches a desired maximum error.
During the first stage, the target position and orientation are applied to the end of the armature. Then, you do the same for the rest of the links working backwards using the previous link as the new target.
The second stage is just the same as the first with the only difference being that you start at the base of the armature.
Which method to use?
As I researched which algorithm to use, FABRIK (Forwards And Backwards Reaching Inverse Kinematics) stood out to me as being both popular among beginners and simple to implement.
This algorithm works iteratively in two stages. These two stages are run as many times as wanted or until the system reaches a desired maximum error.
During the first stage, the target position and orientation are applied to the end of the armature. Then, you do the same for the rest of the links working backwards using the previous link as the new target.
The second stage is just the same as the first with the only difference being that you start at the base of the armature.
Development Process
First steps
Getting started was quite simple and I quickly had a working example with a long arm seeking out the player. It was fun to play around with the arm making it twist and turn as it tried to follow me.
Downsizing
After initially testing out the system using many limbs for the fun of it, it was time to scale it down to make it applicable to arms and legs (the main goal).
However, as you can see in the video, the arm behaves quite erratically with the elbow pointing in seemingly random directions as you get close to it.
Pole target
The solution to the problem mentioned above was to implement something called a pole target. The pole target’s purpose is to give the elbow something to aim for. For testing purposes, the arm is told to always point the elbow upwards. The direction could be controlled by a target following the character and making the arm aim for that.
The solution for pole targets is taken directly from a fellow TGA student and can be found here
Conclusion
Final thoughts
It was interesting to discover how simple the basics of inverse kinematics were. I had always thought that there would be tons of complicated math behind it. Using FABRIK, it felt easy to only have to think about positions and points on lines.
I did quite a lot of research about implementing angular constraints, but couldn’t find a conclusive method to implement. I decided to do something on my own using quaternions. When I tried it out, it seemed fine as long as the arm was only limited about one axis. As soon as multiple axis constraints were introduced, the hand would often end up further away from the target than felt reasonable. I decided to put the idea on hold until I had done some more reading on the topic.
Ultimately, I ended up with a system where I was happy with how the end result felt to interact with. I had planned to apply the system to our player character, but there sadly wasn’t enough time before our polish stage. As everything is just positions and rotations, it would be easy to map it to the character’s joints.
Further development
The system is very bare-bones, but it could easily be expanded with more features.
Some features I would want to implement given more time:
- Angular constraints
- Multiple end effectors
- Physics-based movement
- Procedural animations