WEBVTT 1 00:00:00.240 --> 00:00:03.359 Like many of you, I've always been completely mesmerized watching 2 00:00:03.399 --> 00:00:07.320 a game character move from a subtle fluid walk to 3 00:00:08.039 --> 00:00:13.560 incredibly complex, responsive interactions. It feels like pure magic, right, 4 00:00:13.679 --> 00:00:16.760 it really does. But how do developers achieve that level 5 00:00:16.839 --> 00:00:21.039 of fluidity and realism? We often wonder what's really happening. 6 00:00:20.800 --> 00:00:21.359 Under the hood. 7 00:00:21.480 --> 00:00:22.359 Yeah, exactly. 8 00:00:22.640 --> 00:00:25.679 That's why we're taking a deep dive today into the fascinating, 9 00:00:25.839 --> 00:00:30.320 intricate world of three D game animation programming. Our mission 10 00:00:30.359 --> 00:00:33.840 today is to unpack the intricate details behind character animation 11 00:00:34.039 --> 00:00:37.840 and world interaction. We're drawing from a rich set of sources, 12 00:00:37.880 --> 00:00:41.640 particularly insights from a very practical book on C plus 13 00:00:41.640 --> 00:00:44.600 plus game animation programming. Our goal is to give you 14 00:00:44.600 --> 00:00:48.799 a shortcut to understanding these complex systems, revealing some surprising facts, 15 00:00:49.119 --> 00:00:50.960 and connecting the dot so you can have some real 16 00:00:51.039 --> 00:00:53.119 aha moments about your favorite games. 17 00:00:53.159 --> 00:00:54.960 Absolutely those moments where it clicks. 18 00:00:55.280 --> 00:00:58.679 Now, this deep dive pulls directly from material design for programmers, 19 00:00:58.719 --> 00:01:01.600 but don't worry, We're going to a stracked the core concepts, 20 00:01:01.640 --> 00:01:04.920 the why it matters, and how it works for anyone 21 00:01:05.040 --> 00:01:08.200 curious about game development without getting too bogged down in 22 00:01:08.239 --> 00:01:08.879 the code. 23 00:01:08.599 --> 00:01:10.640 Itself, right, focusing on the ideas behind it. 24 00:01:10.680 --> 00:01:14.200 Get ready to explore. Okay, let's unpack this then, what 25 00:01:14.400 --> 00:01:17.560 exactly makes a character move in a three D game? 26 00:01:17.799 --> 00:01:22.040 It's far more than just a static image being shifted 27 00:01:22.040 --> 00:01:23.159 around exactly. 28 00:01:23.280 --> 00:01:25.239 You have to think of the character well, not as 29 00:01:25.280 --> 00:01:29.879 one solid thing. It's actually built from a collection of points, 30 00:01:29.920 --> 00:01:32.719 almost like hinges. We call these nodes, and they're basically 31 00:01:32.760 --> 00:01:35.159 like the joints in your own body or elbows, knees, shoulders, 32 00:01:35.159 --> 00:01:37.799 that sort of think God. All these nodes are connected 33 00:01:37.799 --> 00:01:41.359 to form a virtual skeleton, often just called bones, and 34 00:01:41.400 --> 00:01:44.280 it's the movement of these virtual bones that directly drives 35 00:01:44.319 --> 00:01:45.159 the character's pose. 36 00:01:45.400 --> 00:01:47.879 So the skeleton is key, it's fundamental. 37 00:01:48.040 --> 00:01:51.239 And what's fascinating here, and maybe a real aha moment 38 00:01:51.840 --> 00:01:55.599 is that instead of storing every single possible pose, which 39 00:01:55.640 --> 00:01:58.359 would be mean an unimaginable amount of data, right that 40 00:01:58.400 --> 00:02:02.079 would be huge, game only store a few key poses 41 00:02:02.280 --> 00:02:05.239 at specific moments in time. These are the key frames. 42 00:02:05.719 --> 00:02:08.400 The magic happens when the computer fills in the movements 43 00:02:08.400 --> 00:02:10.960 between those key frames using some clever. 44 00:02:10.800 --> 00:02:13.840 Math ah interpolation exactly. 45 00:02:13.759 --> 00:02:18.560 For straightforward movement translation and scaling, it uses linear interpolation. 46 00:02:19.439 --> 00:02:22.879 For rotations, which are trickier, it uses something called spherical 47 00:02:23.199 --> 00:02:27.639 linear interpolation or slarrow psleric. This whole idea is really 48 00:02:27.719 --> 00:02:31.360 the bedrock of smooth, data efficient animation. It lets you 49 00:02:31.400 --> 00:02:36.280 have incredibly realistic movement without you know, completely crippling the 50 00:02:36.280 --> 00:02:39.879 game's performance. But just animating the main skeleton. Well, that 51 00:02:39.960 --> 00:02:41.960 isn't quite enough for true realism, is it. 52 00:02:42.400 --> 00:02:44.439 No, you need the finer details too. 53 00:02:44.560 --> 00:02:48.960 Right, So to capture things like expressions or small independent actions, 54 00:02:49.400 --> 00:02:53.680 developers use other techniques. Morph animations, for instance, are crucial 55 00:02:53.719 --> 00:02:57.000 for facial expressions like smiling or frowning, precisely where the 56 00:02:57.039 --> 00:02:59.919 actual shape of the face mesh changes. Then you also 57 00:02:59.919 --> 00:03:03.759 have additive animations. Think of these as overlays. Yeah, for 58 00:03:03.800 --> 00:03:07.280 independent movements like a character nodding their head while they walk, 59 00:03:07.400 --> 00:03:10.479 or maybe making a specific hand gesture. These are layered 60 00:03:10.479 --> 00:03:13.479 on top of the main skeleton animations to add extra detail. 61 00:03:13.960 --> 00:03:17.639 Okay, so we've got these virtual skeletons. They're incredibly detailed, 62 00:03:17.800 --> 00:03:22.199 even down to facial expressions and little gestures. But that's 63 00:03:22.400 --> 00:03:26.919 just the blueprint, right, How do these intricate models actually 64 00:03:26.960 --> 00:03:28.919 get into the game engine ready? 65 00:03:28.960 --> 00:03:29.599 To be animated. 66 00:03:29.800 --> 00:03:34.159 Good question. This is where an asset import library becomes 67 00:03:34.199 --> 00:03:37.719 absolutely essential. A really common one is the open Asset 68 00:03:37.759 --> 00:03:39.840 Import Library, usually just called. 69 00:03:39.719 --> 00:03:41.800 ASSIMP, a SIMP heard of it. 70 00:03:41.800 --> 00:03:44.680 Its whole job is to load character models from various 71 00:03:44.960 --> 00:03:48.960 digital art files three D modeling software outputs. Basically, it 72 00:03:49.039 --> 00:03:52.560 processes all the bits and pieces, the meshes, the textures, 73 00:03:52.560 --> 00:03:54.120 these important nodes we talked about. 74 00:03:54.000 --> 00:03:55.360 And it handles different file types. 75 00:03:55.439 --> 00:03:59.159 Oh yeah, it's incredibly versable. Supports over fifty different file formats, 76 00:03:59.159 --> 00:04:03.360 including common one like wavefront, dot of J and glTF THO. 77 00:04:03.400 --> 00:04:06.800 It's worth noting some big ones like Autodesk's FBX or 78 00:04:06.840 --> 00:04:10.159 proprietary so support can be tricky sometimes. So the loading 79 00:04:10.199 --> 00:04:14.280 process generally involves loading this central data object like an 80 00:04:14.319 --> 00:04:19.639 ascene that organizes everything. Then the game parses the internal structure, 81 00:04:19.839 --> 00:04:23.040 the node hierarchy, pulls out the mesh data, the textures, 82 00:04:23.079 --> 00:04:24.120 the bone info, and. 83 00:04:24.079 --> 00:04:25.600 Gets it ready for the graphics card. 84 00:04:25.560 --> 00:04:28.600 Exactly creating the vertex and index buffers all the stuff 85 00:04:28.639 --> 00:04:31.319 the GPU needs to actually draw the character. 86 00:04:31.720 --> 00:04:35.199 Okay, so the characters loaded skeletons in place. That's one character. 87 00:04:35.639 --> 00:04:38.399 But what happens when you scale this up. You know, 88 00:04:38.920 --> 00:04:42.920 modern games can have hundreds, maybe thousands of characters on screen, 89 00:04:43.040 --> 00:04:46.720 all needing complex animations. How do we handle all that 90 00:04:46.759 --> 00:04:50.480 calculation without well slowing everything down to a crawl. That 91 00:04:50.480 --> 00:04:51.879 feels like a huge challenge. 92 00:04:51.959 --> 00:04:54.480 It is, and this is where things get really interesting 93 00:04:54.480 --> 00:04:58.759 from a performance perspective. Traditionally, all those calculations figuring out 94 00:04:58.800 --> 00:05:01.560 the exact world position of every single joint or bone 95 00:05:01.600 --> 00:05:04.040 for every character, that was all done by the main 96 00:05:04.160 --> 00:05:07.079 processor with the CPU. But like you said, with hundreds 97 00:05:07.160 --> 00:05:11.120 or thousands of characters, it becomes a massive, massive bottleneck. 98 00:05:11.480 --> 00:05:14.480 It just completely bogs down the game. So the big 99 00:05:14.519 --> 00:05:19.079 aha moment. The modern solution is moving these intense calculations 100 00:05:19.439 --> 00:05:23.600 over to the GPU, the graphics card, using something called 101 00:05:24.000 --> 00:05:25.079 compute shads. 102 00:05:25.319 --> 00:05:27.360 Compute shads okay, tell me more. 103 00:05:27.560 --> 00:05:30.759 Think of them as tiny, highly specialized programs that run 104 00:05:30.920 --> 00:05:34.720 entirely on the GPU's parallel processors. They use something called 105 00:05:34.759 --> 00:05:40.360 shader storage buffer objects or ssbos ssbos. Yeah, these are crucial. 106 00:05:40.360 --> 00:05:44.360 They're basically flexible, high capacity memory areas on the GPU 107 00:05:44.720 --> 00:05:47.759 that these compute shads can read and write to, unlike 108 00:05:47.800 --> 00:05:49.759 older methods that were often read only. 109 00:05:49.680 --> 00:05:52.360 Ah so they can work with the data directly. 110 00:05:52.079 --> 00:05:55.480 Exactly, and the performance impact is huge. A single command 111 00:05:55.480 --> 00:05:59.160 from the CPU can trigger literally tens of thousands, sometimes 112 00:05:59.279 --> 00:06:02.399 hundreds of thousands of these shader calculations running all at 113 00:06:02.439 --> 00:06:06.120 the same time across the GPU's course. Wow, it dramatically 114 00:06:06.120 --> 00:06:08.319 frees up the CPU to handle other things like game 115 00:06:08.399 --> 00:06:11.439 logic or AI. The source material we looked at showed 116 00:06:11.439 --> 00:06:12.959 that even with two and a half times the number 117 00:06:13.000 --> 00:06:15.839 of characters, the GPU calculation time was roughly half of 118 00:06:15.839 --> 00:06:16.680 doing it on the CPU. 119 00:06:16.800 --> 00:06:18.519 That's a massive difference, it really is. 120 00:06:18.720 --> 00:06:20.959 Now Debugging them can be a bit tricky. They're kind 121 00:06:21.000 --> 00:06:23.160 of a black box. You often need specialized tools from 122 00:06:23.240 --> 00:06:26.639 Nvidia or AMD. Yeah, but the performance gain is undeniable. 123 00:06:26.759 --> 00:06:30.040 Okay, so the raw performance is there. Animations are running 124 00:06:30.160 --> 00:06:33.000 super fast on the GPU, but how do we make 125 00:06:33.000 --> 00:06:36.079 them smarter, more responsive, not just you know, the same 126 00:06:36.240 --> 00:06:37.560 loop playing over and over. 127 00:06:37.879 --> 00:06:40.759 Right, that's the next layer. We introduce things like lookup 128 00:06:40.759 --> 00:06:43.600 tables and state based animation control. 129 00:06:43.839 --> 00:06:44.839 Lookup tables. 130 00:06:45.000 --> 00:06:49.240 Yeah, instead of reclculating the exact pose between keyframes every 131 00:06:49.240 --> 00:06:52.360 single frame at runtime, which still takes some time, the 132 00:06:52.399 --> 00:06:55.000 game can actually pre calculate all those in between poses 133 00:06:55.040 --> 00:06:57.720 when the model first loads, store them into table. 134 00:06:57.839 --> 00:07:00.199 Ah, so it's pre computation exactly. 135 00:07:00.199 --> 00:07:02.920 It's a classic trade off. You use more GPU memory 136 00:07:02.959 --> 00:07:05.519 to store this table, but you get much much faster 137 00:07:05.639 --> 00:07:08.199 look up. During gameplay, every movement feels. 138 00:07:07.959 --> 00:07:10.839 Instantaneous I see and state based control. 139 00:07:11.240 --> 00:07:14.720 This is about making the character react intelligently. Characters don't 140 00:07:14.759 --> 00:07:19.920 just loop one animation endlessly. They switch between states standing, idle, walking, running, 141 00:07:19.959 --> 00:07:21.160 maybe jumping or attacking. 142 00:07:21.319 --> 00:07:22.680 Yeah, depending on what the player. 143 00:07:22.519 --> 00:07:26.000 Does precisely, so the system blends between these animations. It 144 00:07:26.120 --> 00:07:29.959 uses math, often involving factors like how fast the character 145 00:07:30.040 --> 00:07:32.319 is moving or if they're speeding up or slowing down, 146 00:07:32.759 --> 00:07:37.800 to create really natural transitions between say, walking and running. 147 00:07:37.920 --> 00:07:40.920 So it smooths it out, yeah, no jerky changes. And 148 00:07:41.040 --> 00:07:44.959 these states are managed using what's called a finite state machine. 149 00:07:45.199 --> 00:07:46.839 Think of it like a float chart or a set 150 00:07:46.839 --> 00:07:47.279 of rules. 151 00:07:47.399 --> 00:07:47.720 Okay. 152 00:07:47.839 --> 00:07:50.639 It dictates exactly when a character should switch from idle 153 00:07:50.680 --> 00:07:53.959 to walk, or from walk to run, or maybe trigger 154 00:07:54.000 --> 00:07:57.959 a specific action animation based on player input or game events. 155 00:07:58.160 --> 00:08:01.199 So, putting it all together, what's the result for us, 156 00:08:01.240 --> 00:08:03.439 the players? We're not just seeing puppets on strings. 157 00:08:03.480 --> 00:08:08.000 Not at all. We're seeing characters with dynamic, context aware 158 00:08:08.079 --> 00:08:13.639 motion movement that feels natural, responsive, and believable because it's 159 00:08:13.680 --> 00:08:15.560 reacting intelligently to the situation. 160 00:08:15.959 --> 00:08:19.120 That makes a huge difference to immersion. Okay, so characters exist, 161 00:08:19.160 --> 00:08:22.759 they move naturally, but they don't exist in avoid right. 162 00:08:22.800 --> 00:08:25.600 They need to navigate a world, interact with it, maybe 163 00:08:25.600 --> 00:08:29.120 interact with each other. That journey from just a model 164 00:08:29.319 --> 00:08:32.120 to an interactive agent. That seems like another big step. 165 00:08:32.480 --> 00:08:35.840 It absolutely is. Let's talk about some core mechanics for 166 00:08:35.960 --> 00:08:42.080 that world interaction. First up, something seemingly simple, visual selection. 167 00:08:43.039 --> 00:08:46.320 How do you the player click on one specific character 168 00:08:46.519 --> 00:08:48.200 when there might be dozens on screen? 169 00:08:48.320 --> 00:08:48.519 Yeah? 170 00:08:48.559 --> 00:08:49.600 How does the game know which one? 171 00:08:49.639 --> 00:08:50.080 I meant? 172 00:08:50.360 --> 00:08:55.120 One? Really effective approach is basically drawing the instance index 173 00:08:55.159 --> 00:08:58.000 into a texture. It uses a concept similar to a 174 00:08:58.039 --> 00:08:59.600 g buffer, which you might know from. 175 00:08:59.519 --> 00:09:02.679 Deferred capturing scene data in layers. 176 00:09:02.879 --> 00:09:05.960 Exactly, you render a hidden image where each character is 177 00:09:06.039 --> 00:09:08.679 drawn with a unique color or ID. When you click, 178 00:09:08.759 --> 00:09:11.240 the game just looks up the idea at that pixel coordinate. 179 00:09:11.320 --> 00:09:11.600 Ah. 180 00:09:11.720 --> 00:09:13.480 Very clever, and the beauty is the. 181 00:09:13.440 --> 00:09:16.399 Overhead is constant. It doesn't really matter how many characters 182 00:09:16.440 --> 00:09:18.399 are on screen, the look up time is the same, 183 00:09:19.000 --> 00:09:21.639 much better than say, trying to shoot a virtual ray 184 00:09:21.679 --> 00:09:22.480 and see what it hits. 185 00:09:22.759 --> 00:09:23.679 Definitely more efficient. 186 00:09:23.879 --> 00:09:26.799 And you can even implement a null object ID for 187 00:09:26.840 --> 00:09:30.879 the background, so clicking anywhere else cleanly deselects whatever you 188 00:09:30.919 --> 00:09:31.480 had selected. 189 00:09:31.919 --> 00:09:36.039 Simple but neat, nice little touches. What about controlling things 190 00:09:36.159 --> 00:09:36.960 during development? 191 00:09:37.120 --> 00:09:41.399 Right application control? Yeah, Features like underrato are super important 192 00:09:41.399 --> 00:09:45.480 when treaking things. This is often done using the command pattern. 193 00:09:45.799 --> 00:09:48.480 The command pattern it's a programming design pattern where you 194 00:09:48.519 --> 00:09:52.000 basically wrap up an action like changing a character setting 195 00:09:52.320 --> 00:09:55.159 into an object. You can store these objects, run them, 196 00:09:55.240 --> 00:09:56.440 undo them, redo them. 197 00:09:56.759 --> 00:10:00.120 Very powerful for tools, makes sense for iterating, and of course. 198 00:10:00.200 --> 00:10:03.879 You need saving and loading configurations absolutely critical. You have 199 00:10:04.000 --> 00:10:07.519 choices here. Binary data is fast to load and small, 200 00:10:08.039 --> 00:10:11.039 but it's often not portable between different versions or systems 201 00:10:11.120 --> 00:10:15.240 right brittle Yeah. Textual data, on the other hand, is 202 00:10:15.480 --> 00:10:19.200 human readable, much more flexible. The sorce material we're drawing 203 00:10:19.200 --> 00:10:19.879 from actually. 204 00:10:19.679 --> 00:10:21.159 Ops for Yammal Yammil. 205 00:10:21.399 --> 00:10:24.080 Why Yamal because it's quite readable. It has a nice 206 00:10:24.080 --> 00:10:29.159 structure with nodes, maps and sequences. It integrates well with libraries, 207 00:10:29.279 --> 00:10:32.559 like yammal CTP, plus you can build inversioning and in 208 00:10:32.639 --> 00:10:34.919 good error handling when reading the files back in. 209 00:10:35.120 --> 00:10:39.480 Okay, practical choices, so characters can be selected, settings, tweaked 210 00:10:39.519 --> 00:10:43.480 and saved. Now the really interactive part collisions and moving. 211 00:10:43.279 --> 00:10:48.159 Around absolutely fundamental collision detection, but checking every single tiny 212 00:10:48.279 --> 00:10:52.960 triangle of every model against every other triangle computationally insane. Yeah, 213 00:10:53.840 --> 00:10:58.240 so you use simplifications model abstractions. Game engines first use 214 00:10:58.320 --> 00:11:02.440 things like access aligned bound boxes AABBS just an invisible 215 00:11:02.480 --> 00:11:05.240 box tightly around the character, or maybe bounding. 216 00:11:04.919 --> 00:11:06.559 Spheres, or a quick first check. 217 00:11:06.480 --> 00:11:09.480 Exactly ye broad phase check. If the simple boxes don't 218 00:11:09.480 --> 00:11:12.360 overlap the complex models inside, definitely it do on it either. 219 00:11:12.480 --> 00:11:14.639 It saves a ton of work smart and to avoid 220 00:11:14.720 --> 00:11:18.919 checking every character against every other character, use spatial partitioning 221 00:11:19.480 --> 00:11:22.080 data structures like quad trees for two D worlds or 222 00:11:22.120 --> 00:11:23.039 oc trees for three. 223 00:11:22.960 --> 00:11:24.519 D, dividing up the space. 224 00:11:24.279 --> 00:11:28.519 Precisely you divide the world into smaller regions. An object 225 00:11:28.559 --> 00:11:31.039 only needs to check for collisions with other objects in 226 00:11:31.080 --> 00:11:34.519 the same region or neighboring regions. There are other methods too, 227 00:11:34.960 --> 00:11:38.360 like BSP trees used back in the original doom, but 228 00:11:38.440 --> 00:11:41.440 octrees are very common for level geometry collision in three D. 229 00:11:41.720 --> 00:11:45.559 Okay, that makes sense, and gravity seems basic but important. 230 00:11:45.639 --> 00:11:48.679 Oh vital a simple gravity constant, you know, like nine 231 00:11:48.679 --> 00:11:51.720 point eight one meter ros cart. It's constantly applied pulling 232 00:11:51.759 --> 00:11:55.320 characters downwards. The system checks if they're hitting ground triangles 233 00:11:55.320 --> 00:11:57.799 from the level geometry to stop them falling through the world. 234 00:11:58.000 --> 00:12:00.240 It keeps things grounded literally. 235 00:12:00.159 --> 00:12:03.559 Essential for believability. Now you mentioned something really intricate earlier, 236 00:12:03.600 --> 00:12:04.559 inverse kinematics. 237 00:12:05.000 --> 00:12:08.480 Ik ah, yes, ik This is where it gets really cool, 238 00:12:08.679 --> 00:12:12.000 especially for a realistic leg movement on uneven terrain like 239 00:12:12.080 --> 00:12:13.080 slopes or stairs. 240 00:12:13.159 --> 00:12:14.440 To stop feet going through. 241 00:12:14.279 --> 00:12:18.440 The floor exactly or floating weirdly above it, an algorithm 242 00:12:18.480 --> 00:12:21.159 like fabric that stands for forward and backward reaching inverse 243 00:12:21.200 --> 00:12:25.000 kinematics is often used instead of pants takingly animating every 244 00:12:25.039 --> 00:12:27.960 single joint in the leg. For every possible slope bangle, 245 00:12:29.080 --> 00:12:32.320 You define an end defector basically the character's foot and 246 00:12:32.320 --> 00:12:33.720 a target position on the ground. 247 00:12:33.840 --> 00:12:34.120 Okay. 248 00:12:34.399 --> 00:12:38.960 The fabric algorithm then automatically calculates all the necessary joint rotations, 249 00:12:39.240 --> 00:12:41.720 the knee bend, the hip angle required for the foot 250 00:12:41.799 --> 00:12:43.039 to reach that target naturally. 251 00:12:43.240 --> 00:12:46.159 Wow. So the system figures out the pose pretty much. 252 00:12:46.279 --> 00:12:49.360 Yeah, it ensures the feet plant realistically on the surface, 253 00:12:49.720 --> 00:12:53.559 adapting to the terrain. Huge for immersion, no more foot skating. 254 00:12:53.720 --> 00:12:56.639 That is a huge win. Okay, so the character knows 255 00:12:56.639 --> 00:12:58.679 where the ground is their feet stick to it. But 256 00:12:58.720 --> 00:13:00.919 how do they know where to go? A complex level? 257 00:13:00.919 --> 00:13:01.759 How do they navigate? 258 00:13:01.960 --> 00:13:04.720 Right? Navigation? Lots of ways to approach this. You've got 259 00:13:04.720 --> 00:13:08.559 simpler methods like distance based navigation think pac Man ghosts 260 00:13:08.639 --> 00:13:12.480 trying to close the distance, then more complex graph based 261 00:13:12.559 --> 00:13:17.360 navigation using algorithms to find paths through connected points, and 262 00:13:17.399 --> 00:13:20.960 even machine learning approaches these days. But a very common 263 00:13:21.000 --> 00:13:24.240 and powerful technique involves navigation meshes. 264 00:13:24.440 --> 00:13:26.159 Nav meshes, right, I've heard of those. 265 00:13:26.559 --> 00:13:30.039 They're basically pre calculated maps of all the walkable areas 266 00:13:30.080 --> 00:13:32.960 in the level, a simplified representation of the ground the 267 00:13:33.039 --> 00:13:36.759 character can actually move on. This avoids tons of expensive 268 00:13:36.799 --> 00:13:39.919 collision checks with all the static level geometry during. 269 00:13:39.720 --> 00:13:43.559 Pathfinding, so it's like a simplified map just for movement exactly. 270 00:13:43.639 --> 00:13:46.039 And the core algorithm used with nav meshes is very 271 00:13:46.080 --> 00:13:48.559 often a pathfinding a star. 272 00:13:48.799 --> 00:13:50.559 A star that's the famous one it is. 273 00:13:50.679 --> 00:13:54.480 It's a smart graph based algorithm. It finds the shortest 274 00:13:54.480 --> 00:13:57.759 path by balancing the actual cost proveled so far from 275 00:13:57.799 --> 00:14:01.240 the start point with a heuristic kind of educated guess 276 00:14:01.559 --> 00:14:03.240 of the remaining cost to reach the target. 277 00:14:03.399 --> 00:14:06.159 So it's efficient and finds good paths generally. 278 00:14:06.279 --> 00:14:08.799 Yes. In the source we looked at, the knapmash is 279 00:14:08.840 --> 00:14:12.240 generated directly from the level's wokable ground triangles, and the 280 00:14:12.279 --> 00:14:16.200 a algorithm uses simple Euclidian distance for its costs calculations. 281 00:14:16.600 --> 00:14:19.559 Characters can then navigate between pre defined points on this mash, 282 00:14:19.639 --> 00:14:21.879 often called waypoints, where navigation targets. 283 00:14:22.039 --> 00:14:24.320 So what does this mean for the player experience? Really, 284 00:14:24.399 --> 00:14:27.159 we're moving way beyond just sliding models around. 285 00:14:27.519 --> 00:14:31.960 Absolutely, we're giving these characters intelligence, a physical presence in 286 00:14:32.000 --> 00:14:34.600 the world. They can understand the environment, find their way 287 00:14:34.639 --> 00:14:37.799 through it, interact with it physically. They become truly part 288 00:14:37.799 --> 00:14:38.759 of that virtual space. 289 00:14:38.799 --> 00:14:41.159 It's amazing how many layers there are. Okay, we've built 290 00:14:41.200 --> 00:14:45.080 the characters, given them realistic movement intelligence to navigate. Now 291 00:14:45.159 --> 00:14:47.919 let's talk about the world itself, making it more alive 292 00:14:48.000 --> 00:14:51.960 and immersive. How does level data differ from character models? 293 00:14:52.039 --> 00:14:56.960 Good distinction level data is fundamentally different. Typically, level geometry 294 00:14:57.399 --> 00:15:00.240 is static, non movable, non anim. 295 00:15:00.120 --> 00:15:02.159 Made it right buildings terrain. 296 00:15:02.039 --> 00:15:05.759 Exactly, And this is actually a big advantage. Because it's static, 297 00:15:06.240 --> 00:15:08.639 you can pre calculate a lot of expensive stuff during 298 00:15:08.679 --> 00:15:11.440 development and bake it into the level data, like what 299 00:15:11.720 --> 00:15:14.759 things like light maps, pre calculated lighting and shadows, saving 300 00:15:14.799 --> 00:15:18.039 huge amounts of real time computation. Yeah, those navigation matches 301 00:15:18.039 --> 00:15:23.480 we just discussed, and also hierarchical level of detail or HLODE. Yeah, 302 00:15:23.519 --> 00:15:26.759 these are simplified versions of distant parts of the level geometry. 303 00:15:26.919 --> 00:15:29.440 As things get further away, the game swaps in simpler 304 00:15:29.440 --> 00:15:33.039 models to save rendering power. All this can be biggd. 305 00:15:32.679 --> 00:15:37.080 In I see. Optimization is key absolutely when loading levels. 306 00:15:37.080 --> 00:15:39.960 Again, a library like a SIMP can handle various formats 307 00:15:39.960 --> 00:15:45.360 wayfront glTF, but some level specific or engine specific formats exist, 308 00:15:45.720 --> 00:15:49.399 and things like FBX are still proprietary for collision. With 309 00:15:49.440 --> 00:15:52.720 this static level geometry, the system often uses that three 310 00:15:52.799 --> 00:15:55.919 D octree structure we mentioned to manage checks efficiently. 311 00:15:56.120 --> 00:15:59.120 Makes sense now, beyond just the visuals of the level, 312 00:15:59.320 --> 00:16:02.320 what other sense do we engage to build immersion? A 313 00:16:02.360 --> 00:16:04.279 game isn't just what you see is it. 314 00:16:04.200 --> 00:16:07.919 Not at all? Sound plays a huge, often really underestimated 315 00:16:08.000 --> 00:16:10.679 role in immersion house se well. Sound effects are crucial 316 00:16:10.679 --> 00:16:14.320 for feedback. Think about footsteps often managed by specific audio 317 00:16:14.360 --> 00:16:19.440 libraries like SDL mixer, the sound jumping, character vocalizations. 318 00:16:18.799 --> 00:16:21.639 Impact Yeah, tells you what's happening exactly. 319 00:16:21.159 --> 00:16:23.879 And local sound sources too. Hearing an enemy moving just 320 00:16:23.879 --> 00:16:26.399 around the corner gives you vital gameplay information. 321 00:16:26.720 --> 00:16:29.000 And then there's music, ambience and mood. 322 00:16:29.320 --> 00:16:33.000 Right, you've got menu music, ambient music to set the atmosphere, 323 00:16:33.200 --> 00:16:36.159 and even adaptive music that subtly changes based on what's 324 00:16:36.159 --> 00:16:40.480 happening in the game, intensifying during combat, calming down during exploration. 325 00:16:41.200 --> 00:16:43.440 It really enhances the mood and engagement. 326 00:16:43.720 --> 00:16:44.240 Definitely. 327 00:16:44.519 --> 00:16:47.440 Okay, Finally, how do we make the world itself feel 328 00:16:47.679 --> 00:16:52.480 truly dynamic, truly alive, Moving beyond just static environments, however 329 00:16:52.559 --> 00:16:54.559 beautifully lit or sounded they are. 330 00:16:55.200 --> 00:16:58.679 This is where environmental changes really shine. So visually, there's 331 00:16:58.679 --> 00:17:00.720 a ton we can do. We can break and realistic 332 00:17:00.720 --> 00:17:03.960 colors and material responses with physically based. 333 00:17:03.679 --> 00:17:05.480 Rendering pr PBR. 334 00:17:05.559 --> 00:17:06.799 Yeah, that's everywhere. 335 00:17:06.440 --> 00:17:09.079 Now, it is. We can add transparency for things like 336 00:17:09.160 --> 00:17:12.200 glass or water use a skybox that's usually a big 337 00:17:12.319 --> 00:17:15.240 cube map projected onto an invisible cube surrounding the scene 338 00:17:15.359 --> 00:17:18.279 to give a realistic sense of sky and distance the background. 339 00:17:18.359 --> 00:17:22.039 Implement dynamic lights and shadows that move and change, Simulate 340 00:17:22.119 --> 00:17:26.240 realistic water with reflections, refractions, distortions, and apply all sorts 341 00:17:26.240 --> 00:17:28.039 of stunning post processing. 342 00:17:27.640 --> 00:17:29.119 Effects like what kind of effects? 343 00:17:29.359 --> 00:17:33.519 Oh, things like lens flares, god rays streaming through trees 344 00:17:33.720 --> 00:17:37.759 bloom to make bright lights glow, motion blur, screen space 345 00:17:37.799 --> 00:17:42.559 ambient occlusion or SSAO to add subtle contact shadows. 346 00:17:42.559 --> 00:17:44.279 Okay, lots of acronyms. 347 00:17:43.759 --> 00:17:49.880 There, Yes, SSAO and screen space reflection SSR for reflections 348 00:17:49.920 --> 00:17:52.839 on surfaces and for really cutting edge visuals. You start 349 00:17:52.880 --> 00:17:57.079 talking about ray tracing for hyperrealistic lighting and shadows, and 350 00:17:57.160 --> 00:17:59.920 even virtual reality VR for total. 351 00:17:59.640 --> 00:18:01.920 Immergion, bushing the boundaries and beyond. 352 00:18:01.640 --> 00:18:04.359 Just looking good. The world itself can change over time. 353 00:18:05.039 --> 00:18:07.279 Think about a day night cycle like in Minecraft. Maybe 354 00:18:07.279 --> 00:18:09.799 a twenty minute cycle from dawn to dusk tonight. 355 00:18:09.599 --> 00:18:11.319 Changes the whole feel completely. 356 00:18:11.319 --> 00:18:15.440 Add weather effects, rain, snow, fog, even seasons like you 357 00:18:15.480 --> 00:18:18.160 see in games like Legend of Zelda, Oracle of Seasons 358 00:18:18.240 --> 00:18:21.559 or Stardou valley. These things fundamentally alter the world's appearance 359 00:18:21.839 --> 00:18:24.960 and can even affect gameplay or character behavior. You implement 360 00:18:25.000 --> 00:18:28.279 light control to simulate the sun and moon moving, changing color, temperature. 361 00:18:28.519 --> 00:18:30.039 It brings the environment truly alive. 362 00:18:30.319 --> 00:18:33.640 Wow. So we've really taken a journey today from you know, 363 00:18:33.680 --> 00:18:36.640 the basic building blocks, the polygons. 364 00:18:35.920 --> 00:18:39.079 And nodes, the virtual skeleton. 365 00:18:38.680 --> 00:18:43.240 To optimizing animations with GPUs, making characters move intelligently with 366 00:18:43.279 --> 00:18:44.759 things like A and IK. 367 00:18:44.759 --> 00:18:46.640 Right, navigating and interacting. 368 00:18:46.279 --> 00:18:51.000 And finally crafting these incredibly immersive worlds with dynamic lighting, sound, 369 00:18:51.720 --> 00:18:53.839 and even weather that changes over time. 370 00:18:53.920 --> 00:18:56.680 It's quite something when you break it down. What seems 371 00:18:56.759 --> 00:18:59.559 almost effortless on the screen, you know, a character just 372 00:18:59.599 --> 00:19:03.599 walking cross uneven ground. Yeah, it's actually this masterful orchestration 373 00:19:03.640 --> 00:19:08.000 of complex mathematics, really sophisticated data structures like oc trees 374 00:19:08.039 --> 00:19:12.200 and nav meshes, and some very clever programming techniques. Every 375 00:19:12.680 --> 00:19:16.720 subtle movement, every interaction, every shadow or reflection, it's all 376 00:19:16.759 --> 00:19:20.640 meticulously engineered, often invisible, but always impressive. 377 00:19:20.759 --> 00:19:22.920 It really is. So the next time you pick up 378 00:19:22.920 --> 00:19:25.799 a game, maybe plus for a second, what hidden layers 379 00:19:25.799 --> 00:19:28.799 of incredible engineering will you find yourself wondering about now, 380 00:19:29.000 --> 00:19:32.440 how am I thinking about the challenges of, say, creating 381 00:19:32.440 --> 00:19:35.799 an infinitely distant sky with just a symbol textured box, 382 00:19:36.400 --> 00:19:39.680 or the complex ik calculations needed just for a character's 383 00:19:39.680 --> 00:19:43.240 foot to land correctly on a bumpy slope. How might 384 00:19:43.279 --> 00:19:45.960 that change your perspective on the virtual worlds. 385 00:19:45.599 --> 00:19:47.279 You explore, something to think about 386 00:19:47.519 --> 00:19:51.039 Stay curious, keep exploring, and remember there's always more to learn.