Escuela Técnica Superior de Ingeniería Informática

Physics-Driven Character Animation

Memoria del Trabajo Fin de Grado Grado en Diseño y Desarrollo de Videojuegos

Autor: Aitor Iribar Etxezarreta

Tutores: Miguel A. Otaduy Mickeal Verschoor

Septiembre 2020 Acknowledgements

Gracias a Miguel A. Otaduy y a Mickeal Verschoor por ofrecerme vuestra ex- periencia cuando alcanzaba el límite de mis conocimientos matemáticos. Por obligarme a definir las fuerzas como muelles, y por tener paciencia durante me- ses de escribir esta memoria. Eskerrik asko, bihotzetik, ama eta aitari; azken urte hauek nire burua hobetzen pasatzeko aukeragatik, eta pozten nauen bidean zuen babesa emateagatik. Gracias, Elena, por todo tu apoyo emocional, y por cuánto me ayudaste a re- cuperarme. Gracias también a Codiguillos. Lo que empezó como un grupo para compartir apuntes se convirtió en algunas de mis amistades más preciadas.

1 Abstract Animation in videogames is traditionally implemented through key- frames. Keyframed animations are completely predefined, and lack the ability to react to forces and collisions. Ragdolls are often used when characters need to react to physics, but they can not be animated through keyframes, relegating the use of ragdolls to dead or unconscious characters only. This thesis proposes a method for animating ragdolls by calculating the necessary forces to match a keyframed animation. There exists tech- nology that achieves this, but most of it is proprietary, and little informa- tion on the subject is freely available. As well as proposing the Animation Matching method, the thesis details the development of Hairibar.Ragdoll, an implementation of the method for the Unity engine. This implement- ation is Free Open-Source Software, serving both as a tool and as an example. The Animation Matching method is designed to be intuitive and easy to use by non-technical animators. To this end, the thesis proposes a set of simple parameters to control the ragdoll’s behaviour. It is also designed in such a way that it acts as a post-processing layer that is compatible with any animation technology. The thesis evaluates the results via multiple benchmarks that simulate different use cases for the technology. Finally, it proposes several ways in which the method may be further extended.

2 Contents

1 Introduction 6 1.1 Context ...... 6 1.1.1 Keyframes ...... 6 1.1.2 Ragdolls ...... 7 1.2 Challenges ...... 7 1.3 Goals ...... 8 1.3.1 Functional goals ...... 8 1.3.2 Quality goals ...... 9 1.4 The thesis’s structure ...... 9

2 Related Work 11 2.1 Dynamic Motion Synthesis ...... 11 2.2 Authored Animation-based approach ...... 11 2.3 Active Ragdoll approach ...... 12

3 Animation Matching 14 3.1 Ragdoll simulation ...... 14 3.2 Pose definition ...... 15 3.2.1 Position ...... 15 3.2.2 Rotation ...... 16 3.3 Animation Matching forces ...... 17 3.3.1 Position Matching ...... 17 3.3.2 Rotation Matching ...... 18 3.4 Parameters ...... 19 3.4.1 Stiffness parameter ...... 19 3.4.2 Damping parameter ...... 21 3.4.3 Conclusion ...... 22 3.5 Power Profiles ...... 22 3.6 Collisions ...... 23

4 Implementation 24 4.1 Used technology ...... 24 4.1.1 Unity ...... 24 4.1.2 PhysX ...... 25 4.1.3 Ragdoll setup ...... 26 4.2 Event timeline ...... 29

3 4.2.1 The update loop ...... 29 4.2.2 The physics loop ...... 30 4.3 Architecture ...... 34 4.4 Core module ...... 34 4.4.1 Ragdoll profiles ...... 34 4.4.2 Ragdoll definitions ...... 36 4.4.3 Ragdoll settings ...... 42 4.4.4 Collision Ignorance ...... 46 4.4.5 Debug Tools ...... 47 4.5 Animation module ...... 48 4.5.1 Ragdoll animator ...... 49 4.5.2 Animation profiles ...... 50 4.5.3 Mecanim integration ...... 52 4.5.4 Collision reaction ...... 52 4.5.5 Power on transitioner ...... 53 4.5.6 Animated ragdoll wizard ...... 53 4.6 Extensibility ...... 54 4.6.1 IBoneProfileModifier ...... 54 4.6.2 ITargetPoseModifier ...... 55 4.6.3 Custom ragdoll profiles ...... 55

5 Tools & Methodology 56 5.1 Tools ...... 56 5.1.1 Microsoft Visual Studio ...... 56 5.1.2 Git ...... 56 5.1.3 HacknPlan ...... 56 5.2 Methodology ...... 57 5.2.1 Introduction to Kanban and HacknPlan ...... 57 5.2.2 Introduction to Git-flow ...... 57 5.2.3 Development workflow ...... 58 5.2.4 Data ...... 59

6 Results & Benchmarks 60 6.1 Benchmarks ...... 60 6.1.1 Basic Locomotion ...... 60 6.1.2 Colliding with Walls ...... 65 6.1.3 Walking Under an Obstacle ...... 66 6.1.4 Shooting Balls ...... 66

4 6.1.5 Hanging ...... 67 6.1.6 Climbing ...... 68 6.1.7 High Acceleration ...... 69 6.1.8 Local Space Waving ...... 69 6.2 Failed experiments ...... 70 6.2.1 Velocity Gain parameter ...... 71 6.2.2 Position Matching through Spring Joints ...... 71 6.2.3 Collision Give ...... 71 6.2.4 Maximum acceleration ...... 72

7 Conclusions 73 7.1 Realised goals ...... 73 7.1.1 Functional goals ...... 73 7.1.2 Quality goals ...... 73 7.2 Future work ...... 74 7.2.1 2D Support ...... 74 7.2.2 Better animation limiting ...... 74 7.2.3 Bone scaling and stretching support ...... 74 7.2.4 Dynamic adjustment of joint limits ...... 75 7.2.5 Support for omitting intermediate bones ...... 75 7.3 Closing ...... 76

References 77

5 1 Introduction

Z = 1 Z = 0.3

1.1 Context

To understand the method proposed in this thesis, and why it may prove be- neficial, it is important to understand the individual elements that it combines. This section will explain, at a high level, what keyframed animations and rag- dolls are.

1.1.1 Keyframes

Traditional animation in videogames works via keyframes. A keyframe defines a position and rotation for every part of the character that can move (referred to as bones). See figure (1) for an example of the keyframes an animation may have.

Figure 1: The different keyframes that may be defined for a typical jump anim- ation. Image from The Animator’s Survival Kit.

To play a keyframed animation, each bone is positioned and rotated as described in the animation. They do not snap from keyframe to keyframe, though. For a given moment between keyframes, the positions and rotations defined in both keyframes are interpolated between, resulting in a new pose that is in between the two keyframes. This interpolation is visualised in figure (2). Keyframed animations are fixed - they can not react to the environment. The bones are simply moved to wherever the animation says, with no regard to collisions or forces that may be acting on the character.

6 Figure 2: Animators can control the interpolation between keyframes by editing curves. The square icons represent keyframes, while the lines represent the values that will be used for any given moment.

1.1.2 Ragdolls

Many games feature characters that die. When a character dies, a keyframed death animation is often too static. If the character dies on a staircase, one would expect it to slide down the stairs and lie diagonally. Keyframed anima- tions lack the ability to adapt to the environment in this way. To achieve better results, it is common to switch the character to a ragdoll upon death. Game engines offer the ability to move objects via a physics simulation. Moreover, these objects can be attached to each other via joints. Joints can limit the ways in which the two attached objects can move; limiting their relative position and rotation. A ragdoll simulates the character bones as physics objects with joints that prevent movements that the human body can not perform. Ragdolls allow characters to become a dead weight and be animated by a physics simulation upon death instead of playing a static death animation. Ragdolls re- spect gravity and collisions, achieving much more dynamic and adaptive results. An example can be seen in figure (3).

1.2 Challenges

Keyframed animations could potentially be greatly improved by the dynamic properties of ragdoll simulation. However, keyframes and ragdolls are funda- mentally incompatible. As keyframed animations directly move the bones to a predefined position, they can not be affected by a ragdoll simulation. Any movement caused by the simulation is overwritten by the animation. Furthermore, physics engines are not designed to handle objects that instantly move. Instantaneous movements can introduce extremely high forces to the sim- ulation, making it unstable. They can also break joints, sometimes irreversibly.

7 Figure 3: A dead character being simulated as a ragdoll. Left: what the char- acter looks like in the game. Right: what the physics engine is simulating.

Objects could even be moved to inside a wall, resulting in the physics engine attempting to solve an impossible problem.

1.3 Goals

The aim of this thesis is to propose and develop a system that enhances key- framed animations with the physical properties of ragdolls. This includes sec- ondary motion, collisions and reactions to forces. Multiple development efforts have achieved this previously, as described in sec- tion (2.2). However, none of them are freely available. Most of them are pro- prietary technology, and information about them is sparse. The system developed in this thesis will be Free Open-Source Software, and will be developed as an extension to the Unity engine, offering a free, ready- made solution for millions of users. Additionally, the proposed method will be applicable to any engine capable of physics simulation. At a high level, the system will work by always simulating the character as a ragdoll, even while playing animations. To play animations, bones will not be instantly positioned. Instead, a series of forces will be applied to the ragdoll such that, if unimpeded, the ragdoll will appear to play the animation. If the animation results in an impossible pose, e.g. if a hand would go through a wall, the ragdoll simulation will prevent it, the hand colliding against the wall instead. The system should have the following properties:

1.3.1 Functional goals

• In the absence of contact, and with appropriate parameters set, the char- acter must be able to move almost identically to the keyframed animation.

8 • The resulting motion must be adjustable via parameters. Adjusting these parameters must gradually introduce more secondary motion and allow more deviation from the keyframed animation. • The character must be able to imitate the keyframed pose in local space, regardless of orientation.

• Under collision, the character must react accordingly. It must not penet- rate any colliders, and the pose must be kept as intact as possible in the process.

1.3.2 Quality goals

• The system must be easy to use by non-technical animators. An animator with limited technical knowledge must be able to tweak parameters to achieve their desired look without any external help. To ensure this, any exposed parameters should a have single, clearly understandable effect. • The system must be transparent. It should not require a significant change in neither the animation pipeline nor the code of the game that uses it. • The system must be compatible with any other animation technology, within reason.

1.4 The thesis’s structure

The following chapter, 2: Related Work, will introduce the varying approaches that have been used in the past to animate ragdolls. Section 2.2: Authored Animation-based approach is of particular interest, as it presents the existing work done in the particular approach that the method proposed in this thesis uses. Chapter 3: Animation Matching will describe the proposed method in full detail. This description is technology-agnostic, serving as a theoretical framework that could be implemented in any environment. It also goes beyond the formulas that compute the necessary forces, proposing a set of artist-friendly parameters and multiple techniques to deal with collisions. An implementation of the Animation Matching method was developed for the Unity engine, a free, open-source package called ‘Hairibar.Ragdoll’. Unity was chosen over alternatives such as Epic Games’ Unreal Engine 4 and the open- source Godot due to two main factors: its large user-base and the author’s prior experience. The package will be discussed in chapter 4: Implementation, serving both as a user manual and as an example of the Animation Matching method put into practice. It is developed in such a way that it is implicitly compatible with any animation technology. It also includes a Mecanim integration and a ragdoll setup wizard among other features.

