Inverse Kinematics for Procedural Animation

Traditional animations are made statickly for a single or just a couple of use cases. But what if we could make these use cases close to infinite? By programming our animations we could open up a whole new world of animation.

Table of contents

1. Introduction
2. Inspiration
3. What is procedural animation?
4. Kinematics
   1. Forward Kinematics
   2. Inverse Kinematics
   3. Forward vs Inverse Kinematics
   4. Different IK algorithms
      1. FABRIK
      2. CCD
      3. Why FABRIK and CCD
5. What makes “human like” movement
6. Prototypes for bipedal movement
   1. FABRIK
   2. CCD
   3. Animation script
7. Testing prototypes
   1. A/B test
      1. Test setup
      2. Test result
      3. Test conclusion
   2. Performance test
      1. Test setup
      2. Test Results
      3. Test conclusion
8. Conclusion
9. Future work
10. Sources

1. Introduction

Procedural animation uses code instead of traditional methods of making animatons. This makes them more difficult to implement but in the end more versatile in a given situation.

Inverse Kinematics (IK) is a way of calculating how a chain of bones need to move. This can be used to create animations procedurally.

This is a subject is quite beneficial to the game /animation industry. Because making animations though code can save a lot of time and money. Since we don’t have to make a thousand animations for i.e. player positions and movement. But we can code a system that calculates accordingly to a variety of parameters. So the animation is able to be used in a plethora of use cases. Which adds to the realism of set animation.

In this R&D paper the following question will be answered: Is FABRIK or CCD more suited for human like bipedal procedural walking animation? The question will be answered through a prototype of an procedural animation system. This will use the two different IK algorithms to see which gives the most realistic “human like” movement. Given by a set of criteria: Ease of implementing, resemblance to “human like” movement and performance. More on this in chapter 4.

With this I want to learn more about how Inverse Kinematics algorithms work and how they are implemented. I also want to learn what algorithm is good for the use of a bipedal “human like” movement.

2. Inspiration

For this topic the most inspiration came from an YouTube channel called ‘Codeer’, with a video called ‘Unity procedural animation tutorial (10 steps)’. This sparked my interest in procedural animation and let me to try this method out in the previous semester. This was done with the already existing Unity package called FastIK. In my previous attempt at implementing procedural animation I got stuck due to not understanding the fundamentals of procedural animation an Inverse Kinematics. Which is something that I try to tackle in this project.

3. What is procedural Animation?

In order to get human like bipedal procedural animation right we first need to understand what procedural animation entails. Procedural animation generates an animation on an digital object through real time adjustments to rotation and or position of set object or parts of set object. This can be done in a plethora of examples, a waving flag, particle systems, ragdoll physics, wind going through trees and movement animation just to name a few.

In most games animations of characters or objects are “static”. Which means every animation is predefined and made for a specific purpose. Procedural animation is therefore used in a lot of games to offer a more divers series of animations, from indie titles to AAA studios. The most used method of calculating movement animation for procedural animation is Inverse Kinematics.

4. Kinematics

Kinematics is a field of physics which serves to define how the motion of points or objects behave. For procedural animation we will take a look at Forward Kinematics (FK) and Inverse Kinematics (IK). These are methods of procedural animation that calculate how to move an object chain to a desired target.

This method is mostly used for the animation of humanoid characters like (robot) arms / legs. But even tentacles and ropes are able to be animated through FK or IK. Since all of these objects can be divided into multiple sections.

FK and IK use the joints and bones from sections in calculating the movement. Joints are the points in the chain of where rotation is applicable. Bones are the parts of the chain that are in between these joints, so that a comprehensible digital object is shown. The image on the right shows a
chain of joints and bones as an example
taken from the human leg.

To understand how FK and IK calculate and approach these structures, we will take a look at FK first.

4.1. Forward Kinematics

With the bones and joints explained we now understand what FK and IK use to animate. FK operates with the same goal as IK, but with a different approach. FK provides an animation of the defined chain by taking one joint of the chain and rotating that specific joint. Which in turn moves the bones and joints deeper in the chain as shown in the example here. By combining the rotation of multiple joints we get movement. This however needs manual input and is time consuming.

4.2. Inverse Kinematics

Inverse Kinematics is defined as the problem of determining a set of appropriate joint configurations for which the end effectors move to desired positions as smoothly, rapidly, and as accurately as possible (6). IK uses the same setup as FK, as mentioned above, but calculates the movement differently to reach a desired target. Instead of rotating each joint individually to create movement, IK uses a target to then calculate the angles the joints in the chain should apply to reach that target. As shown in the example below. By following the target of the end joint of the chain, we get movement.

