TECHNIQUES AND AESTHETICS OF HUMAN INVERSE KINEMATICS FOR FIGHTING SIMULATIONS

Transcription

1 TECHNIQUES AND AESTHETICS OF HUMAN INVERSE KINEMATICS FOR FIGHTING SIMULATIONS MASTER OF INTERACTIVE TECHNOLOGY THESIS PRESENTED BY RYAN A. MCCORD

2 TECHNIQUES AND AESTHETICS OF HUMAN INVERSE KINEMATICS FOR FIGHTING SIMULATIONS A Thesis Presented to the Graduate Faculty of The Guildhall Southern Methodist University In Partial Fulfillment of the Requirements For the degree of Master of Interactive Technology With a Specialization in Software Development By Ryan A. McCord B.S., Computer Science, Southern Methodist University ii P age

3 Techniques and Aesthetics of Human Inverse Kinematics for Fighting Simulations Supervisor: Anton Ephanov Advisor: Jani Kajala Reader: Brian Squirrel Eiserloh Traditional key frame animations are not adaptable enough to the environments in which they are used. They are costly in terms of memory usage and development resources. This project implements an inverse kinematics solution for a fighting simulation to reduce problems with traditional animation techniques. The goals of the project are to generate believable procedural animations in real-time that allow control over the motion and interact with the environment. The project specifically demonstrates inverse kinematics on a character in a fighting game where the character has limbs that can follow predefined splines that adapt to the world. The system is constrained, weighted, and can be controlled by an artist, making it a scalable solution for many types of skeletons. iii P age

4 TABLE OF CONTENTS Table of Contents... iv List of Figures... vi List Of Tables... vii Chapter 1: Introduction... 1 Background of the Study... 1 Problem and Purpose Statement... 3 Research or Project Question... 4 Significance of the Study... 4 Overview of Methodology and Limitations... 5 Definitions... 6 Chapter 2: Literature and Field Review... 8 Literature Review... 8 Field Review Summary Chapter 3: Methodology Product and Development Process Data Collection and Procedures iv P age

5 Test Setting Data Analysis Summary Chapter 4: Results Performance Control and Adaptability Scalability Summary Chapter 5: Conclusion Artifact Limits Words of Wisdom Future Improvements and Further Research Summary References v P age

6 LIST OF FIGURES Figure 1: Frames of Traditional Animation... 2 Figure 2: UDK Inverse Kinematics for Foot Placement... 6 Figure 3: Iterative model adopted for the Jacobian transposition method... 9 Figure 4: Cyclic Coordinate Descent method may require multiple iterations Figure 5: Spore Inverse Kinematics Figure 6: Spore Complex Skeleton Figure 7: UFC 2009 Undisputed Full Body IK Targeting Figure 8: Multiple IK Solutions Figure 9: Unconstrained Inverse Kinematics Figure 10: Constrained Inverse Kinematics Figure 11: Shorter Constrained IK Chain Reaches the Goal vi P age

7 LIST OF TABLES Table 1: Avg. Time to Run IK Solution Table 2: Avg. Time to Run IK Solution with Maximum Bounds vii P age

8 CHAPTER 1: INTRODUCTION Animation in 3D graphics provides viewers with a satisfying experience by making characters and environments more life-like. Having believable, articulated figures is essential to video games and generating them has always been a timely undertaking. The underlying solution has been to transition bones from one frame to another. The system, in this case, is completely unaware of the overall perceived motion. It instead gives animators complete control and relies on their ability to create realistic movements. The traditional way of creating animations is by generating key frame poses throughout a motion. When blended over time, these frames represent a complete animation. Transposed bones are predetermined prior to runtime, and not generated on the fly, thus making animations very rigid when used. To appear more realistic and modular, 3D games use blending to transition from one animation to the next. Even then, animations do not satisfy the needs of the many environments in which they are used. A more reliable and adaptable solution is needed. BACKGROUND OF THE STUDY Traditional key frame animations are the forward kinematics solution that is an industry wide standard for creating animations in 3D games. Key frame animations require a lot of data and memory to manage. Translation, rotation, and scaling 1 P age

9 information for every bone are required for every frame. This can become expensive quickly for high-resolution animations, especially if uncompressed. To achieve the best quality, every bone requires precise placement within each frame. When transitioning between frames, the system blends keys between one another to smooth motion. Blending is not necessary if the resolution of the animation is higher than the frame-rate of the system. An infinite number of motions can be represented by key frame animations in 3D simulations. Most of these animations require precise placement. For example, a character that must press a button needs to be directly in front of it, because the animation does not work in any other situation. In this case, the model must be transposed to the initial position before playing in order for it to appear correct. Figure 1: Frames of Traditional Animation A solution to make character animation more adaptable to environments is inverse kinematics. Using this method, when a model is ready to play an animation where the skeleton is within the bounds of its initial state, the animation can play without requiring a dramatic transposition. Inverse kinematics comes primarily from research in robotics 2 Page