9 The development process will then be described in chapter 5: Tools & Meth- odology, introducing the tools and processes that were used and offering time- tracking data. This description will be expanded upon in chapter 6: Results & Benchmarks, giving concrete examples of the iteration and testing processes. Finally, a conclusion will be presented in chapter 7.

10 2 Related Work

The notion of animating characters via physics is not new. Multiple approaches have been used in different games. This chapter will introduce each approach along with their advantages and disadvantages. It will also outline how they have been used in the videogames industry.

2.1 Dynamic Motion Synthesis

Euphoria is a proprietary technology developed by NaturalMotion that uses Dynamic Motion Synthesis[1] to generate character animation on the fly. It was most famously used in the Grand Theft Auto franchise. Other titles include Star Wars: The Force Unleashed, as well as multiple other games by Rockstar Games[2]. Euphoria simulates the character’s motor nervous system, relying heavily on research in the fields of robotics and biology. Typical use involves using standard keyframed animations until a certain behaviour, such as stumbling, is desired. At that point, control of the character animation is handed to Euphoria, which generates realistic stumbling motion. While the results are realistic, very little artistic control over the animation is afforded, making it impossible to convey personality through these behaviours. Because it is intertwined with the character’s AI, NaturalMotion did not directly license Euphoria. Instead, it offered a co-development relationship where a team of NaturalMotion engineers were assigned full-time to integrate Euphoria into the client’s project[3]. The lack of artistic control and the extreme expense of hiring an additional engineering department prevented Euphoria from enjoying widespread adoption. NaturalMotion stopped licensing the technology in 2017[4].

2.2 Authored Animation-based approach

Authored animation-based solutions use traditional keyframed animations as inputs to a system. The system then manipulates a ragdoll, driving it towards the input pose instead of directly setting it to a dictated pose. Different para- meters may influence the way in which the ragdoll moves, or even how the pose is interpreted. The Animation Matching method proposed in this thesis (described in chapter 3) classifies as an Authored Animation-based approach. This approach holds the advantage that it is an extension to the existing animation pipeline. Animators create the animations with the tools and processes they already know, and are not required to significantly change their workflow. Instead, they must understand how the system will use their animation, and how the system can be tweaked to achieve the desired result.

11 There exists no industry-standard solution for this approach. Thus, it is most often used by large, well-funded teams that can afford to build the necessary technology. It has been used in games such as Naughty Dog’s Uncharted 4[6] and multiple games by EA made in the Frostbite Engine, including among others the FIFA and UFC franchises[7]. The approach can be used to different degrees. In FIFA, the physics behaviour can only be appreciated at specific moments, such as when a player is hit by an opponent. In Uncharted 4, on the other hand, the ragdoll simulation is done during gen- eral locomotion as well. In it, the system is tuned in such a way that some subtle secondary motion is achieved through physics. The simulation is also taken advantage of to transition between animations with better continuity, as illustrated in figure (4).

Figure 4: An illustration of the subtly improved continuity achieved in Un- charted 4 via a keyframe-based approach to physics-driven character animation. The red line shows the movement of the hip. The left side is keyframed anim- ation, while the right side is the resulting physics-driven animation. Note the smoothness of the turns and how momentum is kept. Image from a publicly available GDC talk[6].

2.3 Active Ragdoll approach

A third approach to physics-driven character animation is what is commonly referred to as Active Ragdoll. Instead of developing a system that computes the appropriate forces to play an animation, the process is done from the bottom

12 up: a series of forces are directly designed and applied to the ragdoll, with no target pose in the system. This requires a complex system of different forces with different functions. For example: in Totally Accurate Battle Simulator[8] (see figure 5), characters are kept standing up by upward forces at their torso and head. These forces are only active while the character is standing on the ground. The closer the head is to the ground, the stronger these forces are. An illusion of the character balancing on their feet is achieved by keeping the middle point between their feet aligned with the character’s centre of mass. Totally Accurate Battle Simulator features many other forces that drive the different actions characters that can perform in the game: walking, swinging swords, operating a crossbow etc.

Figure 5: A screenshot from Landfall Games’ Totally Accurate Battle Simulator. Note the uniquely unnatural poses created by the Active Ragdoll approach.

The result of this approach is neither realistic, natural nor subtle. The motion has an aesthetic of its own, more akin to a puppet. It is mainly seen in physics- based games by small teams, often in an experimental setting. Games like Totally Accurate Battle Simulator and Gang Beasts[9] are built entirely around this style of animation.

13 3 Animation Matching

This thesis proposes a method for animating ragdolls with keyframed anima- tions. This method works by reading animation data and applying appropriate forces to the character’s limbs. This process is referred to as Animation Match- ing. This chapter will introduce the different forces that influence the ragdoll. Next, it will explain how the animation data is read. Then, it will describe how the forces that drive the animation are calculated and applied, and how these forces can be tweaked to achieve different behaviours. It will then show how these behaviours can be further modified via Power Profiles. Finally, two considerations regarding collisions will be presented.

3.1 Ragdoll simulation

A ragdoll models the character as an articulated body. Each bone in the char- acter’s rig is modelled as a rigid body. These bodies are referred to as ragdoll bones. The dynamics of a ragdoll bone are governed by the Newton-Euler equations. The translational dynamics are given by −→ 3 E 1 Õ−→ = · z 3C < 8 (1) 8 −→ 3 E E C < where 3C is the derivative of the bone’s velocity over time , is the bone’s Í−→ mass, and z8 is the sum of all forces being applied to the bone. 8 The rotational dynamics are given by

−→ ! 3 l Õ   = "−1 · −→g − −→l × " · −→l 3C 8 (2) 8 −→ 3l −→l " where 3C is the derivative of the bone’s angular velocity over time, is the Í−→ bone’s inertia tensor, and g8 is the sum of all torques being applied to the 8 bone. These are the sources of the forces and torques that act upon the ragdoll bones:

• Gravity • Joint forces • Joint limits

• Collisions

14 • Animation Matching • External forces and torques, such as those that may be triggered by game- play code

Animation Matching forces are the focus of this thesis. They are computed and applied in such a way that the ragdoll matches the keyframed animation, while still respecting all other forces. The rest of this chapter will describe this process in further detail.

3.2 Pose definition

A pose holds the following properties of a bone at a moment in time: −→ • World-space position: ? −→ • World-space linear velocity: E

• Local-space rotation: ' −→ • Local-space angular velocity: l

The target pose of a bone is the pose described by the animation to be matched. Animations are matched by applying appropriate forces to the ragdoll bones so that they match their target pose. As keyframed animations do not define velocities, they must be estimated using finite differences. −→ −−−→ −→ ?C − ?C−1 E = (3) C ΔC

0=6;4 0G8B ') '
−→ C−1 · C l = (4) C ΔC where C is a discrete moment in time, and ΔC is the time elapsed since the previous moment C − 1. Poses are divided into two components, position and rotation. These compon- ents are matched separately. While forces for both are calculated in a similar manner, there is a key difference: position is matched in world space, while rotation is matched in local space.

3.2.1 Position

Matching position is done in world space. This allows the ragdoll to follow the character when the movement does not come from the animation being played, but, for example, from player input.

15 3.2.2 Rotation

For a given ragdoll bone, rotation is matched in the local space of the parent of its corresponding bone in the animation. This means that the bone’s rotation will be defined relative to its parent, not in absolute terms. Bones are attached to each other with joints. Forces are applied such that the joint’s rotation matches the target rotation, keeping the relative rotation between parent and child the same as in the target pose. This is visualised in figure (6).

' ' ' ' ') ' 2ℎ8;3 = ?0A4=C · 9>8=C → 9>8=C = ?0A4=C · 2ℎ8;3 (5)

Figure 6: Representation of a bone’s local space.

Matching rotation in local space allows the ragdoll to play animations correctly regardless of orientation. For example, a character can play a waving animation with their right hand while lying on the ground, even though the animation is made for a character that is standing up (see figure (7)).

16 Figure 7: Two characters playing the same waving animation. The character in the left shows the target pose. The character in the right is a ragdoll with only Rotation Matching enabled, matching the animation in local space.

3.3 Animation Matching forces

Every physics step, each ragdoll bone has two kinds of forces applied to it - linear for Position Matching, and rotational for Rotation Matching. These forces drive the ragdoll bone towards the target pose. Both are determined by simulating a spring between the bone’s current pose and its target pose. This section will explain the particulars of how these forces are calculated.

3.3.1 Position Matching

Each bone has one linear force applied to it for Position Matching. This force is obtained by simulating a spring between the ragdoll bone’s current pose and its target pose. The resulting force is −→ −→ −→ z = −: · Δ? − 3 · ΔE (6) where : is the spring constant, 3 is the damping coefficient,

−→ −−−−−→ −−−−−→ Δ? = ?A063>;; − ?C0A64C (7) and

17 −→ −−−−−→ −−−−→ ΔE = EA063>;; − EC0A64C (8)

It is worth noting that damping is done relative to the animation, and not absolute velocity.

3.3.2 Rotation Matching

Rotation Matching forces are simulated as rotational springs on the local ori- entations of ragdoll bones. A bone may have multiple Rotation Matching forces applied to it. A single torque is calculated for each bone. This torque is applied at the joint at the bone’s origin point. This results in the torque being transferred to both bones connected by the joint. The calculation for the torque in local space is similar to the one in Position Matching:

−−−→ −−→ g;>20; = −: · 0=6;4 0G8B (Δ') − 3 · Δl (9) where Δ' is the rotation from the target local rotation to the ragdoll bone’s current local rotation, and

−−→ −−−−−−→ −−−−−→ Δl = lA063>;; − lC0A64C (10)

Δ' can be obtained as such:

' ' ' ' ' ') A063>;; = Δ · C0A64C → Δ = A063>;; · C0A64C (11)

Before being applied to the two bones connected by the joint, the torque must be converted to world space:

−−−−→ −−−→ gF>A;3 = '?0A4=C · g;>20; (12)

Finally, the torque is applied to the bone and its parent.

−−−→ −−−−→ g2ℎ8;3 = gF>A;3 (13)

−−−−−→ −−−−→ g?0A4=C = −gF>A;3 (14)

18 3.4 Parameters

The springs that are simulated for Animation Matching forces have two para- meters:

• :: the spring constant. Defines the stiffness of the spring. • 3: the damping coefficient. Defines the amount of damping.

These parameters, as expressed in equations (6) and (9), are deemed unsuitable for multiple reasons:

• They are difficult to tweak manually, requiring numerical analysis to find the values that will achieve the desired behaviour. • They use non-intuitive units of measurement. • They are dependent on the mass of the attached bodies, meaning that making a ragdoll heavier would require the right values to be found and set again. • The amount of oscillation damped by a given 3 value depends on the value :. This means that making a spring stiffer would necessitate a new 3 value.

As a consequence, a re-parametrisation is proposed. : is substituted by the stiffness parameter U, and 3 is substituted by the damping parameter Z . Both operate in the range [0, 1], are mass-independent, and do not depend on each other. Unlike : and 3, they describe the desired motion instead of the forces that achieve it. This makes them far more suitable for animators.

3.4.1 Stiffness parameter