4.3. Forward vs Inverse Kinematics

Both IK and FK have places in the animation landscape. FK moves more in arc like movements but requires the knowledge of the angles each joint needs to take. IK moves in a straight path in order to reach a given target. While calculating all angles needed to reach that target. So each of the two methods can be applied to a different form of animating.

But for procedural animation of walking we need our animation to be as versatile as possible. IK is better for this since giving it only a target to make it animate on it’s own makes the animation more versatile. Unlike static animations that come with FK. Since FK uses a long list of predefined angles for movement.

That is why in this R&D blog in order to try to create more realistic “human like” walking, Inverse Kinematics will be used.

4.4. Different IK algorithms tested

As mentioned above IK will be used in order to simulate more realistic “human like” movement. In this chapter the IK algorithms of FABRIK and CCD will be explained. after which it is explained why for this R&D cycle FABRIK and CCD were chosen. From all the possible IK algorithms available. Like the Jacobian algorithms.

4.4.1. FABRIK

FABRIK or Forward And Backward Reaching Inverse Kinematics, is an IK algorithm but FABRIK avoids the use of rotational angles or matrices. Instead FABRIK finds each joints desired position via locating a point on a line. The FABRIK algorithm starts form the last joint of the chain. It adjusts each joint according to the desired location. After which it works it’s way back through the chain and adjust accordingly again. Thereafter a iteration is complete.

This method gives performance improvements since calculating an iteration takes less computational power. Because we don’t use rotational angles or matrices. As well as giving a realistic looking results. But this this method still takes more iteration and therefore more computing power than CCD.

4.4.2. CCD

Cyclic Coordonate descent or CCD Is, like FABRIK, a lot faster than most IK algorithms. But CCD is even faster than FABRIK. The biggest advantage to CCD on the other hand is that it is easier to implement.

Like FABRIK, CCD goes through each joint starting at the end-effector. It calculates either a rotation or quaternion to apply to the joint in order to move it to the desired location. CCD does this for each joint until it has reached the root joint.

CCD calculates and moves the chain from the end-effector to the root joint. This moves the joints opposite of their importance, since the outer joints are moved first. Having the outer joint move first makes the movement look less natural, especially in humanoid animation.

4.4.3. Why FABRIK and CCD?

Now that we know of the two most common IK algorithms used to solve IK problems, why these two? When comparing IK algorithms a couple of parameters were taken into account. Firstly, ease of implementing in a prototype so that it fits in the scope of this R&D blog. Secondly, performance at runtime. Thirdly, how close does the algorithm resemble “human like” walking.

For the first criteria the choice of FABRIK and CCD are pretty straight forward. For these two algorithms there a plethora of tutorials and papers explaining what the algorithms are and how to implement them. Therefore these algorithms had a more favorable amount of documentation.

For the second criteria, performance, we fall back on previously mentioned research. FABRIK and CCD take way less iterations and computing power to perform desired behavior. Than the Jacobian algorithms, since these algorithms don’t use the performance cost reducing methods mentioned. Therefore making them less desirable in runtime animations.

For the third criteria, resemblance to “human like” movement, research found it very prominent that the examples of FABRIK’s results look realistic. It might seem counter intuitive to pick CCD. Because mentioned before CCD makes movement look less natural. But this is negligible with the performance improvements found in the research done. This however is something that will be tested in the test done with the prototypes created with these two algorithms.

5. What Makes “Human like” movement?

After our choice in solving the IK problems with FABRIK and CCD we now need to know what actually makes humans walk like humans. For the scope of this project only the legs of human movement will be taken into account.

Research shows that in order to move like bipedal humans there needs to be a walk cycle. In order to attain balance and reduce energy consumption when not moving, the two feet need to placed close to each other. The upper body needs to be moving up and down according to the distance the feet are apart. So the legs don’t unrealistically over extend.

6. Prototypes for bipedal movement

In order to produce valid testing grounds on which to answer: Is FABRIK or CCD more suited for human like bipedal procedural walking animation? We need prototypes for both of these algorithms.

In this project the focus is on a completely procedural walking animation. That is why the choice of using a pre-existing unity package that only handles the FABRIK and CCD calculations was made. Full credits go to Daniel Erdman’s work on the Unity asset: Fast IK. https://assetstore.unity.com/packages/tools/animation/fast-ik-139972