10 and later adapted to 3D graphics. Most robotic uses only involve a single arm or inverse kinematics chain, whereas many 3D simulations require a full body skeletal solution. Their use in 3D games today is somewhat limited. Inverse Kinematics has been used to develop character animations faster in 3D modeling software and to aid simple in-game tasks. New techniques are always in development, and different methods of achieving them have both positive and negative effects. PROBLEM AND PURPOSE STATEMENT Animations, although completely controlled, often require transposition to the initial state before playing. This linear movement can look unrealistic in 3D games and takes away the appeal of the animation. Humanlike motions are much more adaptable to their environments and require more modularity than traditional animations offer. The goal of an inverse kinematic solution is to maintain control, preferably by artists, while providing an adaptable, procedural animation to interact with the environment. Animations can be very expensive to generate. The degrees of freedom for an articulated figure grow with each bone in a chain. As the movement space expands, it becomes more difficult to animate a figure at each frame. This also requires more data to store for a single animation. Every frame stores the transposition data of each bone, and compressing this data is another industry wide problem in itself. With inverse kinematics, there can be metadata associated with an animation prior to runtime, but it usually does not scale with the length of the animation. The performance problems with inverse kinematics are directed towards processing power, and algorithmic complexity. This of course grows with the number of IK-enhanced limbs in a skeleton. 3 Page

11 Inverse kinematics implementations tend to focus on one limb at a time and are often tailored to individual animations. It is more difficult to create a generalized system that can scale well with any application. This is dependent on the implementation specifics and performance implications of the solution. The purpose of this study is to implement an animation solution in a fighting simulation using inverse kinematics that can scale easily, and allows control over the movement while maintaining humanlike and believable aesthetics. Research or Project Question Is the inverse kinematics system scalable? Can the inverse kinematics system be easily commercialized? What are the performance costs of an inverse kinematic solution? In what ways can inverse kinematics solutions be adapted and controlled? SIGNIFICANCE OF THE STUDY Animations are an extremely important part of 3D games. However, the traditional key/frame approach is not adaptable enough to fit complex simulations. In many cases, the mesh translates to the correct position before the animation plays. The animation will always be the same, even in situations where the mesh translation is obvious and clunky, or the animation does not fit the surrounding environment. Inverse kinematics helps motion adapt to the environment by rotating individual bones to achieve a more realistic and believable animation, as opposed to traditional key framed motions. With more powerful processors, inverse kinematics is possible in real-time, and can 4 P age

12 alleviate memory management costs of animations. Of course, the biggest benefit is that fewer key/frames, if any, will drastically cut down animation generation time and remove heavy development burdens from artists. OVERVIEW OF METHODOLOGY AND LIMITATIONS After researching current techniques for solving human inverse kinematics, this study implements the most feasible, appropriate technique, and applies it to a common human motion. This motion compares to similar key framed animations in performance costs, adaptability, and determines the scalability of such a system. This study measures performance in terms of memory usage and processing burdens required to support traditional animations versus IK supported animations. Adaptability refers to if and how an animation can react to different situations. Scalability is measured by how general the system can be made, and how it would be useful in commercial engines. 5 P age

13 Figure 2: UDK Inverse Kinematics for Foot Placement The study is limited in the number of inverse kinematic techniques used. There are many solutions available and this study only implements the most appropriate and feasible one. As for comparing traditional animations to inverse kinematic supported animation, control, adaptation, and scalability are difficult to measure. Control and adaptation are determined by how different parts of the algorithm affect animation. This analysis coupled with performance results helps tell how scalable the system is. DEFINITIONS Kinematics the science of motion, without regard to the forces that cause it 6 P age

14 Inverse Kinematics a solution of determining the angles of joints in a skeletal mesh from position constraints IK the acronym for inverse kinematics Forward kinematics traditional key frame animation Animation a series of frames that represent a motion for a 3D model End-effector the device at the end of a bone chain designed to interact with the environment Goal an aim or purpose IK Chain A limb on a skeleton with one or more bones that the IK solver iterates over Constraint a limitation or restriction 7 P age

15 CHAPTER 2: LITERATURE AND FIELD REVIEW Compelling and exciting experiences drive modern video games. Unsatisfied players are very difficult to win back, and without anything new or appealing, an entire franchise can be devastated. Animations are important to delivering a unique experience. Inverse kinematics can make animations more believable for their environment and allows them to adapt to situations for which animators did not expect during development. This chapter will discuss the methods used in the industry to solve inverse kinematics and adapt animations. The methods explored here are techniques used in the industry to augment animations with inverse kinematics. Here, we will outline various algorithms, systems, and implementations of IK and describe their benefits and limitations. We will then explore applications that use Inverse Kinematics to achieve realistic animation, and determine their analysis of best practices. LITERATURE REVIEW There are many ways of implementing an IK solution. The most popular are the Jacobian Transpose and Cyclic Coordinate Descent methods. We explore their implementation and discuss their limitations and benefits. IK solvers can be very unstable for 3D simulations because most skeletons have natural constraints that are not restricted in a simple IK solver. For example, the human knee cannot bend above 180 degrees of 8 P age