The stiffness parameter U determines how quickly a ragdoll bone will reach its target pose. The actual stiffness : is computed from U as: < · U : = (15) ΔC 2 where m is the ragdoll bone’s mass and ∆t is the size of a physics simulation step. On each step of the physics simulation, a ragdoll bone will have forces applied to it such that, if no other forces acted upon it, it will move a fraction of U of −→ the way towards the target pose. The positi0n change ΔG in a single step is given by −→  −→ ΔG = −Δ? · U (16) −→ where ΔG is the position change in a single step.

19 A derivation of U is provided next: Ignoring damping, the acceleration due to the Animation Matching force can be computed as: −→  −→ z = : · −Δ? (17) −→  −→ 0 · < = : · −Δ? (18)

:  −→ −→0 = · − ? < Δ (19) −→ Integrated using Euler’s method, the velocity gained in a single step ΔE is ob- tained.

−→ −→ ΔE = ΔC · 0 (20)

−→ :  −→ E = C · · − ? Δ Δ < Δ (21) −→ Integrating again, the position change in a single step ΔG is obtained: −→ −→ ΔG = ΔC · ΔE (22)

−→ :  −→ G = C 2 · · − ? Δ Δ < Δ (23)

The change in position is expressed as a fraction of U of the current pose dis- placement: −→  −→ ΔG = −Δ? · U (24)

By substituting the change in position as a function of the stiffness :, the ex- pression that relates : to the desired fraction alpha is obtained.

 −→ :  −→ − ? · U = C 2 · · − ? Δ Δ < Δ (25)

: U = C 2 · Δ < (26)

< · U : = (27) ΔC 2

20 When U = 0,the ragdoll bone will never reach the target pose (no forces will be applied). When U = 1, it will reach the target pose in a single step of the physics simulation. While this is true in an isolated environment, the bone tends to overshoot the target in real use cases, as other bones will pull on it. From an animator’s point of view, it is best to think of U as a tightness setting. U = 1 means the ragdoll will follow the animation perfectly. Lowering U will make the Animation Matching increasingly loose, making the physics behaviour more apparent. It is worth noting that most of the expressive range of U lies in low values. The higher U is, the less visually distinct the behaviour becomes.

3.4.2 Damping parameter

As a substitute for the damping coefficient 3, the spring’s damping ratio Z is proposed. The damping ratio is the fraction between the damping coefficient 3 and the critical damping:

3 Z = 2A8C820; 30

• A system where Z = 0 is said to be undamped, meaning there is no damping and the oscillations do not stop. • A system with Z < 1 is said to be underdamped, meaning the system will eventually come to a rest, but it will oscillate first. • A system with Z = 1 is said to be critically damped, meaning the system will come to a rest in the shortest possible time without any oscillation. • A system with Z > 1 is said to be overdamped, meaning the system will come to a rest without any oscillations, but it will be unnecessarily slow on its way there. For the purposes of Physics-Driven Character Anim- ation, overdamped systems are not recommended, as the slowness looks unnatural. Therefore, the proposed range for Z is [0, 1].

21 3.4.3 Conclusion

Both U and Z can be individually defined for each spring of each ragdoll bone, therefore a single ragdoll bone has four parameters:

• Position Matching U

• Position Matching Z • Rotation Matching U • Rotation Matching Z

Having high values for both parameters of a spring can lead to numerical in- stability. As a general rule of thumb, it is recommended that for a single spring, U + Z < 1.6. As high values of U are visually similar, U can, in most cases, be lowered to increase stability without noticeable impact on the resulting anima- tion.

3.5 Power Profiles

A ragdoll bone can be in one of three power states.

Unpowered: the ragdoll bone is simulated as a rigid body, but no Animation Matching forces are applied. Powered: the ragdoll bone is simulated as a rigid body, and Animation Match- ing forces are applied.

Kinematic: the ragdoll bone is not simulated as a rigid body, moving directly to the target pose instead.

Switching Power Profiles allows Animation Matching to be effectively disabled in certain situations. A character might, for example, be switched to unpowered when it dies, while a hand-animated cutscene might require the characters to be kinematic. It is useful to tie different Power Profiles to different animation states. A Power Profile may have bones in varying power states. Making specific bones kinematic is particularly useful. For a running animation, it often makes sense for the feet to be kinematic so that they do not get stuck on irregular terrain. In an IK setup, making the hand kinematic will guarantee that it is placed exactly where it needs to be. In a climbing setup, kinematic hands and feet make the character believably hang onto the wall under external forces.

22 3.6 Collisions

When there is a collider between the ragdoll bone and the target bone, the ragdoll bone will respect the collider and will not penetrate it. However, Position Matching forces will still be applied to it, which can make the bone vibrate against the collider with a high enough Position Matching U. This problem can be fixed by temporarily lowering the Position Matching U while the bone is colliding. Once it is no longer colliding, the Position Matching U can be returned to its original value. For better results, the value can be slowly ramped up instead of instantly being set to the original value. Certain animations may inevitably cause collisions. As powered ragdoll bones respect colliders, these animations will play incorrectly. The solution to this problem is to selectively ignore collisions. These inevitable collisions can be divided into two cases, each with a specific solution.

1. Collision between two ragdoll bones: an animation might involve the char- acter putting their right hand into their pocket. A standard ragdoll setup would not allow this to happen. This situation can be solved by selectively ignoring collisions between the right hand and the right thigh. 2. Collisions between a ragdoll bone and an external collider: a climbing character may need to have their hands positioned extremely close to a wall. As a ragdoll’s colliders are usually a crude approximation of the body’s shape, this may result in the hand visually hovering at a distance from the wall while the ragdoll actually collides with it. The solution for this case is to disable collisions for the hand, allowing it to penetrate the wall if necessary.

Similarly to Power Profiles, it is useful to tie these collision ignorance settings to specific animation states, so that each animation can ignore only the collisions it needs to.

23 4 Implementation

The method proposed in chapter (3) has been implemented as a package for the Unity engine. It is distributed as a package for the Unity Package Manager (UPM), under the name ‘Hairibar.Ragdoll’. It is Free and Open-Source Software (FOSS), released under the MIT license. The code is hosted on a public GitHub repository[5]. The aim of this chapter is to describe the package and its features, and to serve an example of the Physics-Driven Character Animation method put into practice. The technology used by the package will first be introduced, followed by two sections that will outline how Animation Matching has been implemented in a way that has as little architectural impact on the game that uses it as possible. The package’s architecture will then be explained, and the main features of the two modules that comprise the package will be described. Finally, the extensibility and customisability of the package will be discussed.

4.1 Used technology

The package has been developed in Unity[10], which uses PhysX[11] as a physics engine. To understand the implementation, it is important to have some basic familiarity with both Unity and PhysX. This section will briefly introduce both of them.

4.1.1 Unity

Unity is a cross-platform game engine developed by Unity Technologies. The following is its basic architecture: A Scene contains a set of GameObjects. GameObjects have no behaviour on their own. Instead, they contain a set of Components.A Component is a C# class that can be attached to any GameObject to give it some behaviour. Components are developed as modular pieces that can be mixed and matched to achieve different behaviours. All GameObjects have a Transform component that holds the GameObject’s position, rotation and scale. A GameObject can be another GameObject’s child. In that case, the values in the child’s Transform are defined in local space, that is, relative to its parent. A Unity project has an Assets directory. Any file inside this directory is referred to as an Asset. Assets can range from textures and shaders to configuration files called ScriptableObjects. Unity features a window called the Inspector (see figure 8). Assets, GameOb- jects and their Components can expose configuration values that are shown in the Inspector when they are selected. Simple value types are automatically

24 supported by the Inspector. When an object type requires a more complex Inspector, a bespoke one can be programmed.

Figure 8: An example of the Inspector. The selected GameObject, named ‘R_- Hand’, has three components: Transform, Animator and IKFollow. Note how IKFollow shows a default inspector, while Animator has a bespoke one that adds a message box.

4.1.2 PhysX

Unity has a physics engine integrated into it: PhysX. Developed by Nvidia, PhysX is an open-source realtime physics engine designed for use in video- games. It is a middleware, meaning that it is developed with the intention that developers integrate it into their game engines, making wrappers for PhysX’s features.

25 Due to the sheer size of PhysX, only the features relevant to this project will be introduced. PhysX can simulate rigid bodies with position, orientation, velocity etc. They have a shape that is used for collisions. Their shape can not be deformed. In Unity, a GameObject can be simulated as a rigid body by adding a Rigidbody component to it. Its shape can be defined by adding Collider components. A rigid body is dynamic by default, meaning that it will be simulated. Forces will affect its velocity, it will collide with other bodies, and other dynamic bodies will collide with it. However, it can be made kinematic.A kinematic rigid body ignores the simulation, always moving to its target position and rotation instead. Forces do not affect its velocity, and it does not collide with other bodies. Other dynamic bodies do, however, collide with it. In these collisions, the kinematic rigid body acts as though it had infinite mass. Unity exposes this functionality as a simple isKinematic boolean value. Finally, two rigid bodies can be attached to each other through a joint. A joint defines a set of constraints on how the attached bodies can move. These restrictions are enforced by applying forces to counteract violations. There are several types of joints, varying in the degrees of freedom they allow. For this project, only the D6 joint has been used. The D6 joint is a highly configurable joint type that allows specific degrees of freedom to be either com- pletely locked, completely unlocked, or partially locked (specifying a range in- side which motion is allowed). The D6 joint can be accessed in Unity via the ConfigurableJoint. The ConfigurableJoint is a component that can be attached to any GameO- bject with a Rigidbody. A second Rigidbody can then be attached to the ConfigurableJoint by setting its connectedBody property. The D6 joint also allows a target position and/or rotation to be set. A spring can then be configured to drive the joint towards the target position or rotation. Unity exposes this functionality via JointDrive properties. In this project, ragdolls are composed of a set of Rigidbodies representing different parts of the body. Adjacent parts are connected to each other via Con- figurableJoints. The characteristics of their simulation are given in section (3.1). As described in section (3), position and rotation are matched separately. Position Matching forces (section 3.3.1) are directly applied to the Rigidbod- ies, while Rotation Matching forces (section 3.3.2) are applied through the ConfigurableJoints’ springs.

4.1.3 Ragdoll setup

In this implementation, two different versions of the character are used: the target and the ragdoll. The target is what is commonly used in games for characters that are not ragdolls. It has a set of bones that any animation system can manipulate. It should be noted that, in Unity, these bones can optionally be exposed as GameObjects. This is required by the implementation.

