Authoring Procedural Quadruped Gait in Game Engines With Input
Trent Riek
Abstract
My project is about authoring quadruped procedural animation in a game engine with proper gait movement and transitions without the use of imported animations.
Introduction
Introduction
Video Game’s aesthetic quality & complexity has evolved over the last two decades dramatically.
Video Games went from simple 3d models made of a dozen geometric objects, to simulating huge environments with detailed surfaces, lighting, physics, and AI systems. In fact, video games often have a duel purpose of being simulations.
Characters in video games have also improved…
Both humans and animals
But there are limitations to these simulations
Video games are limited in their ability to perfectly simulate real animations because of two key elements: Software constraints and Gameplay.
Video Games have to simulate elements at runtime. They have to carefully budget their resources to graphics, game logic, and AI, making complex algorithms unsuitable.
But, video games are also driven by gameplay. Gameplay is the engagement of a player in a game and their interactions with the rules.
Because video games must follow gameplay, the animation needs to run in relation to the gameplay - while also trying to look as realistic as possible.
Video Games solve the above issue with skeletal system - an abstracted skeleton is attached to a character mesh and then the skeleton is animated with a predefined set of rotations of the joints. The player hits a button, the animation plays. The skeleton and animations that can play are built in a different program and are imported to the engine.
This keeps the animation complexity very small, but it can frequently leave us with the issues we see above.
By creating additive animations, developers have overcome these challenges pretty well to animations; but these systems are still a) dependent on pre-made animations at their core and b) aren’t implemented completely for all types of animals.
To find a better solution for this issue (in particular for quadrupeds), I created procedural animations; I built a system in the Unreal Game engine that authors realistic & interactive movement for a quadruped (a Llama) within the game engine with no external help.
Background
Gait
A gait is a pattern of walking for an animal, in what order they move their appendages in order to move in a direction. Most creatures in the animal kingdom have a gait (not just creates with legs!) However, when we think about gait we typically refer to bipedal (two leg) and quadruped (four leg) animals.
Elements of a Gait
Gait types for most animals fall into a couple of common names; the walk, amble, trot, pace, canter, and gallop.
trot
gallop
Gait Choice
The gait an animal chooses is based primarily on:
Animals have evolved over time to fill different ecological niches and thus have different weight dispositions and leg types. The means there are optimal gaits for different speeds for a certain animal.
Horse Gait
The walk is a slow, symmetrical, four-beat gait. It is characterized by four distinct beats, where each hoof lands on the ground at a separate interval, independent of the other hooves.
Llama Gait
Llama Gait
Body Movement
In order to a body to fulfill a gait a body needs to move; it will take on a sinusoidal pattern of movement. The body can be abstracted into separate pieces which we can independently modify; this will allow easier implementation.
The movement the torso for both bipeds and quadrupeds have been shown to act like an inverted pendulum.
Leg Movement
Appendages in video games are typically adjusted for simulation through solvers - in particular IK (Inverse Kinematic) solvers. A solver is an algorithm for determining skeletal joint rotations.
Some type of solver will be useful for the legs if we already know the foot pattern of the animal.
Foot Movement
To get the foot position, it would make sense to have a gait system that determines the exact position of the foot.
Then foot can be animated, its position is passed the leg animation (which is dependent on the foot), and subsequently the leg passes its position to the body which uses the leg’s shoulder for its pendulum.
Alternative Methods
There have been multiple implementations of this in the past with different methods. These include difference approaches such
The implementation for this project is a combination of kinematics and pose driven - the desired feet positions are pre-determined, with the body adjusting its movement to match the desired pose.
Implementation
Unreal Game engine
The Unreal game engine is my engine of choice, and features a very robust animation suite that allows lots of readily available features.
Unreal Game engine
Also includes Blueprint Visual Scripting and access to source code
Gait Implementation
The Gait was implemented as a separate Actor component.
The gait system comprises of:
tickUpdate(deltatime){
CurrentVelocity = GetSpeed(deltatime);
UpdateCycle(deltatime);
For (foot in feet){
UpdateFootLocation();
CheckShouldFootMove();
}
}
Gait Implementation - speed
The System starts with a simple speed check - by getting the distance between the current location(c) and the previous location(p), multiplied by deltatime(Δ)
The value is bumped up by a constant so as to give it a significant amount (deltatime is very small).
Speed = dist(c,p) * Δ * const
Gait Implementation - cycle
The Cycle is then updated. A boolean checks if the cycle is active to update, if not checks for speed to start a cycle.
Each foot has an independent cycle. After the cycle is updated, the feet are looped through and each is checked if it is the correct time for it to cycle.
UpdateCycle(deltatime, gaitData){
if( isCycling ){
cyclePosition += currentSpeed * deltatime;
if(cyclePosition >= totalCycleTime) {
isCycling = false;
cyclePosition = 0;
}
}
else{
For each( gait in gaitData ){
If (speed > gait.MinnimumSpeed){
set currentGait;
set isCycling;
}
}
}
Leg implementation - solver
The Unreal engine has built in FABRIK and CCDIK multi joint solvers. However, these are proven to be insufficient for leg movement. Instead, one was built in c++.
The leg is abstracted into 3 parts:
Leg implementation - Shoulder
i is the initial foot position and T is the target foot position. The X and Z values are separate and multiplied by constants, after which are then normalized to a range to confine the rotation to a maximum Value M and minimum value 0.
To calculate the Scapula/Humerus rotations (shoulder), take the foot’s resting location and compare it to the target location.
The farther the distance, the more rotation. If it’s forward, the shoulder extends (rotates forward) and vice versa . Note that the scapula and humerus have opposite rotations.
XValue = NormalizeToRange( (abs(Tx - ix) * XConst), Mx)
ZValue = NormalizeToRange( (Clamp(Tz-iz) * ZConst), Mz)
Leg implementation - Foot & Lower leg.
The foot is positioned at the closest position to the target, using the total length of the leg making sure to use the scapula - elbow distance instead of the scapula Humerus.
The Knee is then calculated using a traditional ik solver.
TotalLegLength =
Size(Scapula - Elbow) + Size(Elbow - Knee) + Size(Knee - Ankle) + Size(Knee - Foot)
If (TotalLength > Distance(Scapula, T) {
FinalFootPos = Normalize(LookAtVector(Scapula, T)) * TotalLength
}
Else {
FinalFootPos = t
}
Body Implementation
The Body spine’s back and front heights are determined by the current feet’s up value. The middle spine values are then lerped between.
FrontSpineLocation = (LFFootZLoc + RFFootZLoc / 2) - ZLoc - Const
BackSpineLocation = (LBFootZLoc + RBFootZLoc / 2) - ZLoc - Const
Results
Conclusion
The system effectively Produces walking animations, keeps the legs (relatively) grounded, and properly transitions animations.
This project was a challenge primarily in the solving order of operations: elements had to be implemented in a correct order for this to work. And the skeletal hierarchy had to be accounted for.
Certain parts were challenging; the spine rotation surprisingly was difficult.
Questions