16 motion. In an unconstrained IK solver, when moving an end-effector foot forward, the system needs to restrict the degrees of freedom of the knee, and constrain motion for aesthetic purposes. Here, we analyze how geometric constraints are added to an IK system and how they attempt to optimize the system. Wolovich and Elliot introduced the Jacobian Transpose method in It involves computing a force applied to the end-effector, the Jacobian matrix for the current configuration, and the resulting velocities for each joint. These joint velocities can be used to create a smooth tracking motion from the end-effector to its goal. Figure 3: Iterative model adopted for the Jacobian transposition method The Cyclic Coordinate Descent method is a heuristic search technique originally proposed by Wang and Chen. It minimizes position and orientation errors by manipulating one joint at a time, starting with the most distant joint and ending with the manipulator base. This reduces the n-dimensional optimization problem to a onedimensional problem at each joint. The algorithm simply determines at each joint, how much the end effector is off by (rotation or translation depending on the joint type), then updates and clamps the current joint to a new orientation or translation. The end effector updates its position, and the heuristic continues to evaluate the next joint. This process may require multiple iterations for the end effector to reach its goal. 9 Page

17 Figure 4: Cyclic Coordinate Descent method may require multiple iterations Chris Welman compares the Jacobian transpose to the Cyclic Coordinate Descent method [Welman]. This project seeks to implement the simpler Cyclic Coordinate Descent methods over the Jacobian transpose for several reasons. Welman explains that the Jacobian is not immune to kinematic singularities, which can cause oscillations if the joint velocities are high. He also shows that the Jacobian Transpose by itself does not work in the general case, and must consider the scale of the world and choice of scale for joint variables. Solving for scaling considerations introduces another matrix multiplication into the equation, and further increases the complexity, especially if that matrix is time variant. He points out that using the Jacobian, the end-effector takes much longer to reach its goal, as it gets closer than the CCD method. Despite the more aesthetically pleasing results of the Jacobian, Wellman explains that both can be constrained and joints can be weighted to achieve better results. In essence, we choose the CCD method here for scalability, stability, and performance reasons. With regard to 3D simulations, skeletons require constrained joints to keep from becoming unstable and to maintain aesthetic quality. In a Cyclic Coordinate Descent based solution, it is easy to clamp joints at each iteration of the algorithm to their 10 P age

18 boundary conditions. This is enough to keep knees from bending more than 180 degrees, and limbs from going through bodies. Wilhelms and Van Gelder outline another method of constraining the joint limits on the system using reach cones. Imagine a sphere centered on the root of the bone whose radius is the length of the bone. A set of points on the sphere can form a polygon window of space for within the bone may move freely. The maximum reach would encompass the entire sphere, meaning the bone is unconstrained. The algorithm would determine if the IK solution lies outside of the reach cone, and then force it to the closest point on the outer rim. Figure 5: A Reach Cone Joint Limit Welman also describes a different set of constraints that are necessary to skeletal motion. Take for instance, two end-effector hands that are reaching for opposing goals. The system must decide which goal the torso will lean toward. By applying weights to different constraints, the minimization of error at each iteration of the heuristic becomes a summation of error over all the sub-trees for a given joint [Welman]. This attempts to produce a blending effect between constraints and gives the system the ability to choose between them. 11 Page

19 The Cyclic Coordinate Descent method is used in this project because of its realtime implications over the Jacobian. While the Jacobian may look better, it is less stable, more complex, and takes longer for an end-effector to reach its goal. The CCD algorithm makes constraining skeletons much simpler, and provides enough control to generate motion with respect to 3D interactive simulations. FIELD REVIEW Video games and 3D simulations rarely use Inverse Kinematics for animation exclusively. However, several games use IK solvers to achieve a level of environment interaction and believable motion more than others. The titles presented here are Spore and UFC 2009 Undisputed. Spore uses Inverse Kinematics to give life to content that is created at runtime (after development). The creatures in Spore have an endless number of possibilities with regard to their skeletal makeup, which demonstrates the flexibility of the Spore animation system. 12 P age

20 Figure 6: Spore Inverse Kinematics The system outlined by the Spore team is very flexible, intricate, and robust. It is forced to take everything about skeletons and animation into account including the number of bones, joints, constraints, and the type of limb. Since content is created at runtime, the skeletal makeup is undefined, and therefore animations are difficult to create. 13 P age