26 The target also has some way of rendering the character, typically via a skinned mesh. The target does not have any physics-related components. The ragdoll, in turn, does not have any visual representation on its own. It is a copy of the target’s bone hierarchy, where every bone has a Rigidbody and a ConfigurableJoint, an where these joints have their GameObject’s parent’s Rigidbody as a connectedBody. Ragdoll bones typically have Colliders as well, though this is not technically required. The limits and degrees of freedom of the ConfigurableJoint do not have any particular requirements either. They should be set according to the needs of the particular characters that the ragdoll will represent. The Animation Matching method (described in detail in chapter 3) is applied to the ragdoll, using the target as the source of the target pose (defined in 3.2). The ragdoll is then visualised by manipulating the target bones, setting them to their ragdoll counterparts’ poses. This process is explained in further detail in section (4.2). This allows the rest of the game to be uncoupled from the ragdoll. The Physics-Driven Character Animation is effectively applied as a post processing layer to the existing character animation, and the client code need not even be aware of the existence of the ragdoll. The ragdoll’s bone hierarchy starts as identical to that of the target. However, it is sometimes desirable to omit certain bones in the ragdoll, be it for the sake of simplicity or performance. The system allows any target bone to be omitted as long as all of its children are omitted too. The target counterparts of omitted bones are never touched by the system, allowing them to play the animation in local space without any physics behaviour. Figure (9) shows an example of the resulting hierarchy of this setup. Additionally, three components that are part of this project are required: the ragdoll must have a RagdollDefinitionBindings and a RagdollSettings, while the target needs a RagdollAnimator. These components will be explained in sections (4.4.2), (4.4.3) and (4.5.1). The target will typically also have an Animator component, which is part of Unity’s standard animation system, Mecanim[12]. However, the package is animation-system-agnostic, meaning that will work with any animation system. As all of this can be complex to set up, the AnimatedRagdollWizard is provided. This wizard automates part of the setup process, and guides the user through the manual steps. This wizard is described further in section (4.5.6).

27 Figure 9: An example of a setup with a target and a ragdoll. An arrow pointing right indicates that the object has children that are hidden. Note how the meshes are only present in the target. Also note how the fingers have been omitted from the ragdoll.

28 4.2 Event timeline

There are two different loops to understand in Unity: the loop that happens for every frame (referred to in this thesis as the update loop), and the loop that happens for every step of the physics simulation (referred to in this thesis as the physics loop). The implementation operates on both. An abridged overview of the actions taken in these loops is provided in figure (10).

Figure 10: An abridged overview of the timeline of the different operations involved in Animation Matching.

4.2.1 The update loop

For every frame that Unity renders, several steps are taken at a certain order. A complete diagram from Unity’s official documentation is pictured in figure (11). The first step to understand is the Update event. At this step, any currently active component with an Update() method has said method called. This is where most game logic is simulated.

29 After the Update event, Unity performs an internal animation update. Unity’s standard animation system, Mecanim, computes the position and rotation that each target bone should have according to the animation. Multiple animation- related events are called at this point, including OnAnimatorMove and OnAnim- atorIK, where the obtained positions and rotations can potentially be modified. After these events, Mecanim modifies the Transforms of the target bones to re- flect the result of the animation update. Once the animation update is finished, the LateUpdate event is called. This event works identically to Update, except for the time at which it is called. It is intended to be used for behaviours that must happen once all game logic has been simulated. In LateUpdate(), RagdollAnimator first reads the pose (defined in section 3.2) of each target bone. These poses become the new target poses for the ragdoll bones. Then, the target bones are moved and rotated to the pose of their ragdoll counterparts. It is worth noting that, because of the way the target poses are read, there is no dependency on Mecanim or any other animation system. This implementation is implicitly compatible with any animation system that:

1. Modifies the target bones’ Transforms before every LateUpdate. 2. Does not require the target bones not to have moved since the last anim- ation update.

When the target is rendered, the target bones are at the exact same position and rotation as the ragdoll bones. This makes it seem like the ragdoll is the character being rendered. It should be noted that the Animator component’s ‘Animate Physics’ mode is not supported. This mode runs the internal animation update after FixedUp- date instead of between Update and LateUpdate. It is intended to animate objects with colliders in sync with the physics simulation. As the target bones do not participate in the physics simulation, and the ragdoll bones are already moved by the simulation, the use of this mode would be redundant.

4.2.2 The physics loop

Unlike the update loop, the physics loop works on a fixed timestep. Depending on the current framerate, it may run once between two iterations of the update loop, multiple times, or not at all. Before running a step of the physics simulation, the FixedUpdate event is called. This event works similarly to Update, being called on all components that use it. A complete diagram of the physics loop can be found in figure (12). During FixedUpdate, the current poses of the ragdoll bones and the last target poses that were read are used to execute Animation Matching.

30 For Position Matching, the appropriate forces are computed as described in section (3.3.1) and applied to the Rigidbodies. For Rotation Matching, the ConfigurableJoints’ JointDrives are used. These JointDrives are configured as springs, and internally compute and apply torques according to equation (9). The ConfigurableJoints’ ‘Rotation Drive Mode’ is set to to spherical interpolation, and the JointDrives are configured with the target rotations and the appropriate spring parameters. After FixedUpdate, a physics step is simulated. During this step, the Joint- Drives apply the correct Rotation Matching forces.

31 Figure 11: The order of event execution for the update loop. The relevant events are indicated by red squares. Original image from Unity’s documentation[13].

32 Figure 12: The order of event execution for the physics loop. Original image from Unity’s documentation[13].

33 4.3 Architecture

The implementation is divided into two main modules: ‘Core’ and ‘Animation’. The Core module serves as a framework for working with ragdolls. The Anim- ation module, which is built on top of the Core module, is centred around the RagdollAnimator component, and fulfils the function on Animation Matching while using the tools provided by the Core module to do so. Both modules are further separated into ‘Core’ and ‘Extra Features’ submod- ules. The Core submodules define the core systems of the module, like Ragdoll- Settings, RagdollAnimator and multiple abstract classes and interfaces that can be implemented to customise behaviour. The Extra Features submodules implement some optional features built on these systems and extension points. Debug features are also included in these submodules. There are also ‘Core.Editor’ and ‘Animation.Editor’ modules. These modules contain editor-only code for their respective runtime counterparts. They mainly include custom inspectors and debug tools. A simplified dependency graph of the project can be found in figure (13). The contents of these modules will be explained in detail in the following sec- tions.

4.4 Core module

The Core module is a set of components, data types and tools that are designed to make working with ragdolls easier. This includes features like Ragdoll Profiles (section 4.4.1), Ragdoll Settings (section 4.4.3) and various debug tools (section 4.4.5) among others. It focuses on making parameters easier to tweak by providing centralised places for them. Some parameters are moved to reusable ScriptableObjects, while others are tweaked in the RagdollSettings component. This section will introduce the different features of the module.

4.4.1 Ragdoll profiles

Ragdoll profiles are the most important features of the Core module. They are reusable ScriptableObjects that hold user-defined data about ragdolls. A new type of ragdoll profile can be made by creating a class that inherits from the abstract class RagdollProfile, which provides multiple features. A RagdollProfile can have an optional RagdollDefinition assigned to it, allowing per-bone data to be defined. This is further explained in section (4.4.2). If no per-bone data is needed, no RagdollDefinition needs to be assigned, in which case the RagdollProfile will be compatible with any ragdoll. A standardised way of signalling a RagdollProfile’s validity is provided. This is used to show error messages and raise exceptions when invalid RagdollPro-

34 35

Figure 13: A simplified dependency graph of the project. Internal classes and custom editors have been omitted. files are used. If a RagdollDefinition is assigned, and the RagdollDefin- ition is invalid, the RagdollProfile will automatically be considered invalid as well. Finally, RagdollProfile has built-in drag-and-drop support, allowing a Rag- dollProfile to be assigned to a ragdoll by dragging and dropping the asset on the ragdoll. RagdollProfiles can be tweaked while playing the game inside the editor, allowing the values to be set in real time.

4.4.2 Ragdoll definitions

To tweak parameters on a per-bone basis in RagdollProfiles, a way of identi- fying bones individually is required. Since RagdollProfiles are designed to be reusable, direct references to the bones are not possible. The solution to this problem are RagdollDefinitions.A RagdollDefinition is a ScriptableObject that defines a set bones. Each bone is assigned a unique BoneName, and one of them is marked as the root bone. This allows Ragdoll- Profiles to serialise parameters as key-value pairs, where the key is the bone name and the value is the parameter value. An example RagdollDefinition is provided in figure (14). RagdollDefinitions, and by extension RagdollProfiles, are uncoupled from specific ragdolls. Instead, they work for any ragdoll whose bones can be mapped one-to-one to the RagdollDefinition, regardless of the shape and/or position of the bones. The actual bones of a ragdoll must then be bound to the BoneNames in the RagdollDefinition. This is done through RagdollDefinitionBindings, a component that must be attached to the ragdoll. This component requires a RagdollDefinition to be assigned. Once a RagdollDefinition is assigned, a set of fields is exposed in the inspector, one per BoneName. Each ragdoll bone must be assigned to their corresponding BoneName. The RagdollDefinitionBind- ings inspector can be seen in figure (15). Due to the amount of bones typically present in a ragdoll, binding every bone can be a tedious process. When a RagdollDefinitionBindings has at least one empty field, an ‘Attempt Autocomplete’ button is offered (see figure 16). Pressing this button attempts to fill the empty fields automatically. This is done by performing a fuzzy search where the ragdoll bones’ GameObjects’ names are compared to the BoneNames in the RagdollDefinition. This process is not guaranteed to find a match for every empty field. The matches that are found are not guaranteed to always be correct, either. Non- etheless, ‘Attempt Autocomplete’ can save a large amount of time. The more similar the ragdoll bones’ names are to the BoneNames, the better the results. RagdollDefinitionBindings allow the BoneNames from the RagdollDefini- tion to refer to actual ragdoll bones at runtime. Crucially, this allows the same

36 RagdollProfile to be shared by two non-identical ragdolls as long as they share the same bone hierarchy. As string-based identifiers are fragile, an editor API for drawing BoneName fields as dropdowns is provided. This eliminates the opportunity for human error when writing BoneNames. An example is pictured in figure (17).

37 Figure 14: A RagdollDefinition for a generic humanoid rig. Any ragdoll with these bones could use a RagdollProfile with this RagdollDefinition, regardless of the bones’ names, shapes, positions and/or rotations.

38 Figure 15: A RagdollDefinitionBindings binding a ragdoll’s bones to the RagdollDefinition from figure (14).

39 Figure 16: The same RagdollDefinitionBindings from figure (15), now with no bones assigned. Note the ‘Attempt Autocomplete’ button and the error message.

40 Figure 17: A BoneName dropdown using the RagdollDefinition from figure (14).

41 4.4.3 Ragdoll settings

Each ragdoll bone has a Rigidbody and a ConfigurableJoint. When multi- plied by the ragdoll bone count, the result is an unwieldy amount of parameters. RagdollSettings solves this problem by providing a centralised place to tweak these parameters for all bones simultaneously. RagdollSettings is a com- ponent that is attached to the ragdoll, and its parameters are tweaked in the inspector. The input values are then distributed to all ragdoll bones. Any of these parameters can be changed at runtime as well as edit time. An example of a RagdollSettings component is provided in figure (18).

Figure 18: A RagdollSettings with typical values.

The following parameters are exposed by RagdollSettings: limitBounciness: By default, joints stop their movement completely when they reach their limit. This inelastic behaviour tends to look wrong, spe- cially for organic characters. A small amount of bounciness generally looks more natural. This parameter, ranging from 0 to 1, controls the bounci- ness of the limit, where 0 causes inelastic collisions and 1 causes joints to

