Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Like many of you, I've always been completely mesmerized watching
a game character move from a subtle fluid walk to
incredibly complex, responsive interactions. It feels like pure magic, right,
it really does. But how do developers achieve that level
of fluidity and realism? We often wonder what's really happening.
Speaker 2 (00:20):
Under the hood.
Speaker 3 (00:21):
Yeah, exactly.
Speaker 1 (00:22):
That's why we're taking a deep dive today into the fascinating,
intricate world of three D game animation programming. Our mission
today is to unpack the intricate details behind character animation
and world interaction. We're drawing from a rich set of sources,
particularly insights from a very practical book on C plus
plus game animation programming. Our goal is to give you
(00:44):
a shortcut to understanding these complex systems, revealing some surprising facts,
and connecting the dot so you can have some real
aha moments about your favorite games.
Speaker 3 (00:53):
Absolutely those moments where it clicks.
Speaker 1 (00:55):
Now, this deep dive pulls directly from material design for programmers,
but don't worry, We're going to a stracked the core concepts,
the why it matters, and how it works for anyone
curious about game development without getting too bogged down in
the code.
Speaker 3 (01:08):
Itself, right, focusing on the ideas behind it.
Speaker 1 (01:10):
Get ready to explore. Okay, let's unpack this then, what
exactly makes a character move in a three D game?
It's far more than just a static image being shifted
around exactly.
Speaker 3 (01:23):
You have to think of the character well, not as
one solid thing. It's actually built from a collection of points,
almost like hinges. We call these nodes, and they're basically
like the joints in your own body or elbows, knees, shoulders,
that sort of think God. All these nodes are connected
to form a virtual skeleton, often just called bones, and
it's the movement of these virtual bones that directly drives
(01:44):
the character's pose.
Speaker 2 (01:45):
So the skeleton is key, it's fundamental.
Speaker 3 (01:48):
And what's fascinating here, and maybe a real aha moment
is that instead of storing every single possible pose, which
would be mean an unimaginable amount of data, right that
would be huge, game only store a few key poses
at specific moments in time. These are the key frames.
The magic happens when the computer fills in the movements
(02:08):
between those key frames using some clever.
Speaker 1 (02:10):
Math ah interpolation exactly.
Speaker 3 (02:13):
For straightforward movement translation and scaling, it uses linear interpolation.
For rotations, which are trickier, it uses something called spherical
linear interpolation or slarrow psleric. This whole idea is really
the bedrock of smooth, data efficient animation. It lets you
have incredibly realistic movement without you know, completely crippling the
(02:36):
game's performance. But just animating the main skeleton. Well, that
isn't quite enough for true realism, is it.
Speaker 1 (02:42):
No, you need the finer details too.
Speaker 3 (02:44):
Right, So to capture things like expressions or small independent actions,
developers use other techniques. Morph animations, for instance, are crucial
for facial expressions like smiling or frowning, precisely where the
actual shape of the face mesh changes. Then you also
have additive animations. Think of these as overlays. Yeah, for
independent movements like a character nodding their head while they walk,
(03:07):
or maybe making a specific hand gesture. These are layered
on top of the main skeleton animations to add extra detail.
Speaker 1 (03:13):
Okay, so we've got these virtual skeletons. They're incredibly detailed,
even down to facial expressions and little gestures. But that's
just the blueprint, right, How do these intricate models actually
get into the game engine ready?
Speaker 2 (03:28):
To be animated.
Speaker 3 (03:29):
Good question. This is where an asset import library becomes
absolutely essential. A really common one is the open Asset
Import Library, usually just called.
Speaker 2 (03:39):
ASSIMP, a SIMP heard of it.
Speaker 3 (03:41):
Its whole job is to load character models from various
digital art files three D modeling software outputs. Basically, it
processes all the bits and pieces, the meshes, the textures,
these important nodes we talked about.
Speaker 1 (03:54):
And it handles different file types.
Speaker 3 (03:55):
Oh yeah, it's incredibly versable. Supports over fifty different file formats,
including common one like wavefront, dot of J and glTF THO.
It's worth noting some big ones like Autodesk's FBX or
proprietary so support can be tricky sometimes. So the loading
process generally involves loading this central data object like an
ascene that organizes everything. Then the game parses the internal structure,
(04:19):
the node hierarchy, pulls out the mesh data, the textures,
the bone info, and.
Speaker 1 (04:24):
Gets it ready for the graphics card.
Speaker 3 (04:25):
Exactly creating the vertex and index buffers all the stuff
the GPU needs to actually draw the character.
Speaker 1 (04:31):
Okay, so the characters loaded skeletons in place. That's one character.
But what happens when you scale this up. You know,
modern games can have hundreds, maybe thousands of characters on screen,
all needing complex animations. How do we handle all that
calculation without well slowing everything down to a crawl. That
feels like a huge challenge.
Speaker 3 (04:51):
It is, and this is where things get really interesting
from a performance perspective. Traditionally, all those calculations figuring out
the exact world position of every single joint or bone
for every character, that was all done by the main
processor with the CPU. But like you said, with hundreds
or thousands of characters, it becomes a massive, massive bottleneck.
It just completely bogs down the game. So the big
(05:14):
aha moment. The modern solution is moving these intense calculations
over to the GPU, the graphics card, using something called
compute shads.
Speaker 1 (05:25):
Compute shads okay, tell me more.
Speaker 3 (05:27):
Think of them as tiny, highly specialized programs that run
entirely on the GPU's parallel processors. They use something called
shader storage buffer objects or ssbos ssbos. Yeah, these are crucial.
They're basically flexible, high capacity memory areas on the GPU
that these compute shads can read and write to, unlike
(05:47):
older methods that were often read only.
Speaker 1 (05:49):
Ah so they can work with the data directly.
Speaker 3 (05:52):
Exactly, and the performance impact is huge. A single command
from the CPU can trigger literally tens of thousands, sometimes
hundreds of thousands of these shader calculations running all at
the same time across the GPU's course. Wow, it dramatically
frees up the CPU to handle other things like game
logic or AI. The source material we looked at showed
that even with two and a half times the number
(06:13):
of characters, the GPU calculation time was roughly half of
doing it on the CPU.
Speaker 2 (06:16):
That's a massive difference, it really is.
Speaker 3 (06:18):
Now Debugging them can be a bit tricky. They're kind
of a black box. You often need specialized tools from
Nvidia or AMD. Yeah, but the performance gain is undeniable.
Speaker 1 (06:26):
Okay, so the raw performance is there. Animations are running
super fast on the GPU, but how do we make
them smarter, more responsive, not just you know, the same
loop playing over and over.
Speaker 3 (06:37):
Right, that's the next layer. We introduce things like lookup
tables and state based animation control.
Speaker 1 (06:43):
Lookup tables.
Speaker 3 (06:45):
Yeah, instead of reclculating the exact pose between keyframes every
single frame at runtime, which still takes some time, the
game can actually pre calculate all those in between poses
when the model first loads, store them into table.
Speaker 1 (06:57):
Ah, so it's pre computation exactly.
Speaker 3 (07:00):
It's a classic trade off. You use more GPU memory
to store this table, but you get much much faster
look up. During gameplay, every movement feels.
Speaker 1 (07:07):
Instantaneous I see and state based control.
Speaker 3 (07:11):
This is about making the character react intelligently. Characters don't
just loop one animation endlessly. They switch between states standing, idle, walking, running,
maybe jumping or attacking.
Speaker 1 (07:21):
Yeah, depending on what the player.
Speaker 3 (07:22):
Does precisely, so the system blends between these animations. It
uses math, often involving factors like how fast the character
is moving or if they're speeding up or slowing down,
to create really natural transitions between say, walking and running.
So it smooths it out, yeah, no jerky changes. And
these states are managed using what's called a finite state machine.
(07:45):
Think of it like a float chart or a set
of rules.
Speaker 1 (07:47):
Okay.
Speaker 3 (07:47):
It dictates exactly when a character should switch from idle
to walk, or from walk to run, or maybe trigger
a specific action animation based on player input or game events.
Speaker 1 (07:58):
So, putting it all together, what's the result for us,
the players? We're not just seeing puppets on strings.
Speaker 3 (08:03):
Not at all. We're seeing characters with dynamic, context aware
motion movement that feels natural, responsive, and believable because it's
reacting intelligently to the situation.
Speaker 1 (08:15):
That makes a huge difference to immersion. Okay, so characters exist,
they move naturally, but they don't exist in avoid right.
They need to navigate a world, interact with it, maybe
interact with each other. That journey from just a model
to an interactive agent. That seems like another big step.
Speaker 3 (08:32):
It absolutely is. Let's talk about some core mechanics for
that world interaction. First up, something seemingly simple, visual selection.
How do you the player click on one specific character
when there might be dozens on screen?
Speaker 2 (08:48):
Yeah?
Speaker 1 (08:48):
How does the game know which one?
Speaker 2 (08:49):
I meant?
Speaker 3 (08:50):
One? Really effective approach is basically drawing the instance index
into a texture. It uses a concept similar to a
g buffer, which you might know from.
Speaker 1 (08:59):
Deferred capturing scene data in layers.
Speaker 3 (09:02):
Exactly, you render a hidden image where each character is
drawn with a unique color or ID. When you click,
the game just looks up the idea at that pixel coordinate.
Speaker 1 (09:11):
Ah.
Speaker 2 (09:11):
Very clever, and the beauty is the.
Speaker 3 (09:13):
Overhead is constant. It doesn't really matter how many characters
are on screen, the look up time is the same,
much better than say, trying to shoot a virtual ray
and see what it hits.
Speaker 1 (09:22):
Definitely more efficient.
Speaker 3 (09:23):
And you can even implement a null object ID for
the background, so clicking anywhere else cleanly deselects whatever you
had selected.
Speaker 1 (09:31):
Simple but neat, nice little touches. What about controlling things
during development?
Speaker 3 (09:37):
Right application control? Yeah, Features like underrato are super important
when treaking things. This is often done using the command pattern.
The command pattern it's a programming design pattern where you
basically wrap up an action like changing a character setting
into an object. You can store these objects, run them,
undo them, redo them.
Speaker 2 (09:56):
Very powerful for tools, makes sense for iterating, and of course.
Speaker 3 (10:00):
You need saving and loading configurations absolutely critical. You have
choices here. Binary data is fast to load and small,
but it's often not portable between different versions or systems
right brittle Yeah. Textual data, on the other hand, is
human readable, much more flexible. The sorce material we're drawing
from actually.
Speaker 2 (10:19):
Ops for Yammal Yammil.
Speaker 3 (10:21):
Why Yamal because it's quite readable. It has a nice
structure with nodes, maps and sequences. It integrates well with libraries,
like yammal CTP, plus you can build inversioning and in
good error handling when reading the files back in.
Speaker 1 (10:35):
Okay, practical choices, so characters can be selected, settings, tweaked
and saved. Now the really interactive part collisions and moving.
Speaker 3 (10:43):
Around absolutely fundamental collision detection, but checking every single tiny
triangle of every model against every other triangle computationally insane. Yeah,
so you use simplifications model abstractions. Game engines first use
things like access aligned bound boxes AABBS just an invisible
box tightly around the character, or maybe bounding.
Speaker 2 (11:04):
Spheres, or a quick first check.
Speaker 3 (11:06):
Exactly ye broad phase check. If the simple boxes don't
overlap the complex models inside, definitely it do on it either.
It saves a ton of work smart and to avoid
checking every character against every other character, use spatial partitioning
data structures like quad trees for two D worlds or
oc trees for three.
Speaker 1 (11:22):
D, dividing up the space.
Speaker 3 (11:24):
Precisely you divide the world into smaller regions. An object
only needs to check for collisions with other objects in
the same region or neighboring regions. There are other methods too,
like BSP trees used back in the original doom, but
octrees are very common for level geometry collision in three D.
Speaker 1 (11:41):
Okay, that makes sense, and gravity seems basic but important.
Speaker 3 (11:45):
Oh vital a simple gravity constant, you know, like nine
point eight one meter ros cart. It's constantly applied pulling
characters downwards. The system checks if they're hitting ground triangles
from the level geometry to stop them falling through the world.
It keeps things grounded literally.
Speaker 1 (12:00):
Essential for believability. Now you mentioned something really intricate earlier,
inverse kinematics.
Speaker 3 (12:05):
Ik ah, yes, ik This is where it gets really cool,
especially for a realistic leg movement on uneven terrain like
slopes or stairs.
Speaker 1 (12:13):
To stop feet going through.
Speaker 3 (12:14):
The floor exactly or floating weirdly above it, an algorithm
like fabric that stands for forward and backward reaching inverse
kinematics is often used instead of pants takingly animating every
single joint in the leg. For every possible slope bangle,
You define an end defector basically the character's foot and
a target position on the ground.
Speaker 1 (12:33):
Okay.
Speaker 3 (12:34):
The fabric algorithm then automatically calculates all the necessary joint rotations,
the knee bend, the hip angle required for the foot
to reach that target naturally.
Speaker 1 (12:43):
Wow. So the system figures out the pose pretty much.
Speaker 3 (12:46):
Yeah, it ensures the feet plant realistically on the surface,
adapting to the terrain. Huge for immersion, no more foot skating.
Speaker 1 (12:53):
That is a huge win. Okay, so the character knows
where the ground is their feet stick to it. But
how do they know where to go? A complex level?
How do they navigate?
Speaker 3 (13:01):
Right? Navigation? Lots of ways to approach this. You've got
simpler methods like distance based navigation think pac Man ghosts
trying to close the distance, then more complex graph based
navigation using algorithms to find paths through connected points, and
even machine learning approaches these days. But a very common
and powerful technique involves navigation meshes.
Speaker 1 (13:24):
Nav meshes, right, I've heard of those.
Speaker 3 (13:26):
They're basically pre calculated maps of all the walkable areas
in the level, a simplified representation of the ground the
character can actually move on. This avoids tons of expensive
collision checks with all the static level geometry during.
Speaker 1 (13:39):
Pathfinding, so it's like a simplified map just for movement exactly.
Speaker 3 (13:43):
And the core algorithm used with nav meshes is very
often a pathfinding a star.
Speaker 2 (13:48):
A star that's the famous one it is.
Speaker 3 (13:50):
It's a smart graph based algorithm. It finds the shortest
path by balancing the actual cost proveled so far from
the start point with a heuristic kind of educated guess
of the remaining cost to reach the target.
Speaker 1 (14:03):
So it's efficient and finds good paths generally.
Speaker 3 (14:06):
Yes. In the source we looked at, the knapmash is
generated directly from the level's wokable ground triangles, and the
a algorithm uses simple Euclidian distance for its costs calculations.
Characters can then navigate between pre defined points on this mash,
often called waypoints, where navigation targets.
Speaker 1 (14:22):
So what does this mean for the player experience? Really,
we're moving way beyond just sliding models around.
Speaker 3 (14:27):
Absolutely, we're giving these characters intelligence, a physical presence in
the world. They can understand the environment, find their way
through it, interact with it physically. They become truly part
of that virtual space.
Speaker 1 (14:38):
It's amazing how many layers there are. Okay, we've built
the characters, given them realistic movement intelligence to navigate. Now
let's talk about the world itself, making it more alive
and immersive. How does level data differ from character models?
Speaker 3 (14:52):
Good distinction level data is fundamentally different. Typically, level geometry
is static, non movable, non anim.
Speaker 1 (15:00):
Made it right buildings terrain.
Speaker 3 (15:02):
Exactly, And this is actually a big advantage. Because it's static,
you can pre calculate a lot of expensive stuff during
development and bake it into the level data, like what
things like light maps, pre calculated lighting and shadows, saving
huge amounts of real time computation. Yeah, those navigation matches
we just discussed, and also hierarchical level of detail or HLODE. Yeah,
(15:23):
these are simplified versions of distant parts of the level geometry.
As things get further away, the game swaps in simpler
models to save rendering power. All this can be biggd.
Speaker 2 (15:32):
In I see. Optimization is key absolutely when loading levels.
Speaker 3 (15:37):
Again, a library like a SIMP can handle various formats
wayfront glTF, but some level specific or engine specific formats exist,
and things like FBX are still proprietary for collision. With
this static level geometry, the system often uses that three
D octree structure we mentioned to manage checks efficiently.
Speaker 1 (15:56):
Makes sense now, beyond just the visuals of the level,
what other sense do we engage to build immersion? A
game isn't just what you see is it.
Speaker 3 (16:04):
Not at all? Sound plays a huge, often really underestimated
role in immersion house se well. Sound effects are crucial
for feedback. Think about footsteps often managed by specific audio
libraries like SDL mixer, the sound jumping, character vocalizations.
Speaker 2 (16:18):
Impact Yeah, tells you what's happening exactly.
Speaker 3 (16:21):
And local sound sources too. Hearing an enemy moving just
around the corner gives you vital gameplay information.
Speaker 2 (16:26):
And then there's music, ambience and mood.
Speaker 3 (16:29):
Right, you've got menu music, ambient music to set the atmosphere,
and even adaptive music that subtly changes based on what's
happening in the game, intensifying during combat, calming down during exploration.
It really enhances the mood and engagement.
Speaker 2 (16:43):
Definitely.
Speaker 1 (16:44):
Okay, Finally, how do we make the world itself feel
truly dynamic, truly alive, Moving beyond just static environments, however
beautifully lit or sounded they are.
Speaker 3 (16:55):
This is where environmental changes really shine. So visually, there's
a ton we can do. We can break and realistic
colors and material responses with physically based.
Speaker 2 (17:03):
Rendering pr PBR.
Speaker 1 (17:05):
Yeah, that's everywhere.
Speaker 3 (17:06):
Now, it is. We can add transparency for things like
glass or water use a skybox that's usually a big
cube map projected onto an invisible cube surrounding the scene
to give a realistic sense of sky and distance the background.
Implement dynamic lights and shadows that move and change, Simulate
realistic water with reflections, refractions, distortions, and apply all sorts
of stunning post processing.
Speaker 2 (17:27):
Effects like what kind of effects?
Speaker 3 (17:29):
Oh, things like lens flares, god rays streaming through trees
bloom to make bright lights glow, motion blur, screen space
ambient occlusion or SSAO to add subtle contact shadows.
Speaker 1 (17:42):
Okay, lots of acronyms.
Speaker 3 (17:43):
There, Yes, SSAO and screen space reflection SSR for reflections
on surfaces and for really cutting edge visuals. You start
talking about ray tracing for hyperrealistic lighting and shadows, and
even virtual reality VR for total.
Speaker 2 (17:59):
Immergion, bushing the boundaries and beyond.
Speaker 3 (18:01):
Just looking good. The world itself can change over time.
Think about a day night cycle like in Minecraft. Maybe
a twenty minute cycle from dawn to dusk tonight.
Speaker 2 (18:09):
Changes the whole feel completely.
Speaker 3 (18:11):
Add weather effects, rain, snow, fog, even seasons like you
see in games like Legend of Zelda, Oracle of Seasons
or Stardou valley. These things fundamentally alter the world's appearance
and can even affect gameplay or character behavior. You implement
light control to simulate the sun and moon moving, changing color, temperature.
It brings the environment truly alive.
Speaker 1 (18:30):
Wow. So we've really taken a journey today from you know,
the basic building blocks, the polygons.
Speaker 2 (18:35):
And nodes, the virtual skeleton.
Speaker 1 (18:38):
To optimizing animations with GPUs, making characters move intelligently with
things like A and IK.
Speaker 3 (18:44):
Right, navigating and interacting.
Speaker 1 (18:46):
And finally crafting these incredibly immersive worlds with dynamic lighting, sound,
and even weather that changes over time.
Speaker 3 (18:53):
It's quite something when you break it down. What seems
almost effortless on the screen, you know, a character just
walking cross uneven ground. Yeah, it's actually this masterful orchestration
of complex mathematics, really sophisticated data structures like oc trees
and nav meshes, and some very clever programming techniques. Every
subtle movement, every interaction, every shadow or reflection, it's all
(19:16):
meticulously engineered, often invisible, but always impressive.
Speaker 1 (19:20):
It really is. So the next time you pick up
a game, maybe plus for a second, what hidden layers
of incredible engineering will you find yourself wondering about now,
how am I thinking about the challenges of, say, creating
an infinitely distant sky with just a symbol textured box,
or the complex ik calculations needed just for a character's
foot to land correctly on a bumpy slope. How might
(19:43):
that change your perspective on the virtual worlds.
Speaker 3 (19:45):
You explore, something to think about
Speaker 1 (19:47):
Stay curious, keep exploring, and remember there's always more to learn.