21 Figure 7: Spore Complex Skeleton This system creates IK chains for different parts of bodies, such as spines or different limbs of arms. By defining the basic motions that each is required to perform, rules can be generated, authored by animators, and applied to skeletons of virtually any shape and size. This level of flexibility is invaluable when developing commercial inverse kinematic systems to use in more than one game or simulation, and is what this project aims to achieve. In UFC 2009 Undisputed, instead of segmenting the character into different limbs to perform IK on, the animation itself is broken into various parts that are retargeted. The game uses full body IK targeting to detect hits on opponents accurately, use fewer animations more efficiently, and move the character realistically. A single punch is broken up into the following motions: Movement translating the character to the correct position Twist rotating the character so that a forward punch will hit an opponent 14 Page

22 Lean tilting the torso so that the arm can extend far enough Punch Direction the direction at which the punch must move Arm Extension extending the arm forward Foot Locking keeping the feet locked as the character punches Figure 8: UFC 2009 Undisputed Full Body IK Targeting Most 3D games and simulations use simple blending between animations. However, real-time IK solutions are possible and used to augment a single chain at a time instead of a whole skeleton. This, combined with blending, can allow a character to perform an action and yet interact with the environment. 15 Page

23 Another engine that offers inverse kinematics support is Unreal Engine 3. It uses skeletal control nodes within its AnimTree system to decide which bones are augmented with IK. These nodes can be referenced in code and controlled by modifying blend strength between traditional animation and IK. This system contains many different control nodes that are either general or specific. General nodes may allow for an IK-chain of any length to be augmented, while specific nodes could be used only for head control or foot placement. One important takeaway from this system is that users can specify how limbs will bend by choosing a joint and placing an end goal for it. This simple step saves development time from providing a long list of constraints for each bone in the chain. SUMMARY The Cyclic Coordinate Descent algorithm is a very simple but adaptable IK solution. It is fast, robust, and stable. It can be constrained, weighted, and controlled with parameters that reflect the skeleton to which it is applied. This way, we can keep maintain control over animations and allow them to believably interact with the environment. By blending with a rest pose, individual IK chains in this project can act independently as limbs that attempt to meet their own goals. These methods provide us with the means make more believable fighting simulations and continue to solve the procedural animation issues of today s industry. 16 P age

24 CHAPTER 3: METHODOLOGY Inverse kinematics offers a solution to animations that seem repetitive and lacks environmental interaction. Key frame animations are costly in terms of development schedule and memory. Robotic limbs introduced the need for inverse kinematics and 3D graphics later expanded systems to full body skeletons. There are many ways of implementing an IK solution, but a fast, reliable algorithm is necessary for real time simulations. The Cyclic Coordinate Descent method provides speed and stability, with an aesthetic quality that satisfies the needs of the video game industry. This project implements the CCD algorithm in a fighting simulation to demonstrate the use of inverse kinematics and to explore the implications of control and adaptation, performance, and scalability of such a system. This is an experimental project, where the data gathered comes from the simulation after implementation. The final product is a software application where a character, augmented by Inverse Kinematics, performs a procedural animation. The data is be collected at development time and runtime, and analyzed thereafter. PRODUCT AND DEVELOPMENT PROCESS The final product is a 3D simulation that displays an interactive character augmented by inverse kinematics and driven by either input or artificial intelligence. The 17 P age

25 system will be developed using C++ in Visual Studio 2010, and accompanied by a 3ds Max 2011 exporter also written in C++. Animations and character models will come from an artist or free, online libraries. The details of the inverse kinematics implementation are the most important parts of the system. The solution uses the Cyclic Coordinate Descent method outlined in Chapter 2 to drive the limbs of the character. An idle animation or pose will normalize the character after an action is played. The actions the character can perform are as follows: Stand in an idle position with feet grounded, regardless of the character s center of gravity Punch, using either arm, a location in space The inverse kinematics components are limb based, and in an effort to tweak the system, as an artist would generate animations, constraints and weights are used provide control over the motions generated. Constraints keep the character s limbs from rotating to unrealistic orientations, and weights allow control over how much each bone orients during each iteration of the algorithm. DATA COLLECTION AND PROCEDURES This is an experimental project. The data collected comes straight from the project and implementation specifics. Performance data is an analysis of the final algorithm s complexity and the burdens on memory (bytes of storage) and processing usage (frames per second). Control and Adaptation describes the number of variables that can be tweaked to modify the motion s behavior and an analysis of how the algorithm drives the animation. Scalability refers to how the system, based on performance, control, and 18 P age