42 bounce back without losing any energy. limitSpring: Enforcing joint limits as hard limits can send large shocks through the ragdoll. These large shocks often irreversibly break the joints, causing the ragdoll bones to move uncontrollably with extremely high velocities. To avoid this unacceptable behaviour, a feature of ConfigurableJoints is used where the limits are enforced as springs instead. This parameter is the : stiffness of the springs per mass unit. For each bone, it is scaled accord- ing to the bone’s mass, making the apparent stiffness mass-independent. limitSpringDamping: The damping coefficient 3 of the spring described in limitSpring. It also scaled by the bone’s mass. limitContactDistanceFactor: Limits require a certain amount of tolerance for stable behaviour. To this end, limits can specify a distance threshold. The limit is only simulated if the joint is at a distance from the limit equal or lower to the threshold. limitContactDistanceFactor is expressed as a fraction of the total distance allowed inside the joint’s limits. For example, if a joint as a range of 60º, and a limitContactDistanceFactor of 0.25, the limit will only be simulated if the joint is at 60º · 0.25 → 15º or less from the limit. Higher values will make limits less likely to be violated even at large velocities, but will have a higher performance cost, as they will have to be simulated more of the time. enableJointPreprocessing: PhysX simulates frozen degrees of freedom by us- ing infinite inertia around the frozen axes. When such constrained bodies are attached to joints, extremely stiff solver constraints are generated. The process of ‘preprocessing’ involves ignoring huge impulses that cause tiny changes in velocity. This can improve results in overconstrained cases. It is recommended to use preprocessing by default. If situations where a joint’s constraints are impossible to be satisfied are encountered, disabling preprocessing should be considered. enableJointProjection: Projection is a post-processing process in which, when a joint solver fails to bring the joint back inside the limits, the joint is directly brought back into alignment with no respect to momentum or collisions. As it is not a physical process, but rather a ‘cheat’, it should be avoided if possible. If joint limit violations result in unacceptable artefacts, however, projection can be a useful last resort. If projection is enabled, two new parameters are exposed: minJointProjectionDistance and min- JointProjectionAngle. These parameters define thresholds where pro- jection is only applied if the limit violation passes the thresholds. useGravity, drag, angularDrag, material, interpolation, collisionDetectionMode: These parameters are simple wrappers for Rigidbody’s properties with the same names. The same value is applied to all ragdoll bones. mass: The desired total mass of the ragdoll. The sum of the mass of all ragdoll bones will equal this value.

43 jointSolverIterations: Sets the amount of iterations for the joint solvers. Higher iterations can improve stability at the cost of performance. As a reference point, 6 is the default value. powerProfile: Applies a power profile (explained in section 3.5) to the ragdoll. Power profiles are defined through a type of RagdollProfile: Ragdoll- PowerProfiles.A RagdollPowerProfile defines a power setting for each bone in the ragdoll. The settings are colour-coded for better readability. These colours are the same as the ones used by RagdollColliderVisualizer (section 4.4.5). A ‘Set All’ button is offered so that RagdollPowerProfiles can be defined faster. An example RagdollPowerProfile is pictured in figure (19).

Figure 19: An example of a RagdollPowerProfile. weightDistribution: The way a ragdoll’s mass is distributed among its bones

44 can dramatically affect the ragdoll’s behaviour when in an unpowered state. To make this distribution easier to tweak, the bone’s masses are defined through a RagdollWeightDistribution. RagdollWeightDis- tribution is a type of RagdollProfile. It exposes a set of sliders ran- ging from 0.1 to 1.5, one slider per bone. These sliders define the relative masses of the different bones. For example, a bone A with a value of 1 will have double the mass of a bone B with a value of 0.5. An example RagdollWeightDistribution is pictured in figure (20).

Figure 20: An example RagdollWeightDistribution.

The total mass defined in the mass parameter is distributed according to these relative masses. For a humanoid character, it is recommended that bones around the centre of mass are the heaviest, with bones getting progressively lighter towards the extremities. For the sake of stability, large differences between bones that are attached to each other should be avoided.

45 4.4.4 Collision Ignorance

As proposed in section (3.6), the selective ignoring of collisions is allowed. This is implemented through RagdollCollisionProfile and RagdollColli- sionIgnorer. RagdollCollisionProfile is a type of RagdollProfile where the collisions to be ignored can be specified. An example of one is shown in figure (21). Collisions can be ignored in two different ways:

• Ignored bone pairs can be set. Two bones in a pair will ignore collisions with each other. • A bone’s colliders can be outright disabled.

Figure 21: An example of a RagdollCollisionProfile. In this profile, colli- sions have been completely disabled for the hands. A running animation caused the legs to collide with each other, so certain bone pairs have been disabled so that this doesn’t affect the ragdoll.

It is worth noting that bones that are attached to each other always ignore collisions between each other. The inspector warns against redundant settings, and offers a button to auto- matically fix them (see figure 22).

46 Figure 22: A RagdollCollisionProfile with redundant settings. The ‘Fix’ buttons will automatically remove the redundant settings when pressed.

After a RagdollCollisionProfile has been defined, a RagdollCollisionIgnorer component can be added to the ragdoll. This component applies the assigned RagdollCollisionProfile. The profile can be changed at runtime. Rag- dollCollisionProfile will first undo the application of the previous profile, and will then apply the new one. If the profile is set to null, it will be inter- preted as a profile that doesn’t ignore any collisions.

4.4.5 Debug Tools

The Core module includes two features intended to ease development:

RagdollColliderVisualizer: When added to a ragdoll, this component draws the colliders of the ragdoll as meshes. They are coloured according to their bones’ power settings, following the same colour coding as RagdollPower- Profile. A picture of RagdollColliderVisualizer working is shown in figure (23).

47 Figure 23: A character with the power profile shown in figure (19) can be seen three times. The left character has their mesh enabled, and RagdollCol- liderVisualizer disabled. The centre character has their mesh disabled and RagdollColliderVisualizer enabled. The right character has both their mesh and RagdollColliderVisualizer enabled.

PhysicsDragTool: An editor tool that allows the user to click and drag on a Rigidbody to move it. Useful to manipulate a ragdoll while tweaking their values.

4.5 Animation module

The Animation module builds on the framework provided the Core module, and implements Animation Matching via the RagdollAnimator component, which uses the Animation Matching parameters defined in RagdollAnimationPro- files. A Mecanim integration is included, as well as an implementation of the collision reaction method proposed in section (3.6) and a component that prevents large, sudden forces in certain situations. Finally, the module contains a wizard that helps in the creation of ragdolls. This section will describe all of these features in detail.

48 4.5.1 Ragdoll animator

The RagdollAnimator, pictured in figure (24), is the most important compon- ent in the package. It implements Animation Matching through the method described in section (4.2). It must be attached to the target, typically alongside an Animator.

Figure 24: The inspector for RagdollAnimator.

A RagdollDefinitionBindings must be assigned in the inspector, which allows the RagdollAnimator to find the ragdoll bones. This means that no specific hierarchical relationship between the target and the ragdoll is required, though making them siblings is recommended for organisational purposes. A RagdollAnimationProfile must also be assigned. RagdollAnimationPro- files, described in detail in section (4.5.2), define the U and Z parameters used in Animation Matching. RagdollAnimator requires a RagdollAnimationPro- file to always be set. The assigned RagdollAnimationProfile can be swapped for a different one at runtime. When changing profiles, a transition happens. During a transition, the RagdollAnimator linearly blends between the previous profile’s parameters and the new profile’s parameters. The length of this transition can be set via the profileTransitionLength property. Two master controls are offered, masterAlpha and masterDampingRatio. They act as multipliers ranging from 0 to 1 for U and Z respectively. These controls are useful for quickly testing what a profile would look like with different values. Their use as a permanent part of an animation setup is not recommended. RagdollAnimationProfiles should be used to statically define different kinds of behaviours. To modify parameters dynamically, an IBoneProfileModifier (described in section 4.6.1) should be used. RagdollAnimator also has two debug features:

49 hideMesh: Disables all renderers in the target. Useful in tandem with Rag- dollColliderVisualizer (section 4.4.5). Allows the developer to see the ragdoll simulation more clearly. Also useful to prevent potentially unpleasant visuals when dealing with simulation-breaking issues. forceAnimatedPose: Skips the step where the target bones are moved to the ragdoll bones’ poses, rendering the character in its original target pose. Useful for A/B testing and comparisons between the target pose and the ragdoll pose.

These debug features are only present in the Unity Editor, they can not be used by runtime code.

4.5.2 Animation profiles

Animation Matching requires a set of parameters, as described in section (3.4). These parameters are defined through a type of RagdollProfile: RagdollAn- imationProfiles. An example of a RagdollAnimationProfile is provided in figure (25). The profile is split into position and rotation parameters. For each section, there are three global parameters: U, Z and a maximum acceleration. These global parameters apply to all bones by default. Optionally, a RagdollDefinition can be provided. If a RagdollDefinition is available, U and Z can be overridden on a per-bone basis. In the case of Rotation Matching, an extra parameter is exposed: matchRootRo- tation. Rotation is matched relative to the bone’s parent. However, for the root bone, this is effectively the same as matching in world space. In practice, matching the root’s rotation prevents the ragdoll’s orientation from straying far from the target’s. Not matching the root’s rotation allows a dis- connect between the target’s orientation and the ragdoll’s. This disconnect is most apparent when Position Matching is disabled. This behaviour may or may not be desirable, depending on the situation. In a setup for a running character, it may be sensible to enable root rotation matching in order to prevent the character from falling over. For a skydiving character, on the other hand, arbitrary orientations may be desirable.

50 Figure 25: An example of a RagdollAnimationProfile for a humanoid charac- ter that has had their right arm injured. Lower alpha values have been used in their right arm to reflect the injury. The rotation damping ratio for the shoulder and upper arm has been raised to avoid the arm looking too floppy.

51 4.5.3 Mecanim integration

The package offers an integration with Mecanim, Unity’s built-in animation system. In Mecanim, a character’s animation is driven by a finite state machine. A state may refer to a specific animation, a blend tree, or even a sub-state machine. A state can have components inheriting from StateMachineBehaviour attached to it. The package includes multiple such components: SetRagdollPowerProfileOn- Enter, SetRagdollWeightDistributionOnEnter, SetRagdollCollisionPro- fileOnEnter and SetRagdollAnimationProfileOnEnter. These components hold a reference to an instance of their respective Ragdoll- Profile type. When the state machine enters a state with any of these compon- ents, each of them will assign its referenced profile at the appropriate component in the ragdoll or target. This integration allows completely different ragdoll setups to be seamlessly tied to different animation states without any custom code, allowing animators fur- ther control over the ragdoll. All four components inherit from SetRagdollProfileOnEnter, which imple- ments a basic structure for their shared functionality. If a user creates a custom type of RagdollProfile, they may consider creating a SetRagdollProfileOn- Enter variant for said profile type.

4.5.4 Collision reaction

In section (3.6), a method for reacting to collisions is proposed, in which the U parameter for a bone is dynamically reduced after a collision. This method is implemented in RagdollCollisionReaction. This optional component, which should be attached next to a RagdollAnimator, waits for the ragdoll bones to collide with something. When a ragdoll bone collides, its U parameters are multiplied by a certain con- figurable factor. They are then linearly transitioned back towards their original value over an amount of time specified by recoveryTime. How much U is lowered is configured via the softeningAmount property, which ranges from 0 to 1. The final value of U is given by:

U;>F4A43 = U>A868=0; · (1 − B>5 C4=8=6<>D=C · (1 − C)) (32) where

C8<4(8=24>;;8B8>=  C = min , 1 A42>E4A~)8<4 (33)

RagdollCollisionReaction allows further configuration. A CollisionMask can be provided to only react to collisions against certain layers. The reaction