The choice made to use this Unity package was in part due to the Scope limitations applied after a few weeks of research. As well as due to the fact previous work of student from GPE already explained in detail how exactly these algorithms work. This research focused more on the comparison of these two algorithms. With a completely self written animation script applied to both algorithms.

In the following two sub-chapters the results of these prototypes will be shown. The third sub-chapter will go into detail how the animation script handles the implementation of the “human like” walking. From which the criteria mentioned in chapter 5 will be shown. With corresponding code snippets.

All of the issues mentioned in these sub-chapters will be addressed in chapter 9. Future Work.

6.1. FABRIK

The first GIF here shows the full walk cycle, from starting and stopping. As seen a full walk cycle is implemented. But the legs still move in an instant to the new location. The steps start off small but gradually get bigger as the legs get further and further.

The second GIF shows the legs going up and down the stairs. The hips y position move in a slower pace up than down. This is to simulate effort being put into the legs in order to climb stairs.

It is quite difficult to see but the y position of the hips changes according to the distance the feet are from one another. The stopping animation, or idle animation, also shows how the legs try to find balance when stopping in motion. This however, as seen in the second GIF, the stopping sometimes overexerts in it’s rebalancing.

6.2. CCD

Just as with the FABRIK prototype you can see the results of this same animation script but with the CCD algorithm. Slight differences can be spotted. Like the end joint of each leg here being the first to change position. Which seem to simulate moving ones leg more with the shin than with the full leg. This falls perfectly in line with the differences in CCD compared to FABRIK, as mentioned before.

6.3. Animation Script

The first code snippet here shows how the legs find the correct positioning on the terrain they’re standing on. By raycasting downwards and adjusting the position of the targets accordingly. This however does not make the legs move up and down without them taking a step.







The second code snippet shows that the targets of the legs only moving when the correct leg needs to take a step. This corrects the legs moving in a hopping kind of motion.






This third code snippet shows when the animation script should take the next step.

This fourth code snippet shows how the hips of the legs calculate the position they need to take when moving. The position is calculated through another raycast. Than it is adjusted according to the position of the feet. So that only after a step the hips move up or down. It can also be seen that when going up the legs face a longer hip rise than when going down. This is how the effort before is simulated.

7. Testing Prototypes

This chapter will go into detail what tests were done in order to answer: Is FABRIK or CCD more suited for human like bipedal procedural walking animation? First up is the A/B test done with a group of 20 people, thereafter comes a short performance test done through the profiler in Unity.

The criteria that are tested upon are two of the ones mentioned in chapter 4.4.3. namely: Resemblance to “human like” movement and performance.

7.1. A/B test

In order to test if my prototypes were actually resembling real “human like” walking. The following A/B test was made: https://forms.gle/sUx9ZQAdNVYHen9Y6

7.1.1. Test setup

The setup for this A/B test was as follows. In the Google form the participants were asked to rate and compare the GIF’s shown in chapter 6. First on all 4 GIF’s the participant were asked to rate the GIF’s from 1 to 10. Going from “Not realistic at all” to “Human like realism”. After which the participants were asked to choose between the GIF’s of FABRIK and CCD. In this choice the participants were asked to choose which of the 2 GIF’s resembles “human like” walking more. After which they needed to explain their choice.

7.1.2. Test Results

After sending the test to a big group of people, 21 people participated in the filling in the google form. Screenshots of these results are in chapter 10 Sources, on source (9).

From these screenshots the following averages can be calculated:
– Rating GIF: FABRIK walking cycle is 5.71
– Rating GIF: FABRIK going up and down stairs is 6
– Rating GIF: CCD walking cycle is 6.29
– Rating GIF: CCD going up and down stairs is 5.95

These averages show that participants were more happy with how “human like” the CCD prototype walked. But slightly liked the FABRIK prototype going up and down the stairs. Although the difference in averages are minimal these preferences are shown in the following pie charts.

In these pie charts is shown that participants preferred the FABRIK prototype with going up and down the stairs, winning the vote with 57.1%. As well as preferring the CCD prototype when walking, winning the vote with 61.9%.

7.1.3. Test conclusion

From these test results it can be concluded that participants preferred the FABRIK prototype when the animation was going up and down the stairs. While participants preferred the CCD prototype during the walk cycle animation.

Even though the differences are small they do show a preference with the participants. Unfortunately this test only reached 21 people. Preferably this test should be shown to more people to get an even more accurate measurement.