26 adaptation, can be commercialized and used in a 3D engine on numerous skeletal makeups. Test Setting The setting takes place on an Alienware M17x personal computer wherever the simulation is run. It is an experimental project. Data Analysis System Specifications: CPU: Intel Core i5 M520 (4-core 2.4GHz) RAM: 4 Gigabytes Video: ATI Mobility Radeon HD 5800 Series Platform: Windows 7 Ultimate 64-bit Graphics API: DirectX 11 The three critical characteristics of the system to be reviewed are performance, control/adaptation, and scalability. Performance will be the easiest to measure. It will consist of a record on the frames per second and bytes of memory used by the system. This will show us how much of a burden inverse kinematics is on a normal 3D simulation. Control refers to the number of independent variables that an artist can change in an effort to tweak the procedural animation, and adaptation further describes how the algorithm drives the aesthetics of motion itself. This is a very difficult area to study, but it is the most important for inverse kinematic solutions when compared to traditional animation. Finally, scalability is an evaluation of the performance, and control/adaptation of the system itself. This evaluation will involve an examination of different parts of the implementation in an effort to determine its commercial possibilities and limitations if applied to characters of a larger or varied skeletal makeup. 19 P age

27 Specific data collected and analyzed: Performance o Process for generating an IK animation o Time (milliseconds) to calculate IK solution for one punch o Frames per Second of a system using traditional animations o Frames per Second of a system using IK enhanced animations o Bytes in memory to store IK enhanced animations Control o Visual differences in animations when various properties are manipulated o Control variables for artists versus programmers Scalability o Time (milliseconds) to generate animations for limbs of varying bone quantities o Number of tweakable properties per bone/animation available to an artist SUMMARY The final product of this project is a 3D simulation in which a character, augmented by inverse kinematics, performs a common fighting animation that is procedurally generated. This is an experimental project, and is used to analyze the performance, control and adaptability, and scalability of an inverse kinematic solution within 3D fighting games. Performance is measured in terms of memory and processing burdens. Control and adaptability refer to the variables and components of the algorithm that drive and modify the animation. Finally, scalability is the determination of how inverse kinematics will fit in a full 3D engine and on varying skeletons, based on the performance and control/adaptability implications. 20 P age

28 CHAPTER 4: RESULTS Simple key-frame animations often require characters to be in a particular state for the animation to play as intended. They use large amounts of data storage and development time. Inverse Kinematics solutions run in real-time and are used to fix-up animations in the industry. The question is whether they can be further used to drive animations entirely. The results presented in this chapter outline the performance, control/adaptability, and scalability of a small IK-driven animation system. Performance is measured through the system s burden on the processor, time it takes to generate an animation, etc. Control and adaptability explore all the ways that programmers and artists can manipulate procedural animations to produce a desirable outcome. This includes listing all the possible variables available and what happens when each one is tweaked. Scalability takes the performance and control statistics to determine the feasibility of a commercial procedural animation system with regard to different skeletons and limb structures. PERFORMANCE To measure any sort of performance of a system or algorithm, the steps in the algorithm should first be examined. Steps during skeleton segmentation (before runtime): 1. Skeleton limbs initialized 2. Skeleton bones added to limbs 21 P age

29 3. Degrees of freedom given to each bone 4. Animation spline defined Steps during IK animation generation (runtime): 1. For each animation spline a. Animation spline fixed up to environmental object(s) b. Spline evaluated at time (t) and sent to IK system with desired limb info c. IK system gets current bone orientations and stores them d. For each iteration desired i. For each current bone in the limb 1. Get the orientation from the current bone to the end effector 2. Get the orientation from the current bone to the goal 3. Compute the difference (quaternion multiply by the inverse) 4. Apply difference to current bone 5. Clamp each bone within its allowed Degrees of Freedom on the final iteration The steps before the animation is generated happen only once per character/animation and occur before the game is running. This happens in development time, which means we aren t really concerned about its performance. These steps are much more important later when we discuss the control and adaptability of the system. The steps that occur during animation generation can become very complex depending on the desired effect, IK implementation, and numbers of limbs and bones running at once. During the animation generation, we can see the driving loops of the system come from each animation spline (n) and each bone in the limb (m). Therefore the complexity of the system becomes O(n * m). We could have three separate splines to blend for one limb or 3 separate limbs. We could have one or more iterations in our IK loop, but that number will most likely remain constant based on the number of bones in the limb. There can also be any number of bones in a single IK chain. Games that use the system will 22 P age

30 most likely only run the algorithm on one to two limbs at a time with a few bones in each limb. It s time to look at actual numbers. There are a few ways to evaluate the performance of the system. The most important ways are looking at the burdens that the previously mentioned loops put on the game. Avg. Time (milliseconds) to Run IK Solution # Bones in IK Chain IK Iterations Table 1: Avg. Time to Run IK Solution Table 1 shows how the time to run the IK solution increases linearly based on the number of iterations and number of bones in the solution. However, it would be redundant to run multiple iterations on an IK chain that had only one bone. The system has an upper bound on the number of iterations equal to the number of bones in the IK chain. So one bone would have a maximum of one iteration, two iterations for two bones, etc, turning the chart into something more like Table 2. Avg. Time (milliseconds) to Run IK Solution # Bones IK Iterations Table 2: Avg. Time to Run IK Solution with Maximum Bounds 23 P age