52 can also be individually enabled or disabled for position matching and rotation matching.

4.5.5 Power on transitioner

When a bones goes from an unpowered state to a powered state, huge, sudden forces can be applied to the bone, which can lead to instability. A similar problem can happen when a character is first instanced, as large jumps may happen in its animation and/or position. If an Animator is being used, RagdollAnimator forces it to run an animation update, after which the ragdoll bones are initialized at the target bones’ new poses with a velocity of 0. However, this workaround is only available if the character is using an Animator, and only solves one of the problems. For these situations, RagdollPowerOnTransitioner can be used. Ragdoll- PowerOnTransitioner is an optional component that should be attached next to a RagdollAnimator. When an unpowered bone becomes powered, its U para- meters are linearly transitioned from 0 to their original value over an amount of time defined by transitionLength. This avoids the previously mentioned problematic sudden forces. This transition can optionally also be triggered when the character is instanti- ated by setting doStartingTransition to true.

4.5.6 Animated ragdoll wizard

There are many individual steps in creating a ragdoll. The setup involving two versions of the character described in section (4.1.3) further complicates the process. To solve this issue, the package includes the AnimatedRagdollWizard. This wizard guides the user through the multiple steps involved in the creation of a ragdoll, and automates the process where possible. What follows is a step-by- step description of the wizard. The process starts with a GameObject that will become the target. The wiz- ard asks for the GameObject to be assigned to a field. Pressing the ‘Create Copy’ button creates a copy of the assigned GameObject. The original object is renamed to ‘Target’, while the copy is renamed to ‘Ragdoll’. In the second step, the wizard instructs the user to add the desired colliders to the ragdoll bones. The user must press the ‘Continue’ button once the colliders have been added. The third step asks the user to add a ConfigurableJoint to every ragdoll bone, and to configure said joints with the desired axes and limits. A field is shown where the root bone must be assigned. The wizard enforces the rules regarding omitted bones explained in section (4.1.3). The ‘Continue’ button is only enabled if all the requirements are met. When it is pressed, any child of ‘Ragdoll’ that is not relevant to the ragdoll simulation is destroyed.

53 In the final step, a choice is offered: the user can create a new RagdollDefin- ition or use an existing one. If the user decides to create a new RagdollDefinition, one will be created, and it will be automatically configured with the ragdoll’s bones’ names. A RagdollPowerProfile, a RagdollWeightDistribution and a RagdollAnim- ationProfile will be created, all configured to use the newly created Rag- dollDefinition. After this step, a series of components will be added to the target and the ragdoll. The ragdoll will have a RagdollDefinitionBindings, a RagdollSettings, a RagdollCollisionIgnorer and a RagdollColliderVisualizer added to it. The RagdollDefinitionBindings will be automatically configured with the new RagdollDefinition or the provided one, and the bindings will be auto- completed if possible. The newly created RagdollPowerProfile and Ragdoll- WeightDistribution will be assigned to the RagdollSettings if a new Rag- dollDefinition was created. A RagdollAnimator, a RagdollPowerOnTransitioner and a RagdollColli- sionReaction will be added to the target. The RagdollAnimator will have the RagdollDefinitionBindings automatically assigned, and if new profiles have been created, the new RagdollAnimationProfile will be assigned too. After the components are created and configured, the wizard is closed.

4.6 Extensibility

Several ways of extending the package with custom features are offered. IBoneProfileModifier and ITargetPoseModifier offer two interfaces through which the behaviour of RagdollAnimator can be modified. RagdollAnimator will make use of any component in the same GameObject that implements either of these interfaces. RagdollAnimator calls all of its modifiers before every Animation Matching step, so modifiers can be combined. Through custom RagdollProfiles, any additional data can be treated in the same manner as the existing RagdollProfiles.

4.6.1 IBoneProfileModifier

RagdollAnimationProfiles are static. Their values can not change at runtime, save for editing them in the editor during play mode. Thus, a different solution is needed for dynamic changes: IBoneProfileModifiers. IBoneProfileModifier is an interface that allows a class to receive and modify the Animation Matching parameters for each ragdoll bone. RagdollColli- sionReaction and RagdollPowerOnTransition are implemented through this interface.

54 It could, for example, be used for loosening a bone that has been shot in a shooter, or to make an arm stronger in reaction to player input in a climbing game.

4.6.2 ITargetPoseModifier

If a ragdoll is allowed to stray far from the target pose, features that dynamically alter animation, such as IK, may not align correctly with the ragdoll. This issue is exacerbated if only Rotation Matching is used and root rotation is not matched. In cases where these existing features fail to produce a correct target pose, ITargetPoseModifier can be used. ITargetPoseModifier allows a class to receive the current target pose of each bone. This target pose can then be modified or completely overrisen. Ragdol- lAnimator will match the modified pose instead of the original one.

4.6.3 Custom ragdoll profiles

Custom features may require configuration in the same way that Animation Matching and collision ignorance do. In such a case, the user may decide to create a new type of profile by inheriting from RagdollProfile. All built- in profiles are implemented through RagdollProfile, and the class provides multiple benefits as described in section (4.4.1).

55 5 Tools & Methodology

The development methodology was a combination of Kanban and Git-flow that was adapted for the particular needs of the project; namely the need for iter- ation, experimentation, and the presence of a single developer. This chapter will introduce the tools that enabled this workflow, as well as the Kanban and Git-flow strategies, after which the workflow itself will be described in detail.

5.1 Tools

There were tools that, while not intrinsically part of the developed project, were instrumental to the development process. This section will introduce these tools.

5.1.1 Microsoft Visual Studio

All of the code was written in Microsoft Visual Studio. Microsoft Visual Studio[17] is an Integrated Development Environment de- veloped by Microsoft that has support for 36 different programming languages, including C#, which was the language the project was developed in. It has an extremely powerful set of features, and facilitates the development of applica- tions with Unity via its Unity integration. Additionally, a free license is offered for individuals. Microsoft Visual Studio was chosen for its wide range of C# editing and debug- ging features and its Unity integration. Its DGML (Directed Graph Markup Language) editor was used to visualise, reason about and plan the software architecture.

5.1.2 Git

Git[15] is a version control system, originally created by Linus Torvalds in 2005, now maintained as an open source project headed by Junio Hamano. It has excellent support for non-linear development, and is widely used in the pro- gramming community. In a survey conducted by Stack Overflow in 2018, 87.2% of the participants cited Git as their favourite version control system[16]. Git was essential to the development process, and made prototyping different approaches easier.

5.1.3 HacknPlan

HacknPlan[18] is a project management tool built specifically for game devel- opment by Chris Estevez. It was used to manage the work that needed to be done, and was central to the methodology that was used.

56 5.2 Methodology

HacknPlan was extensively used in the development process, serving as a Kan- ban board. A simplified version of the Git-flow strategy was used for version control. This section will introduce all of these, outline the workflow that was used for the development process, and showcase how the different tools enabled said workflow.

5.2.1 Introduction to Kanban and HacknPlan

Kanban is a workflow management system based on organising pending work into discrete pieces of work, often referred to as tasks or cards, that can then be visualised in a Kanban board. A Kanban board has a set of columns that represent the different stages a task can be at. There is no standard set of columns, as different projects might need to represent different stages. HacknPlan was used as a Kanban board. HacknPlan has a fixed set of columns:

Planned: the task is to be completed in the near future, but work on it has no yet started. In progress: the task is actively being worked on. Testing: work on the task has finished, but it must be reviewed/validated before being considered complete. If the work does not pass the review, the task may be moved back to the ‘In Progress’ column if further work should be done, or it may be removed entirely if the task is abandoned. Completed: work on the task has finished, and it has been approved after a review.

Additionally, in HacknPlan, a task can be in the backlog. A task in the backlog is a piece of work that is pending, but not planned to be done in the near future. As they are planned in the long term, these tasks are often very high level, needing to be elaborated upon before being moved to the ‘Planned’ column of a board. Finally, tasks can be grouped into user stories.A user story refers to a high level feature or section, and contains several tasks that describe the steps needed to complete said feature at a lower level.

5.2.2 Introduction to Git-flow

Git-flow is a branching strategy popularised by Vincent Driessen[19]. Git-flow operates under two strict principles: the master branch must always be deploy- able, and work must happen in feature branches.

57 Git-flow proposes two main branches: master and develop. Work happens in short-lived feature branches that stem from develop. After the feature the work is complete, the feature branch is merged into develop. Develop represents the latest version of the software, while master represents the latest stable release of the software. For the development of this project, a simplified strategy based on Git-flow was used. As the project was still unreleased, and thus there was no concept of a release version, the develop branch was omitted, with feature branches branching in and out of master directly.

5.2.3 Development workflow

Ideas for features or work that needed to be done were first turned into tasks in the backlog. In the case of features, they were created as user stories if they were large and high level enough (e.g.. support for arbitrary rigs). Tasks that were required by currently planned/in progress tasks, or were relevant to the work in progress, were directly planned and created in the board, without passing through the backlog. When every task in the board was completed, a planning pass was done. This involved multiple steps:

1. Sort the backlog in terms of priority 2. Delete tasks that had become obsolete 3. Move the highest priority tasks to the board until the planned tasks amounted to between an estimated week and two weeks of work. 4. Expand upon the planned tasks that were too high level to be actionable

These planning passes resulted in a workflow similar to the concept of ‘sprints’ in Scrum methodology. After the planning pass, tasks to work on were selected in order of priority. Work on a task begun by creating a feature/fix branch. This allowed multiple branches to be worked on in parallel, and offered a way to easily discard changes if necessary. The ability to cleanly discard changes was paramount, as many features were of an experimental nature. Position Matching in particular required multiple approaches to be attempted. Once the task was complete, it was moved to the ‘Testing’ column in HacknPlan. If the feature was experimental, the resulting quality was analysed at this stage. If it was deemed insufficient, the branch was never merged into develop, and another approach would be attempted in a new branch. If the feature was accepted, the code would be refactored to improve it in terms of architecture. After the refactor, the branch was finally merged into develop, and the task was moved to the ‘Completed’ column.

58 5.2.4 Data

Most work time was tracked on a per-task basis. Tasks were also classified into different categories. Figure (26) shows the time distribution over these categories.

• ‘System Programming’ refers to the implementation of runtime features like Animation Matching. • ‘Tool Programming’ refers to the creation of in-editor tools like custom inspectors and the setup wizard.

• ‘Demo Making’ refers to the creation of the different test scenes in which the system has been tested. • ‘Thesis Writing’ refers to the writing of this thesis. • ‘Others’ includes miscellaneous categories such as bug fixing and architec- ture design.

Figure 26: The amount of work time dedicated to each category.

59 6 Results & Benchmarks

6.1 Benchmarks

A set of benchmarks were designed to evaluate the parameters’ influence and the effectiveness of the developed techniques. These benchmarks are contained in a set of scenes that represent different use cases for the system. Some scenes feature multiple benchmarks. Each bench- mark was designed with a specific facet to test. The benchmarks were used during development to guide decisions about the configuration of the techniques and parameters via experimentation. The fol- lowing is a list of the benchmarks that were used, along with their specific goals. Most of them can be seen in motion in a YouTube video[20]. A detailed perceptive evaluation would be ideal to validate the results of these benchmarks. However, this was outside the scope of this thesis.