7.2. performance test

In order to test the performance of each prototype, GIF’s over a period of 7 seconds were shot in order to shed light on the profiler use in Unity.

7.2.1 Test setup

This test was setup as follows. First the FABRIK legs were activated in Unity and the CCD legs deactivated. The Unity profiler was measuring the performance costs of scripts over a 7 second window.

7.2.2. Test Results

The GIF’s shown below are the results of the performance test. The FABRIK test results in a computing time of between 0.05ms and 0.1ms. With some Spikes exceeding the max average 0.1ms computing time. The CCD test results in a computing time of between 0.08ms and 0.11ms. With also some spikes exceeding the max average 0.11ms computing time.

7.2.3. Test conclusion

Although the seemingly random spikes in computing time are outside this test to be concluded. From this performance test we can conclude that over the 7 second period of time, FABRIK uses less resources in order to generate the animations than CCD.

8. Conclusion

With the tests from chapter 7 we are able to draw a conclusion to help us answer the research question: Is FABRIK or CCD more suited for human like bipedal procedural walking animation?

From the research made in this blog the expectations of the tests were quite extraordinary. The research showed that for computing time CCD would be faster, but with computing time FABRIK showed more promising. It was the general appearance of the walking animation that gave CCD points. While the research suggested FABRIK to win in all overall appearance. FABRIK was better in the case of walking up and down the stairs though. Unfortunately the control group used in the appearance test was quite small. But nonetheless the following conclusion can be made with the three criteria, mentioned in chapter 4.4.3.

On ease of implementing does FABRIK win by a Good margin. This is due to the sheer amount of tutorials, papers and articles on the algorithm. Since it seems like this algorithm is most used in the industry.

On resemblance to “Human like” walking CCD takes the crown. It performed slightly better in the walk cycle A/B test. Even though FABRIK was the favorite in the going up and down stairs A/B test.

On performance FABRIK takes the win as well. Not by much but we can see a marginal difference in computing time, when compared to CCD.

After concluding on the set criteria on which to answer the research question, the conclusion can be made that overall FABRIK scores better. With the ease of implementing and better performance in the given environment. Compared to the very slight differences in appeal.

9. Future work

If this research would be continued in the future there are some things that need to be revalued. The prototypes needs more work refining the animations, more animations to show for in general, the size of the test group needs to be at least 50 people and the performance test should consist of more that just script computing power in 1 situation. The code made for the animation script can go for a code revision as well.

Besides this is comparing only two of all the possible IK algorithms not best even with the given reasons. So in future work more of the available IK algorithms should be evaluated. Possibly also be worked on as prototype.

10. Sources

1. Ye, R. (2019, March 21). Inverse Kinematics for Game Programming – Ruihao (Ray) Ye [They/Them]. Medium. https://medium.com/@turtle50vp/inverse-kinematics-for-game-programming-5f9a408e24b2
   
   
2. FK and IK Explained – Which One to Use and When? (2018, January 25). YouTube. https://www.youtube.com/watch?v=0a9qIj7kwiA&t=159s
   
   
3. C# Inverse Kinematics in Unity 🎓. (2019, May 11). YouTube. https://www.youtube.com/watch?v=qqOAzn05fvk&t=428s
   
   
4. Aristidou, Lasenby, Chrysanthou And Shamir, A. J. Y. A. (2017). Inverse Kinematics Techniques in Computer Graphics: A Survey (No. 00 pp. 1–24). https://doi.org/10.1111/cgf.13310
   
   
5. Zucconi, A. (2020, April 12). An Introduction to Procedural Animations. Alan Zucconi. https://www.alanzucconi.com/2017/04/17/procedural-animations/
   
   
6. Aristidou, A. (2011, May 15). FABRIK: a fast, iterative solver for the inverse kinematics problem. Http://Andreasaristidou.Com/FABRIK.Html. http://andreasaristidou.com/FABRIK.html
   
   
7. Song, W., & Hu, G. (2011). A Fast Inverse Kinematics Algorithm for Joint Animation (No. 1877–7058). Elsevier. https://doi.org/10.1016/j.proeng.2011.11.2655
   
   
8. Bertomeu-Motos, A. & Miguel Hernández University, Elche. (2016, March). Biomechanics of human walking and stability descriptive parameters. https://doi.org/10.21134/doctumh.v1i1.880
   
   
   
9. Pictures of test results