31 The CCD solution runs quickly, but there are certainly ways the current implementation could be sped up. See chapter six for more about future improvements. The data required to simply store an IK enhanced animation is significantly different than traditional animations. Traditional animations, as explained in the Background section of Chapter One, store separate key frames within the animation and blend between them (or not if the resolution of the key frames is higher than the game s frame-rate). However, with this system, the key frames of the end effector are the only ones that need to be stored. This is further simplified by generating a spline that follows the key frames, rather than storing whole transformations at a time. A cubic spline is based on how many curves it contains. Each curve requires two end-points in 3D space, and two control points for Bezier curves, or two velocities for Hermite curves. That is a minimum of 4 points in space, and scales linearly by the number of curves. The reason to use splines instead of key frames for the end effector is not only to reduce memory footprint, but fixing up the end-point of the spline to fit the environment is much easier than fixing up every single key frame transformation. One Point in 3D space = 3 * size of float = 12 bytes One Curve = Four points in 3D space = 4 * 12 bytes = 48 bytes per curve vs. One Transformation = One translation in 3D space + a quaternion = 3 * size of float + 4 * size of float = 28 bytes Almost every animation requires more than 2 frames >= 56 bytes 24 P age

32 You can see that splines can describe the animation for a single bone much easier than a transformation. This is great for an end effector because the IK will handle the transformations for the other bones in the chain while the end effector simply follows the spline. As far as performance is concerned, Inverse Kinematics can greatly reduce the memory footprint on animations and runs quickly depending on the number of bones in each IK chain and the number of animations at one time. Of course, if an underlying animation is being played underneath, then at least we can say is that the IK system will not greatly hurt the performance of the game. CONTROL AND ADAPTABILITY The problem with Inverse Kinematics over traditional animations is the loss of control over the character. We simulate control by using splines to animate limbs of the character. However, not all bones lie in a given chain, some chains share bones, etc. The bones left over are inherently simulated or unaltered. Here we discuss the level of control that the system offers and see how the animation can adapt to the environment. The following properties represent variables that artists and/or programmers have control over when manipulating and defining how the system works in a given situation. Underlying animation Number of IK chains in a skeleton Which bones go in a chain (may skip intermediate bones) Spline Definition o Points on a spline o Which points transform relative to the skeleton o Which points transform relative to the target o Time to traverse the spline o Filter function for manipulating time step 25 P age

33 Weights of bones to IK chains Constraints on bones within a skeleton How the spline interacts with the environment Let us talk about the steps that are done before the game is run. These artistdriven steps can have very deep features programmed into them. For instance, defining an animation spline can be as simple as picking points in space for a single punch. Start and end are the easiest. However, when a character needs to punch another character, it is important to say which points in space are actually moved relative to the target character, and which remain constant in model space of the current character. The starting point of a punch is transformed relative to the character who is punching. They start the punch from the same position no matter what in space they intend to hit. The end-point, however, is moved to that location in space. The artist can decide how fast the spline should be evaluated, apply filter functions to the time interval, and more. The biggest problem at this stage is the lack of control over the animation. Artists cannot see exactly how the animation will play out, unless they have a tool that can run the same situation in which the system will be used. Given a viewer, artists may be able to determine if the solution will fail or succeed when constrained. But that doesn t necessarily give them any sort of control over the system. They would have to tweak the spline of the end effector in a way that would generate the desired look and feel. This lack of control over each bone in the chain means that a character can t reliably do things like elbow an enemy in the face, unless the elbow becomes the end effector. This is because there are multiple solutions from an IK solver (Figure 7). One solution to controlling the elbow is to have it linked to a constraint point, where it always 26 Page

34 attempts to bend in the direction of the constraint. This is what most 3D game engines do, such as Unreal Engine 3 and the CryEngine. Figure 9: Multiple IK Solutions Let us talk about the steps that happen during runtime. When controlling the system while the IK solver is running, we try to constrain the motion to its desired range. Human motion is very specific about its motion, and so the limits are clearly defined. As mentioned before, the system clamps Euler angles down to their min and max ranges for what each bone is capable. 27 P age

35 Figure 10: Unconstrained Inverse Kinematics You can see in Figure 8, that the end effector reaches its goal, but the unconstrained motion causes the character to look unnatural. Constraining the system is an important step in the IK solver. The system requires less iteration to reach its goal when unconstrained because the constraints tend to snap the end effector back away from the goal position. 28 P age

36 Figure 11: Constrained Inverse Kinematics Constraints actually cause the performance to go up much further because of the clamping and increase in IK solver iterations. More so, the constraints can hurt the solver even though they make sure the character stays within their limits of motion. In Figure 9, the chain on the right arm includes all the bones from the middle spine up to the hand end effector. The end effector fails to reach its goal because the system is relying on the spine to bend the character forward (Figure 8). However, if we shrink the chain to omit the spine and only use the arm bones, the end effector reaches its goal even though it is being constrained (Figure 10). Therefore, it is important to decide what the constraints are for the system and to know which bones are part of the IK chain. 29 P age