6.1.1 Basic Locomotion

The main benchmark scene, ‘SCE_WalkingAround’, contains a character with a basic set of movement animations, representing a typical character in a game with a third person perspective, as shown in figure (27). The character’s move- ment is simulated with a vertical capsule as a collider, the navigation collider, which determines where they can or can not stand.

Figure 27: The basic locomotion benchmark (section 6.1.1).

The ragdoll has a collider per ragdoll bone, resembling the general shape of the character. These colliders collide with the scenery, but not with the navigation

60 collider. The ragdoll’s feet are set to kinematic, while the rest of the bones are powered. This way, the character will always stand where the simulation of the navigation collider dictates. The feet always stay under the navigation collider, while the rest of the body is pulled the feet while matching the target animation, and respecting collisions with the scene. The environment features a flat ground, with a series of colliders for the char- acter to collide with. This benchmark focuses on the ragdoll’s ability to faithfully play animations, and the gradual deviation introduced by lowering the available parameters. With high enough values of U and Z , the resulting animation must be indis- tinguishable from the keyframed animation. By lowering these parameters, sec- ondary motion must be gradually introduced, with the ragdoll deviating more from the target. The effects of the parameters have been visualised in figures (28), (29) and (30). The graphs in these figures show the ragdoll’s deviation from the target pose over time for the 6 possible combinations of the the following parameter values: high (0.60), medium (0.30) or low (0.01) U, and high (1.00) or low (0.10) Z . The deviation is obtained by computing the average difference between the ragdoll bones and the target bones. All 3 graphs analyse the same execution of the test, in which a character stands still at the beginning, starts running at physics step 50 and stops running at physics step 250. In figures (28) and (29), a clear separation can be seen. Low U values stray much further from the target pose than medium of high U values. The effect of Z is best appreciated by looking at the behaviour after sudden changes in velocity, such as when the character starts running (physics step 50) and stops running (physics step 250). The low U, Z data shows large, low- frequency oscillations that take over 50 physics steps to settle. These spikes are much less noticeable for entries with high Z . The high U, high Z case is worth examining on its own. As per the definition of U provided in section (3.4.1), this case would be expected to achieve the lowest deviation from the target. However, its positional deviation is the third highest in figure (28). Figures (30) and (31), which show the deviation in linear velocity and the target linear velocity respectively, offer insight into the cause of this inconsistency. Estimating the target velocity via finite differences over a single step leads to a noisy target velocity with high-frequency variation. High parameter values are more sensitive to such high frequency variation, while lower values will effectively smooth out this effect . Several takeaways can be taken from these tests. The range of U has most of its expressiveness in its lower range. An U of 0.3 looks virtually identical to an U of 0.6. Furthermore, as the effect of the noisy nature of the target velocity is proportional to the values of U and Z , it is recommended that U be set by starting low and increasing it until the desired behaviour is

61 Figure 28: The average difference between the target bones’ world position and the ragdoll bones’ world position. found. In general, the lowest values that achieve the desired behaviour will give the best visual quality. This is, to a lesser extent, also applicable to Z . Three different starting points for further experimentation are proposed, de- pending on the desired animation style:

• For games that aim for enhanced fluidity and secondary motion while keeping playing animations faithfully: U= 0.05, Z =0.5 • For games that desire the collision-related properties of Animation Match- ing without secondary motion modifying the animation: U= 0.3, Z =1

• For a playful, non-realistic style that resembles the Active Ragdoll ap- proach (2.3), U=0.02, Z = 0.1

62 Figure 29: The average difference between the target bones’ local rotation and the ragdoll bones’ local rotation.

Figure 30: The average difference between the target bones’ world-space linear velocity and the ragdoll bones’ world-space linear velocity.

63 Figure 31: The average target world-space linear velocity.

64 6.1.2 Colliding with Walls

The capsule for the character from ‘SCE_WalkingAround’, further described in section (6.1.1), has a radius that is much smaller than the radius that would be needed to avoid the character’s limbs coming into contact with walls. The goal of this benchmark (show in figures 32 and 33) is to evaluate the way the ragdoll deals with parts of their body colliding with a wall and being unable to faithfully play the target animation.

Figure 32: The ‘collision with walls’ benchmark (section 6.1.2). The mesh, which has been made transparent to make the figure clearer, shows the target animation. The ragdoll shows the resulting animation, which respects collisions. Note how the character’s left arm goes through the wall while the ragdoll’s does not.

Figure 33: A timelapse of a hit reaction in benchmark (6.1.2). The transparent mesh shows the target pose.

A satisfactory result requires the collision to have little effect upon the animation of the body parts uninvolved in the collision. The colliding arm should slightly

65 lag behind the body without looking like a dead weight. Once the collision is over, the arm should return to the target pose at a speed that is neither too slow or too fast. This benchmark was instrumental for the development of the collision reaction method described in section (3.6).

6.1.3 Walking Under an Obstacle

The capsule in ‘SCE_WalkingAround’, described in section (6.1.1), is signific- antly shorter than the character, ending at waist height. A collider was set up in the environment at a similar height, such that the capsule collider would allow movement under it, but the ragdoll would collide with it. This benchmark tests the ragdoll’s ability to deviate greatly from the target to react to a collision, and return to the target pose afterwards in a natural and stable manner. Initial ragdoll setups featured joints with non-elastic limits. These hard limits introduced large shocks to the ragdoll, breaking it irreversibly and never re- turning to the target pose. This issue was fixed once the joint limits were made elastic, allowing use cases as extreme as the one shown in figure (34).

Figure 34: A timelapse of the ‘walking under an obstacle’ benchmark (section 6.1.3). The red capsule indicates the collision shape used for allowing movement.

6.1.4 Shooting Balls

In this setup, the user can click on the screen to shoot a sphere from the camera towards the ragdoll. This benchmark evaluates the way the ragdoll reacts to sudden, localised forces. A similar setup might be seen in a shooter where bullets apply a force upon hitting a body part. Hit reactions are one of the main use cases for Physics- Driven Character Animation. This setup doubles as a perfect demonstration of the effect of U and Z . As the value of U is increased, the character returns to the target pose in a shorter time. As the value of Z is decreased, the character oscillates more around the target pose instead of perfectly returning to it. Figures (35) and (36) show the results of the benchmark with different combinations of parameters.

66 Figure 35: A timelapse of a hit reaction in benchmark ‘shooting balls’ (section 6.1.4). In this particular example, the ragdoll has considerable U and high Z values.

Figure 36: A timelapse of a hit reaction in benchmark ‘shooting balls’ (section 6.1.4). In this example, the character has medium U and very low Z .

6.1.5 Hanging

In this setup, the character’s right hand is set to kinematic, and it always follows a movable object that floats in the scene. The main goal of this benchmark is to ensure that the ragdoll can hang from a single bone without breaking. As a secondary test, the target animation is a single frame of a climbing animation. In a successful test, the ragdoll should not become unstable even with multiple forces acting upon its hanging body. The lower body should sway convincingly, and the value of U should correspond with the apparent strength of the character. Achieving satisfactory results in this benchmark required much experimentation with the parameters. For example, in figure (37), the lower body had its Position

67 Matching U set to 0 so that it would be allowed to sway. The arms were given high values of Rotation Matching U to keep them stiff, and a non-zero Position Matching U to help them support the ragdoll’s weight.

Figure 37: A timelapse of the ragdoll described in section (6.1.5) swinging after a disturbance. The red and yellow lines show the target pose. Note how the motion is achieved with a single frame of animation.

6.1.6 Climbing

In this benchmark, the character climbs along a vertical wall, using IK to place their hands on grabbable objects. The ragdoll is set up such that its whole body is powered. The arms and hands are specially tight, while its legs have no Position Matching, and loose Rotation Matching. The goal of this benchmark is to evaluate the improvements that Animation Matching can bring to a real use case, specially in regarding secondary motion. These improvements are best appreciated via an A/B test performed by enabling and disabling Animation Matching. See figures (38) and (39) for a comparison.

Figure 38: A timelapse of benchmark 6.1.6: Climbing with Animation Matching disabled.

68 Figure 39: A timelapse of benchmark 6.1.6: Climbing with Animation Matching disabled. Note the sway of the lower body.

6.1.7 High Acceleration

This benchmark involves a setup similar to the one described in section (6.1.1), but with the character moving at an extremely high velocity with instantaneous acceleration. It is designed to test the ragdoll’s stability under extremely high acceleration. This benchmark prompted the addition of the maximum acceleration function- ality introduced in section (6.2.4). While this addition improved stability, the visual result is not ideal, as the character visually lags behind the target as shown in figure (40).

Figure 40: The results of limiting acceleration on a character that accelerates extremely quickly. The mesh shows the target. Note how the ragdoll fails to keep up with the target.

The amount of acceleration present in this benchmark was deemed uncommon enough that this issue was left as an area for future improvement.

6.1.8 Local Space Waving

The system must be able to play animations in local space, regardless of the character’s orientation. The local space waving benchmark, pictured in figure (41), is designed to ensure that this is the case.

69 Figure 41: The ‘local space waving’ benchmark (section 6.1.8).

The scene features three ragdolls side by side, playing the same waving anima- tion. The rightmost one has all of their bones powered, and they are rotated so that they lie down on a slope. The one in the centre is upright, and has their feet kinematic and the rest of their bones powered. Both have Position Matching disabled, and quite strong Rotation Matching. Rotation Matching of the root bone is disabled. The leftmost ragdoll is entirely kinematic, serving as reference of the target animation. The result is the following: both powered characters wave convincingly while being far from upright. The standing character with kinematic feet slouches forwards while waving, while the laying character is supported by the slope while waving.

6.2 Failed experiments

The Animation Matching method was designed and developed in an iterat- ive process. Thus, many approaches were attempted for different problems. Position Matching in particular required many attempts before arriving at a satisfactory solution. This section contains the most insightful discarded approaches.

70 6.2.1 Velocity Gain parameter

The first approach for Position Matching used a different function to compute the forces. Instead of using function (6), the force was computed as −→ −→ z = −ΔE · E4;>28C~608= · < (34) where E4;>28C~608= is a value in the range [0, 1]. This method produced results similar to the final product. However, the only tweakable parameter was E4;>28C~608=; the damping was coupled to the match- ing force. The artistic control afforded by this single parameter was deemed insufficient. Rotation Matching was already implemented through a spring, though the : and 3 values had to be manually entered. The decision was made to implement Position Matching through a spring too, and the focus was moved to finding an artist-friendly replacement for : and 3.

6.2.2 Position Matching through Spring Joints

When transitioning to a spring-based solution for Position Matching, an ap- proach relying on the joints provided by the physics engine was tested, with the expectation that these joints would prove more robust than a custom im- plementation of a spring. Each ragdoll bone was attached with a spring joint to its target bone. These springs were configured with the parameters described in section (3.4). The results were extremely jittery for high values of U, even with high damping. Moreover, the additional joints and rigidbodies required by this setup raised the complexity and performance cost of the ragdoll significantly. The decision to directly compute and apply the Position Matching forces without relying on additional joints was made.

6.2.3 Collision Give

As described in section (3.6), tight parameters can cause the ragdoll to vibrate against colliders that interfere with the animation. To solve this issue, a predictive approach was attempted. The path of each ragdoll bone over the current physics step was extrapolated, and a sweep test was performed along it. If a collision was found, the bone’s acceleration was lowered by a controllable 2>;;8B8>=68E4 factor in the range [0,1].

−−−−→ −−−−−−→ 05 8=0; = 0>A868=0; · (1 − 2>;;8B8>=68E4) (35)

71 The lowered Position Matching forces did alleviate the vibrations, though the predictive behaviour over a single step was imperceptible. It was, in practice, equivalent to reacting to collision events. A longer-term prediction was attempted by extrapolating the bone’s path over a longer period of time. The results gave the impression of the character going limp when approaching colliders, which looked highly unnatural. In conclusion, the performance cost of the short-term predictive behaviour was deemed pointless, and the method described in section (3.6) was adopted.

6.2.4 Maximum acceleration

For use cases where large, sudden accelerations are expected, it was theorised that it would be desirable desirable to apply a limit 0<0G scalar to the acceler- ation a ragdoll bone can experience in a single step. The limit was effectively applied on the animation matching force before this force is added to the bone together with the rest of the forces. However, the limit was evaluated in terms of acceleration to make it mass-independent.

−−−−−−→ −→ z;8<8C43 = D · min (0D=;8<8C43, 0<0G ) · < (36) −−−−−−→ where z;8<8C43 is the force after the acceleration limit has been applied, −→ z −→D = −→ (37)

z −→ z 0 = D=;8<8C43 < (38)

and 0<0G is the maximum acceleration magnitude allowed in a single step. Benchmark (6.1.7) proved that this approach gives unsatisfactory visual quality. The functionality is kept present in Hairibar.Ragdoll, but it is recommended that the maximum acceleration be set to infinite for most use cases.

72 7 Conclusions

7.1 Realised goals

A set of goals were presented in section (1.3). This section will show how each of these goals was achieved.

7.1.1 Functional goals

• In the absence of contact, and with appropriate parameters set, the charac- ter must be able to move almost identically to the keyframed animation: As demonstrated by benchmark 6.1.1: Basic Locomotion, high enough com- binations of parameters U and Z look indistinguishable from the target animation. • The resulting motion must be adjustable via parameters. Adjusting these parameters must gradually introduce more secondary motion and allow more deviation from the keyframed animation: The use of parameters U and Z allows control over the resulting motion. Their effect can be appreciated in benchmarks 6.1.1: Basic Locomotion, 6.1.4: Shooting Balls and 6.1.5: Hanging. • The character must be able to imitate the keyframed pose in local space, regardless of orientation: Matching rotation in local space allows the rag- doll to match the target at any orientation, as proven by benchmark 6.1.8: Local Space Waving. • Under collision, the character must react accordingly. It must not penet- rate any colliders, and the pose must be kept as intact as possible in the process: The physical simulation of ragdolls guarantees that they will re- spect collisions. The ability to match rotation in local space allows the colliding body parts to keep a pose as similar to the target as collision will allow. Additionally, the collision reaction technique presented in section (3.6) achieves more natural animation under collision, as seen in bench- mark 6.1.2: Colliding with Walls.

7.1.2 Quality goals

• The system must be easy to use by non-technical animators. An anim- ator with limited technical knowledge must be able to tweak parameters to achieve their desired look without any external help. To ensure this, any exposed parameters should a have single, clearly understandable ef- fect: Two parameters have been designed to achieve this goal: U and Z , presented in section 3.4: Parameters. They each have a clear, easily ex- plainable effect on the resulting animation. They operate in the range [0, 1], allowing them to be visually presented as intuitive sliders.

73 • The system must be transparent. It should not require a significant change in neither the animation pipeline nor the code of the game that uses it: The timeline described in section (4.2) allows Motion Matching to operate as a post-processing layer applied to the target animation. The animation systems of a game need not change at all to make use of Hairibar.Ragdoll, only requiring the ragdolls to be set up. Bespoke code need only be writ- ten for dynamic switching of ragdoll profiles in cases where the included Mecanim integration will not suffice. • The system must be compatible with any other animation technology, within reason: Reading the animated pose of the target bones decouples the An- imation Matching from the animation systems. Thus, as long as the anim- ation system modifies the position and rotation of the bones, Hairibar.Ragdoll will be implicitly compatible with it.

7.2 Future work

The developed system satisfies many use cases. However, the addition of certain features would further improve it. The following is a list of improvements that could be made to both Hairibar.Ragdoll and the Animation Matching method in general in the future, but were considered out of scope for this thesis.

7.2.1 2D Support

Unity offers two different physics engines: PhysX for 3D, and Box2D for 2D. Hairibar.Ragdoll only supports PhysX, making it incompatible with games that use 2D physics. The Animation Matching method could easily be adapted to 2D by using 2D vectors for position and only considering rotation in the Z axis. However, much of the tooling in Hairibar.Ragdoll would require updating to support 2D and 3D physics interchangeably. This would be a major undertak- ing. Additionally, as there is no 2D equivalent for the ConfigurableJoint, the Rotation Matching forces would need to be manually computed and applied.

7.2.2 Better animation limiting

As discussed in sections (6.1.7) and (6.2.4), simply applying a hard limit to acceleration over a single step gives unsatisfactory results. Designing a better method for limiting acceleration would better suit Animation Matching for games involving sudden accelerations, such as racing games.

7.2.3 Bone scaling and stretching support

It is common for bones to be stretched and scaled in stylised, unrealistic anim- ation. This presents a problem when attempting to play these animations with

74 a ragdoll. Scaling a collider can create issues in the physics simulation. For example, imagine a sphere collider in a narrow corridor. If the sphere is scaled such that its diameter is larger than the corridor’s width, the physics engine will be presented with an unsolvable collision. Stretching a bone involves changing the distance between a bone and its par- ent. Ragdolls are typically implemented with joints that disallow any relative movement, allowing only rotation. Supporting bone stretching would require temporarily allowing two connected bones to becomes separated. Additionally, the collider of the stretched bone would need to be scaled accordingly to prevent other colliders from intersecting the stretched bone. This addition would allow animators to make more stylised animations while still reaping the benefits of Animation Matching.

7.2.4 Dynamic adjustment of joint limits

Ragdolls are typically set up with conservative joint limits. The reason for this is that the wider the allowed range of motion, the more potentially unnatural poses that the ragdoll will reach. However, animations will often include poses that fall outside of these limits. In its current state, Hairibar.Ragdoll will not allows the joints to beyond their limits, failing to faithfully play such animations. In a Game Developers Conference talk, Jalpesh Sachania explained EA’s solu- tion to this issue[7]. Their solution is to dynamically adjust the joint limits when the target anima- tion goes outside of them. The total range of allowed motion is kept the same, but it is offset from its original centre such that the target rotation is at one of the limits. Once the target rotation returns to the original limits, the joint limits return to their original value. Implementing this solution would allows ragdolls to be set up with conservative limits without sacrificing animation quality.

7.2.5 Support for omitting intermediate bones

Hairibar.Ragdoll does not enforce any specific bone hierarchy. However, it does require the ragdoll to be set up in a certain way: all parents of a ragdoll bone must themselves be ragdoll bones. In other words, if a target bone is omitted from the ragdoll, all children of the omitted bone must be omitted as well. As an example, if a character’s rig features 3 spine bones, the ragdoll must have a Rigidbody per spine bone. The ragdoll can not be simplified such that their spine is composed of a single Rigidbody. This requirement could be eliminated by allowing a ragdoll bone to represent a chain of target bones where each bone is a child of the previous one. The child

75 deepest into the chain would be simulated as a ragdoll bone, while the rest of the chain would be omitted from the ragdoll. The ragdoll bone would match the combined local rotation of the whole chain. To maintain visual fidelity, the resulting local rotation of the ragdoll could be evenly distributed along the chain. The removal of this requirement would allow simpler ragdolls to be made even for complex character, reducing complexity and improving performance.

7.3 Closing

This thesis has proposed Animation Matching, a method that combines the strengths of keyframe-based animation and ragdolls. It has demonstrated how to implement this method in a way that is transparent for both animators and programmers, acting a post-processing layer. It has also introduced a set of intuitive parameters to control the ragdoll’s behaviour. Finally, a freely available implementation of the method for the Unity engine has been developed.

76 References

[1] ‘Dynamic Motion Synthesis - White Paper’ (2005): https: //web.archive.org/web/20100103165338/http://naturalmotion. com/files/white_paper_dms.pdf

[2] ‘Morpheme with Euphoria - Case Studies’, archived from original Natur- alMotion page. (2014) https://web.archive.org/web/20140714130720/ http://www.naturalmotion.com/middleware/euphoria

[3] ‘Euphoria - Partners’, archived from original NaturalMotion page. (2010) https://web.archive.org/web/20100301094216/http: //www.naturalmotion.com/euphoria.htm

[4] ‘NaturalMotion winding down commercial tech li- censing business for third-party developers’, Pocket- Gamer.biz (2017) https://www.pocketgamer.biz/news/65937/ naturalmotion-ends-commercial-tech-licensing-business/#: ~:text=NaturalMotion%20winding%20down%20commercial%20tech% 20licensing%20business%20for%20third%2Dparty%20developers& text=Zynga%2Downed%20NaturalMotion%20is%20set,Morpheme%20and% 20animation%20engine%20Euphoria.

[5] Public GitHub repository for Hairibar.Ragdoll: https://github.com/ hairibar/Hairibar.Ragdoll

[6] ‘Physics Animation in Uncharted 4: A Thief’s End‘, GDC Talk (2017)https://www.youtube.com/watch?v=7S-_vuoKgR4 [7] ‘Physics Driven Ragdolls and Animation at EA: From Sports to Star Wars’, GDC Talk (2018) https://www.gdcvault.com/browse/gdc-18/ play/1025210/Physics-Driven-Ragdolls-and-Animation

[8] ‘The unknowable chaos of physics in Totally Ac- curate Battle Simulator’, Rock Paper Shotgun (2020)https://www.rockpapershotgun.com/2020/01/15/ the-unknowable-chaos-of-physics-in-totally-accurate-battle-simulator/

[9] ‘Gang Beasts at 2014’s GDC European Innovative Games Showcase’ (2014)https://www.youtube.com/watch?v=eFeUyGLOlPA [10] Unity User Manualhttps://docs.unity3d.com/Manual/index.html [11] PhysX Documentation https://docs.nvidia.com/gameworks/content/ gameworkslibrary/physx/guide/Manual/Index.html

[12] ‘Animation Overview’, Unity User Manual https://docs.unity3d.com/ Manual/AnimationOverview.html

77 [13] ‘Order of Execution for Event Functions’, Unity User Manual https:// docs.unity3d.com/Manual/ExecutionOrder.html

[14] ‘What is Kanban?’, Atlassian https://www.atlassian.com/agile/ kanban

[15] Githttps://git-scm.com/ [16] ‘Developer Survey Results 2018‘, Stack Overflow (2018) https:// insights.stackoverflow.com/survey/2018#work-_-version-control

[17] Microsoft Visual Studio https://visualstudio.microsoft.com/vs/

[18] ‘Presskit - HacknPlan’ https://hacknplan.com/press/ [19] ‘A Successful Git Branching Model’, Vincent Driessen (2010) https:// nvie.com/posts/a-successful-git-branching-model/

[20] ‘Hairibar.Ragdoll Showcase’, YouTube https://youtu.be/ByNPbbACf40

78