37 Figure 12: Shorter Constrained IK Chain Reaches the Goal There are probably better ways of constraining the system, which are mentioned in chapter five. The problem with clamping Euler angles is that when converting between a quaternion and Euler angles, it is difficult to know which angle is doing what. There are many ways of expressing a quaternion as a set of Euler angles because the order in which the rotations are applied matters. For example, you can express a quaternion as an XYZ rotation or a ZYX rotation. Both have the same result, but the values for each axis are quite different. This is what makes clamping Euler angles quite unpredictable and burdening. Instead, the quaternion itself needs to be constrained. When looking at the overall control of the system, we can effectively say that the desired goal for the end effector is easily controlled, but that the desired orientation of the bones within the chain is somewhat uncontrollable. There are small things like giving 30 Page

38 individual joints their own targets to achieve, or constraining the system to basic human motion. However, the more control expressed on the system, the less room the IK solver has to meet its goal. SCALABILITY The scalability of the system is based on its combined performance and control. We examine how the performance would scale on skeletons of different makeup. We want to know how the system would perform on a skeleton that has many different limbs or many bones in each limb, like a tail. This steps outside of human motion, but is important when considering a system for commercial purposes and use in many games. Looking at the performance of the system, we can see that it linearly increases based on the number of bones a chain and the number of IK chains running at the same time. The average skeleton will not need more than four bones in a single chain. Human motion has been predefined, and has been the basis for testing this system. When you look at other species or even alien species such as in Spore, things get a bit more complicated. The IK for those creatures tends to be small, maybe 3 bones in a single chain. However, some creatures have many arms and legs all working together. The performance of a single creature with six legs and two bones in each leg is very different from a single human with two arms and legs. It would be important to have many predefined splines for each type of limb and use them on the chains within that skeleton. If different skeletons can use the same splines even though they have different chains, then the memory footprint can be reduced. The algorithm itself would work best with fewer bones in each chain than fewer chains (see Table 1). This is because fewer bones 31 Page

39 require less iteration. Therefore, performance scales well, especially if there are very few bones in each chain. The control and adaptability of the system is a different matter. Adaptability of the system starts with the base IK solver, and ends with the constrained motion. The control of the system is all about the constrained motion. Therefore, we look at how the constraints scale with the system. An unconstrained system scales very well. We can expect the end effector to reach its goal and follow the spline animation closely. Unfortunately, the system gets into trouble as more constrained bones are added to the chain (see Figures 8 through 10). It is possible that other forms of constraint would make the system scale better with the number of bones in each chain, but it will likely affect the performance in a negative way. As the system stands control does not scale well when constrained, and therefore the adaptability of the system does not scale well. SUMMARY The system presented here is very fast at solving the inverse kinematics problem. The memory footprint for storing animations is small, and the system will perform quickly on the skeletons used in games. The end effector reaches its goal nearly every time in an unconstrained system, however it is not very practical in animation. Artists require finesse over their characters and need to see how they will look during runtime. It is important that tools to author end effector splines and visualize the IK solution are necessary when developing animations with this system. The IK solver at runtime will need to constrain the motion to the context of what the character should be able to do. These constraints hurt the adaptability of the system and pull end effectors 32 Page

40 away from their goals. Even if they do, it is unlikely that the desired pose will be the solution. Other forms of constraining the system are necessary for it to be effective in games. In a constrained system, there is little or no control over the rest of the bones in the animation. A secondary constraint can be placed for intermediate joints such as elbows or knees to reach for. These changes would greatly help the way that limbs interact with their environment and could potentially give the system a stable level of control without harming the performance. The system scales very well with performance, but as the system scales with more bones in an IK chain, the control hurts the adaptability even more. In the next chapter, we will look deeper into the limits of the system, discuss our words of wisdom when working with inverse kinematics, and talk about the future improvements and ways this system could better be implemented. 33 P age

41 CHAPTER 5: CONCLUSION Inverse kinematics offers a glimpse at a different way of animating characters in 3D games. Fighting games require tons of animations and interaction between characters and environments. Traditional animation can often be very rigid and repetitive in games that require a lot of interaction. With inverse kinematics, animations can further extend themselves to be more adaptable and lively. The system described in this thesis implements an inverse kinematic solution where the goal position follows an authored, but adaptable spline for the end effector to achieve. IK chains can have any number of bones in them, and the solution can iterate any number of times over these bones. The system performs very well with a small memory footprint and fast average times. However, when attempting to control the animations using constraints, adaptability is compromised and the animation tends to look less desirable as the number of bones in each chain increases. In this chapter we discuss the limitations of the system and provide words of wisdom that require attention when implementing a similar system or dealing at all with inverse kinematics. Finally, future improvements and research are outlined in this chapter. 34 P age

42 ARTIFACT LIMITS The limits of the artifact do not necessarily affect the performance, control, or scalability of the system. However, they do require attention and solutions to these limitations will be described in this chapter. The artifact itself relies on exported 3ds Max models and their makeup. 3ds Max has a built-in human skeleton format it calls a biped. The biped contains a certain number of limbs and bones in each limb, along with particular naming conventions for each. The system uses this biped format when extracting information about the skeleton and different limbs. It cannot segment skeletons on its own, and must be told which bones are in which limb, etc. When invoking the IK solver, the system takes the current spline and samples into it, then sends the new goal position to the solver for a given limb. It does not operate on multiple limbs at a time or aggregate orientations and blend between them. This would be useful if the spine was being pulled by two arms attempting to reach different goals. It is not a difficult task to achieve, but requires refactoring the system so that instead of applying the new orientations immediately, they are stored and blended at the end of the solver. One of the biggest limitations of the system is the method of constraining the motion. Currently, the solver takes a pre-authored set of min and max Euler angles to clamp each bone. This clamping is extremely unstable because converting a quaternion to Euler angles is virtually impossible without context, because it is unknown how that quaternion is oriented (XYZ rotation versus ZYX, etc.) A better way of constraining the 35 P age

43 system is by using the bone as a sort of line in space, a polygon window, and fixing up the quaternion so that the bone is aligned inside of the polygon. In doing this, it is unknown how performance will be affected. Another limitation is goal orientation. Currently the end effector simply attempts to reach the goal, but without a desired orientation. There are an unlimited number of examples of why you would want to orient the end effector. Perhaps the end effector is a hand and needs to align perfectly to a handlebar. Maybe the end effector is a foot and must rest flat on the ground. This is not a difficult task to do because in most cases the end effector can simply orient however we want without compromising the adaptability of the IK solution, but it is difficult to author with our spline animation definition. The final orientation would have to be relative to some object (the spline curve, target object, or character). WORDS OF WISDOM Cyclic Coordinate Descent algorithm is fast and not terribly hard to implement. What is difficult is getting the most out of it. There are a lot of things to consider when working with CCD, because it can be unstable and unpredictable at times. Beyond constraining the system, there are many things to take into consideration when implementing a solution. CCD iterates over the bones in the chain, applying a rotation such that the end effector is brought closer to the goal. What happens when the goal is between the current bone and the end effector? The iteration is wasted and does nothing because it can t rotate that bone to be any more useful to the end effector. Something that might help is a little bit of chaos. By knocking the current bone to the side, it is possible 36 Page

44 that later bones will rotate smoothly toward the end effector, instead of becoming a singularity, where multiple solutions seem possible. Therefore, try applying random rotations to a given bone (preferably one at the start of the chain) and letting future iterations solve the problem. Another thing to consider is the order in which bones are oriented. Start from the end effector or from the other end of the chain? Almost every implementation iterates from the end effector down through the other bones, because other bones may overshoot the end effector early on. By rotating the end effector first, singularities are pre-empted in some cases. This also creates a sort of pulling feel to the end effector. The reverse would create a more compressed feeling. The reason for using CCD in this system was to ensure that the IK solution attempted to keep the end effector on the goal. A Jacobian implementation would converge much slower on the goal, but if it s possible to minimize the scaling error, then this method might be better. That s because Jacobian methods are good at moving from one point to another rather than just trying to find a solution that works like CCD. Quaternions are elegant structures, and Euler angles are very sloppy when it comes to animation. Quaternions reduce the memory footprint of orientations, and become very fast to combine or operate on. Converting between quaternions and Euler angles is a difficult challenge because you have to know which way rotations are being applied in the quaternion. Euler angles can be expressed in many combinations and one must be careful when converting and clamping them. When faced with a challenge to use Euler angles, seek alternate approaches before doing so. 37 P age

45 Always think about what possibilities the system will need to deal with. Underlying animations are important in an IK system because individual limbs are independent of one another. If during a punch, we want the character s foot to tilt off the ground, an underlying animation needs to be played on it. Likewise, if the character needs to catch an opponent s fist in the air, then the IK will run on the arm, and the hand will grip in mid-air as an overlay, but not affect the IK solver. It is always good to try new things and see what works and what fails. FUTURE IMPROVEMENTS AND FURTHER RESEARCH There are tons of future improvements and various research topics to explore from this system. They include different tools to use when authoring animations and constraints, new constraint methods, and different ways of blending animations together. Different tools would convert to the system into a more commercialized product. Tools are necessary for artists to author animations and constrain the character. The following are just a few tool features that would make the system much more useful: Spline building for the end effector, and allowing artists to author them Different spline points adapt to the environment in different ways o Transform relative to the character o Transform relative to the spline curvature o Transform relative to the target/goal object Constraint editor so artists could author constraints for each bone o Polygon-Windows instead of Euler angles o Minimum is a single point in space o Maximum is a sphere Visualizer with IK solver running in real time as constraints and splines are authored 38 P age