WEBVTT 1 00:00:00.160 --> 00:00:03.799 So, picture of virtual glass, right, being knocked off a 2 00:00:03.839 --> 00:00:06.559 table in your favorite video game. 3 00:00:06.639 --> 00:00:07.719 Yeah, we've all seen it. 4 00:00:07.799 --> 00:00:10.679 Right. It hits the floor and it just shatters perfectly. 5 00:00:10.720 --> 00:00:13.960 The water splashes everywhere, the little shards they scatter and 6 00:00:14.000 --> 00:00:17.120 skid to a halt, and it feels like it has weight, 7 00:00:17.600 --> 00:00:20.519 like it has a real physical presence. But what you 8 00:00:20.600 --> 00:00:26.359 don't actually see is the frantic, microscopic war of mathematical 9 00:00:26.399 --> 00:00:27.839 equations firing. 10 00:00:27.480 --> 00:00:29.320 Off thousands of times a second. 11 00:00:29.199 --> 00:00:31.800 Exactly thousands of times, just to tell that glass it 12 00:00:31.879 --> 00:00:35.000 hit the floor instead of falling endlessly into the void. 13 00:00:35.280 --> 00:00:37.520 Welcome to the deep dive everyone, thanks for having me. 14 00:00:37.840 --> 00:00:40.200 And yeah, it really is the ultimate illusion. I mean, 15 00:00:40.280 --> 00:00:41.200 when you think about. 16 00:00:40.960 --> 00:00:43.600 It, it really is. Today we are pulling apart the 17 00:00:43.600 --> 00:00:46.159 physics engines that build those illusions. We're getting into the 18 00:00:46.240 --> 00:00:51.880 actual mechanics, the mathematical cheat codes, and the literal computer 19 00:00:51.960 --> 00:00:52.719 science battles. 20 00:00:52.799 --> 00:00:54.640 Oh, it's absolutely a battle. 21 00:00:54.359 --> 00:00:57.679 Right, the battles that translate these raw equations into that 22 00:00:57.719 --> 00:01:01.119 feeling of weight and reality on your Yeah. Because we 23 00:01:01.119 --> 00:01:04.000 expect things to behave in a very specific way, don't we. 24 00:01:04.000 --> 00:01:07.760 We do. We are so deeply conditioned by reality. You 25 00:01:07.760 --> 00:01:12.239 know when a virtual object mimics that behavior even closely enough, 26 00:01:12.400 --> 00:01:14.840 our brains just they don't question it. 27 00:01:15.040 --> 00:01:17.239 We just accept the reality of the scene exactly. 28 00:01:17.280 --> 00:01:19.760 We just accept it and move on. Though calling it 29 00:01:19.799 --> 00:01:21.799 reality might actually be a bit of a stretch. 30 00:01:22.560 --> 00:01:23.359 What do you mean by that? 31 00:01:23.439 --> 00:01:27.799 Well, simulating physics isn't really about perfectly mapping the actual 32 00:01:27.920 --> 00:01:31.319 universe into a computer. I mean it's mostly smoke, mirrors 33 00:01:31.519 --> 00:01:33.120 and bending the laws. 34 00:01:32.920 --> 00:01:34.760 Of physics just to trick the human eye. 35 00:01:34.840 --> 00:01:38.640 Yeah, to trick the eye, and crucially, to save computational power. 36 00:01:38.840 --> 00:01:41.159 Okay, I love that. So before we get into the 37 00:01:41.200 --> 00:01:44.840 heavy math, we probably need to draw a line between 38 00:01:45.239 --> 00:01:48.040 what the human artists do and what the computer does. 39 00:01:47.879 --> 00:01:50.040 Right, Yeah, that's a good place to start. We are 40 00:01:50.079 --> 00:01:53.359 specifically looking at what's called secondary animation here. 41 00:01:53.480 --> 00:01:55.319 Not the core character acting. 42 00:01:55.159 --> 00:01:58.959 Right right. Primary animation that's the performance. It's the highly 43 00:01:59.000 --> 00:02:04.159 skilled artistic work, the emotion, the subtle facial expressions. 44 00:02:03.519 --> 00:02:06.079 The deliberate pacing of how a character walks exactly. 45 00:02:06.159 --> 00:02:09.400 But secondary animation is the physical fallout of those actions. 46 00:02:09.680 --> 00:02:12.599 Okay, So like hair blowing in the wind, yeah, or. 47 00:02:12.520 --> 00:02:16.439 A cape reacting when a hero jumps, or explosion debris 48 00:02:16.439 --> 00:02:19.439 settling on the ground. It's the environment reacting organically. 49 00:02:19.560 --> 00:02:23.319 Gotcha. It makes me think of like a movie set. 50 00:02:23.599 --> 00:02:26.280 The primary animation is the lead actor pouring their heart 51 00:02:26.280 --> 00:02:30.039 out on screen, right, and the secondary animation is like 52 00:02:30.560 --> 00:02:33.000 the wind machine and the rain tower in the background, 53 00:02:33.000 --> 00:02:35.039 making the scene actually believable. 54 00:02:35.159 --> 00:02:38.039 That is a perfect analogy. And to generate all that 55 00:02:38.120 --> 00:02:42.240 wind and rain, you know, animators don't painstakingly draw every 56 00:02:42.240 --> 00:02:44.800 single piece of debris frame by frame anymore. That would 57 00:02:44.800 --> 00:02:48.800 take forever, it would, so they rely on dynamic simulation. 58 00:02:48.800 --> 00:02:53.680 Which the textbook notes is distinct from discrete event simulation. Right, Yeah, 59 00:02:53.680 --> 00:02:56.840 because if I'm simulating, say a factory assembly line, or 60 00:02:56.960 --> 00:02:59.680 I don't know, an elevator schedule, I really just care 61 00:02:59.680 --> 00:03:02.280 about things arrive, right. The schedule is just a series 62 00:03:02.319 --> 00:03:06.159 of discrete events. Yes, But with this, with dynamic simulation, 63 00:03:06.520 --> 00:03:10.360 we're tracking the continuous evolving momentum of an object in 64 00:03:10.439 --> 00:03:13.199 three D space. But wait, hold on, if it's a 65 00:03:13.319 --> 00:03:18.039 dynamic simulation, how strictly do we actually have to follow 66 00:03:18.159 --> 00:03:22.039 the real rules of physics in these virtual worlds? 67 00:03:22.159 --> 00:03:22.479 Yeah? 68 00:03:22.520 --> 00:03:24.919 Like do I have to obey Newton flawlessly? 69 00:03:25.199 --> 00:03:29.840 Well, what's fascinating here is not if it ruins the shot. Really, yeah, 70 00:03:29.919 --> 00:03:32.479 I mean the physics engine is ultimately subservient to the 71 00:03:32.560 --> 00:03:35.879 art direction. Animators reinvent physical laws all the time. 72 00:03:35.960 --> 00:03:36.680 Oh that makes sense. 73 00:03:36.759 --> 00:03:40.199 Think of the classic wildly Cuyote gag from the old cartoons. 74 00:03:40.199 --> 00:03:42.199 Oh yeah, Or he runs off a cliff, right. 75 00:03:42.080 --> 00:03:44.159 He runs off the cliff, hovers in the air for 76 00:03:44.199 --> 00:03:47.840 like three full seconds to look at the camera and panic. 77 00:03:47.599 --> 00:03:50.199 And then he plummets. So the physics engine just what 78 00:03:50.400 --> 00:03:51.919 takes a coffee break pretty much. 79 00:03:52.400 --> 00:03:55.199 But consider what happens when he actually does fall. An 80 00:03:55.199 --> 00:03:59.400 animator might program his mass or the gravity acting on 81 00:03:59.479 --> 00:04:01.400 him to be completely different from reality. 82 00:04:01.479 --> 00:04:04.120 Oh so he accelerates twice as fast just to catch 83 00:04:04.159 --> 00:04:05.919 up on the comedic timing exactly. 84 00:04:06.000 --> 00:04:08.960 Pure accurate physics would completely ruin the joke there. So 85 00:04:09.039 --> 00:04:11.520 the physics engine is just a tool to serve the art. 86 00:04:11.800 --> 00:04:13.879 The physical laws are entirely malleable. 87 00:04:14.159 --> 00:04:17.720 Okay, that's wild. But let's say we do want that continuous, 88 00:04:18.519 --> 00:04:22.240 highly realistic movement like a bouncing ball. Sure we have 89 00:04:22.319 --> 00:04:26.519 to use Newton's second law, right, f equals ma force 90 00:04:26.560 --> 00:04:28.560 equals mass times acceleration. 91 00:04:28.759 --> 00:04:31.399 Yep. That's the engine of the simulation. You calculate the 92 00:04:31.399 --> 00:04:35.399 forces to find acceleration, integrate that to get velocity, and 93 00:04:35.560 --> 00:04:37.319 integrate velocity to get the position. 94 00:04:37.439 --> 00:04:41.160 But here's the thing. Computers can't actually process continuous time. 95 00:04:41.680 --> 00:04:44.000 I mean they process discrete binary data. Right. 96 00:04:44.199 --> 00:04:46.879 That is the fundamental bottleneck of all simulation. They have 97 00:04:46.920 --> 00:04:48.279 to calculate in chunks. 98 00:04:48.480 --> 00:04:48.720 Right. 99 00:04:48.759 --> 00:04:51.639 We call it the timestep. We essentially tell the processor 100 00:04:51.680 --> 00:04:54.920 to freeze time, assess all the forces acting on the ball, 101 00:04:55.160 --> 00:04:59.040 calculate its current velocity, jump forward by a specific. 102 00:04:58.680 --> 00:05:01.240 Chunk of time one full second. 103 00:05:01.040 --> 00:05:03.800 Yeah, exactly one second, and then place the ball in 104 00:05:03.839 --> 00:05:04.720 its new position. 105 00:05:04.879 --> 00:05:05.120 Yeah. 106 00:05:05.160 --> 00:05:06.879 This method is called oiler integration. 107 00:05:07.040 --> 00:05:09.600 Wait, hold on it. If we just freeze time, assume 108 00:05:09.639 --> 00:05:12.399 the velocity stays constant, and jump forward a full second, 109 00:05:12.920 --> 00:05:14.560 isn't the ball gonna end up in the wrong place? 110 00:05:14.839 --> 00:05:18.319 Because if it's falling, gravity's pulling it the entire second. 111 00:05:18.680 --> 00:05:20.480 It's speeding up that whole time, not just at the 112 00:05:20.519 --> 00:05:21.160 end of the jump. 113 00:05:21.319 --> 00:05:24.759 You've just identified the fatal flaw of basic oiler integration. 114 00:05:25.040 --> 00:05:28.560 No I did, Yeah, because the computer only updates the 115 00:05:28.639 --> 00:05:31.879 velocity at the end of that timestep. Your virtual ball 116 00:05:31.920 --> 00:05:35.399 will perpetually lag behind where a real world ball would be. 117 00:05:35.639 --> 00:05:36.240 Oh wow. 118 00:05:36.600 --> 00:05:40.439 It assumes a constant velocity during the whole duration of 119 00:05:40.480 --> 00:05:43.279 the jump, so it constantly undershoots the correct position. 120 00:05:43.959 --> 00:05:47.519 Mate. It's like, okay, it's like driving down a highway, 121 00:05:47.560 --> 00:05:49.879 but you're only allowed to open your eyes once every 122 00:05:49.920 --> 00:05:50.480 ten second. 123 00:05:50.600 --> 00:05:51.800 That's exactly what it's like. 124 00:05:51.959 --> 00:05:54.199 You have to guess where you are down the road 125 00:05:54.279 --> 00:05:56.680 based on the exact speed you are going the moment 126 00:05:56.680 --> 00:05:59.480 you close your eyes, and you're completely ignoring the fact 127 00:05:59.480 --> 00:06:02.000 that your foot was pressing the gas pedal the whole time. 128 00:06:02.040 --> 00:06:02.600 You're blind. 129 00:06:02.800 --> 00:06:06.040 A perfect analogy. So how do you think we fix 130 00:06:06.160 --> 00:06:07.000 the undershoot? 131 00:06:07.279 --> 00:06:09.720 Well? Do I just open my eyes more often? Like 132 00:06:09.879 --> 00:06:12.839 shrink the timestep down to a tenth of a second 133 00:06:12.920 --> 00:06:14.439 or I don't know, one hundredth of a second. 134 00:06:14.680 --> 00:06:19.040 You can. Shrinking the timestep dramatically reduces the error, but 135 00:06:19.800 --> 00:06:21.160 there is a brutal trade off. 136 00:06:21.199 --> 00:06:23.319 The computer has to work harder, much harder. 137 00:06:23.480 --> 00:06:25.519 Every time you cut the time step in half, you 138 00:06:25.639 --> 00:06:28.160 essentially double the computational load on the machine. 139 00:06:28.279 --> 00:06:28.720 Yikes. 140 00:06:28.879 --> 00:06:32.120 Yeah, shrink it too much and your fast paced video 141 00:06:32.160 --> 00:06:35.600 game slows to like one frame a minute, the processor 142 00:06:35.600 --> 00:06:37.120 will literally choke on the math. 143 00:06:37.199 --> 00:06:40.800 Okay, so we can't just brute force it with smaller 144 00:06:40.879 --> 00:06:42.240 chunks of time. What do we do? 145 00:06:42.639 --> 00:06:45.000 We have to use better math. Instead of just taking 146 00:06:45.000 --> 00:06:46.839 the velocity at the start of the time step, we 147 00:06:46.879 --> 00:06:49.959 can use algorithms that calculate the average velocity over the 148 00:06:50.040 --> 00:06:52.480 duration of the step. Oh I see for scenarios with 149 00:06:52.560 --> 00:06:57.160 constant acceleration. This completely eliminates the lag without increasing the 150 00:06:57.160 --> 00:07:00.079 processor load at all. How you do the math is 151 00:07:00.160 --> 00:07:01.759 just as important as the math itself. 152 00:07:01.839 --> 00:07:03.759 It's super clever, it is, but. 153 00:07:03.800 --> 00:07:05.759 You also have to be meticulous that your math is 154 00:07:05.800 --> 00:07:07.160 speaking the same language. 155 00:07:07.399 --> 00:07:10.199 Wait, are you talking about keeping the unit straight like 156 00:07:10.199 --> 00:07:10.959 the Mars orbiter. 157 00:07:11.199 --> 00:07:14.319 I am. Indeed, you can have the most elegant integration 158 00:07:14.360 --> 00:07:17.560 algorithm in the world, but if your variables are misaligned, 159 00:07:17.879 --> 00:07:18.920 disaster strikes. 160 00:07:19.279 --> 00:07:21.759 Yeah. For anyone who doesn't know the Mars Climate orbiter. 161 00:07:21.839 --> 00:07:24.720 In nineteen ninety nine, it literally burned up in the 162 00:07:24.759 --> 00:07:27.879 Martian atmosphere, a total tragedy, and it was because one 163 00:07:27.920 --> 00:07:31.439 engineering team programmed their physics simulation using metric newtons of 164 00:07:31.480 --> 00:07:34.360 force and another team used English pounds. 165 00:07:34.680 --> 00:07:40.600 Yep, the math itself worked flawlessly, but the mismatched units 166 00:07:40.600 --> 00:07:43.279 destroyed a multi million dollar spacecraft. 167 00:07:43.519 --> 00:07:47.199 Just a spectacular, incredibly expensive reminder to always check your 168 00:07:47.279 --> 00:07:50.920 variables exactly. Okay, so let's assume our math is airtight. Right, 169 00:07:50.959 --> 00:07:53.600 we have a gravity engine running smoothly. Sounds good, but 170 00:07:53.639 --> 00:07:56.839 I'm realizing a massive problem here. If we're just calculating 171 00:07:56.920 --> 00:08:01.399 raw gravity, my virtual bowling ball and a virtual feather 172 00:08:02.000 --> 00:08:04.600 are going to hit the ground at the exact same time. 173 00:08:04.560 --> 00:08:07.600 Right, because pure gravity is independent of mass. 174 00:08:07.680 --> 00:08:10.959 Yeah, Visually, that's going to look completely ridiculous to a player. 175 00:08:11.040 --> 00:08:14.079 It breaks the illusion immediately. To make a pure gravity 176 00:08:14.120 --> 00:08:17.399 simulation look real to you, the viewer, we have to 177 00:08:17.439 --> 00:08:20.120 add what isn't actually there air? 178 00:08:20.480 --> 00:08:24.040 Oh, drag. We have to simulate the atmosphere pushing back 179 00:08:24.079 --> 00:08:25.480 against the object as it falls. 180 00:08:26.000 --> 00:08:29.759 Exactly. Air resistance acts in the direct opposite direction of 181 00:08:29.800 --> 00:08:33.919 the object's motion, and importantly, the magnitude of that resistance 182 00:08:34.240 --> 00:08:36.240 increases the faster the object goes. 183 00:08:36.320 --> 00:08:37.240 Okay, makes sense. 184 00:08:37.279 --> 00:08:40.440 Animators use a user tunable drag constant. We'll call it 185 00:08:40.480 --> 00:08:43.440 df PO define how aerodynamic an object is. 186 00:08:43.600 --> 00:08:45.840 So a low D means the object is sleek and 187 00:08:45.919 --> 00:08:47.000 slices through the air. 188 00:08:47.360 --> 00:08:49.679 You got it, And a high D means it's bulky 189 00:08:49.759 --> 00:08:51.840 or rough and really catches the wind. 190 00:08:52.080 --> 00:08:56.120 So as the virtual ball drops and accelerates, the upward 191 00:08:56.159 --> 00:08:59.399 push of the air, resistance just gets stronger and stronger. 192 00:08:59.120 --> 00:09:01.320 Until you have the c artical balancing point, which is 193 00:09:01.360 --> 00:09:02.240 terminal velocity. 194 00:09:02.440 --> 00:09:03.200 Right, This is the. 195 00:09:03.240 --> 00:09:07.519 Exact mathematical moment where the upward force of drag perfectly 196 00:09:07.559 --> 00:09:11.799 balances out the downward pull of gravity. The net acceleration. 197 00:09:11.360 --> 00:09:14.240 Drops to zero, so the object stops speeding up exactly. 198 00:09:14.240 --> 00:09:16.679 It just continues to fall at a constant, steady rate 199 00:09:16.840 --> 00:09:19.039 instead of continuously accelerating. 200 00:09:19.120 --> 00:09:22.559 Okay, that totally fixes the falling aspect. But what about wind? 201 00:09:22.799 --> 00:09:25.279 Do we have to build an entirely separate physics system 202 00:09:25.360 --> 00:09:27.799 to simulate wind blowing things around? 203 00:09:27.919 --> 00:09:29.600 Not at all? And this is actually one of the 204 00:09:29.600 --> 00:09:33.600 most elegant shortcuts in all of simulation. Oh really, Yeah, 205 00:09:34.080 --> 00:09:37.480 wind is calculated using the exact same drag equation we 206 00:09:37.559 --> 00:09:41.159 just talked about. How the only difference is that instead 207 00:09:41.200 --> 00:09:44.879 of using the object's absolute velocity through the world, the 208 00:09:45.080 --> 00:09:48.480 engine uses the relative velocity of the object compared to 209 00:09:48.519 --> 00:09:49.720 the velocity of the wind. 210 00:09:50.000 --> 00:09:53.480 Wait, wait, wait, here's where it gets really interesting. So mathematically, 211 00:09:54.000 --> 00:09:56.960 a stationary leaf getting blasted by a fifty mile per 212 00:09:56.960 --> 00:10:01.399 hour windstorm that's treated identic to a leaf being fired 213 00:10:01.399 --> 00:10:05.480 at fifty miles per hour through completely dead, still air. 214 00:10:06.559 --> 00:10:08.879 The math doesn't care who is doing the moving. 215 00:10:09.080 --> 00:10:11.440 The math only sees the difference in speed. It does 216 00:10:11.480 --> 00:10:13.480 not care at all. And if we connect this to 217 00:10:13.480 --> 00:10:16.879 the bigger picture. From a creative standpoint, this gives animators 218 00:10:16.879 --> 00:10:18.080 an immense amount. 219 00:10:17.759 --> 00:10:19.720 Of control because they can use wind to direct a 220 00:10:19.799 --> 00:10:20.679 scene precisely. 221 00:10:20.759 --> 00:10:22.759 They don't have to just let gravity do all the 222 00:10:22.840 --> 00:10:26.240 dull work pulling particles straight down. They can inject invisible 223 00:10:26.279 --> 00:10:30.000 wind forces to physically push sparks or snow or debrithe 224 00:10:30.039 --> 00:10:32.639 exactly where they want them for the best visual impact. 225 00:10:32.960 --> 00:10:35.440 That is so cool. Okay, so we're falling, we've got drag, 226 00:10:35.480 --> 00:10:38.360 we're being blown by the wind. But eventually this virtual 227 00:10:38.360 --> 00:10:39.799 ball is going to hit the virtual ground. 228 00:10:39.840 --> 00:10:41.279 It has to land sometime. 229 00:10:41.200 --> 00:10:44.159 Right, So how does the computer actually know when a 230 00:10:44.279 --> 00:10:49.480 hit happens without breaking the illusion? Because in reality, collisions 231 00:10:49.519 --> 00:10:52.960 take time, materials compress, energy transfers. 232 00:10:53.399 --> 00:10:57.720 Yeah, real collisions are continuous, dynamic events. Like think of 233 00:10:57.759 --> 00:11:01.960 a high speed camera capturing a golf physically compressing against 234 00:11:01.960 --> 00:11:02.639 a clubhead. 235 00:11:02.799 --> 00:11:03.879 Right, it flattens out. 236 00:11:04.000 --> 00:11:07.919 It does, But in an animation simulation, calculating that atomic 237 00:11:08.039 --> 00:11:13.440 level deformation of materials is impossibly expensive computationally, So we 238 00:11:13.519 --> 00:11:17.519 cheat again. We cheat. We treat collisions as instantaneous events 239 00:11:17.519 --> 00:11:20.279 to save time, and we divide them into three distinct 240 00:11:20.360 --> 00:11:24.600 algorithmic phases detection, determination, and response. 241 00:11:24.639 --> 00:11:28.679 Okay, so detection is did it hit? Determination is exactly 242 00:11:28.679 --> 00:11:31.240 when and where did it hit? And response is what 243 00:11:31.320 --> 00:11:32.440 happens next exactly. 244 00:11:32.480 --> 00:11:35.639 Let's look at detection first. The engine constantly calculates something 245 00:11:35.639 --> 00:11:36.440 called the plane. 246 00:11:36.240 --> 00:11:38.120 Equation, which is what exactly. 247 00:11:38.399 --> 00:11:41.279 It tracks the mathematical distance from the center of our 248 00:11:41.320 --> 00:11:44.519 falling ball to the surface of the floor. As long 249 00:11:44.559 --> 00:11:46.759 as the result is a positive number, the ball is 250 00:11:46.840 --> 00:11:47.919 safely up in the air. 251 00:11:48.320 --> 00:11:51.799 Boait. Because we're moving in discrete chunks of time, those 252 00:11:51.879 --> 00:11:54.960 timesteps we were just talking about, the ball doesn't smoothly 253 00:11:55.000 --> 00:11:56.120 approach zero. 254 00:11:55.919 --> 00:11:57.639 Distance, right, Ah, you're ahead of me. 255 00:11:57.799 --> 00:12:00.759 Well, it might be like five units above the floor 256 00:12:00.840 --> 00:12:04.120 at timestep one, and then after jumping forward it's negative 257 00:12:04.120 --> 00:12:07.399 two units below the floor at timestep two, It literally 258 00:12:07.440 --> 00:12:09.600 passed through the floor between frames. 259 00:12:09.360 --> 00:12:13.159 And that negative distance is exactly what triggers the collision detection. 260 00:12:13.279 --> 00:12:17.679 The engine goes aha, an impact occurred during that last timestep. 261 00:12:18.200 --> 00:12:21.000 But it can't just leave the ball underground, right. 262 00:12:20.879 --> 00:12:22.440 And it can't just push it back up to the 263 00:12:22.480 --> 00:12:28.639 surface either. It needs determination the headache of fractional timesteps, because. 264 00:12:28.399 --> 00:12:31.200 If it just bums it up, the bounce will look completely. 265 00:12:30.759 --> 00:12:33.559 Wrong exactly, so the engine actually has to hit the 266 00:12:33.600 --> 00:12:37.039 rewind button. The algorithm calculates the exact fraction of the 267 00:12:37.039 --> 00:12:40.000 timestep where the ball's distance to the floor was perfectly zero. 268 00:12:40.399 --> 00:12:43.080 It moves the ball to that specific point in space 269 00:12:43.120 --> 00:12:47.480 and time stops. The simulation calculates the new trajectory, and 270 00:12:47.519 --> 00:12:48.679 then restarts the clock. 271 00:12:48.840 --> 00:12:51.600 Okay, this explains so much. You know those classic video 272 00:12:51.600 --> 00:12:55.120 game glitches where a character occasionally just walks straight through 273 00:12:55.120 --> 00:12:55.879 a solid wall. 274 00:12:55.919 --> 00:12:57.279 Oh, yes, I know them. 275 00:12:57.320 --> 00:13:00.360 Well, is this because their speed was so high and 276 00:13:00.399 --> 00:13:03.039 the timestep was so big that they were in front 277 00:13:03.039 --> 00:13:06.159 of the wall in frame one and completely behind it 278 00:13:06.200 --> 00:13:09.159 in frame two. Like the engine didn't check the math 279 00:13:09.200 --> 00:13:10.639 fast enough, so they just teleported. 280 00:13:10.840 --> 00:13:14.559 You nailed it. That is a phenomenon officially called tunneling. 281 00:13:15.159 --> 00:13:17.440 If the timestep is too large and the object is 282 00:13:17.440 --> 00:13:20.480 moving fast enough, the simulation entirely misses the event. 283 00:13:20.840 --> 00:13:22.799 Man. That sounds like a nightmare to code around. 284 00:13:22.879 --> 00:13:25.440 Oh, it gets so much worse. Imagine a ball ricocheting 285 00:13:25.480 --> 00:13:29.440 inside a small box in a single large timestep. That 286 00:13:29.759 --> 00:13:34.200 really fast moving ball might mathematically pass through multiple different 287 00:13:34.240 --> 00:13:34.879 walls at once. 288 00:13:35.039 --> 00:13:35.720 Oh jeez. 289 00:13:36.080 --> 00:13:39.240 Yeah, the engine can't just trigger a response for the 290 00:13:39.279 --> 00:13:42.159 first collision it happens to process in its list. It 291 00:13:42.200 --> 00:13:45.720 has to test every potential collision, figure out which one 292 00:13:45.720 --> 00:13:48.440 happened first in time, execute that one, and throw out 293 00:13:48.480 --> 00:13:49.519 the rest because. 294 00:13:49.279 --> 00:13:53.440 That first impact changes the ball's direction entirely, so the 295 00:13:53.480 --> 00:13:57.320 other wall calculations become completely irrelevant. Exactly the amount of 296 00:13:57.360 --> 00:14:00.240 background math happening before I even see the name next 297 00:14:00.320 --> 00:14:02.840 frame of a game is staggering. 298 00:14:03.000 --> 00:14:03.600 It really is. 299 00:14:03.840 --> 00:14:07.120 Okay, So the engine successfully rewinds time, it finds the 300 00:14:07.159 --> 00:14:10.240 exact microsecuative impact. We're on the floor. Now we need 301 00:14:10.240 --> 00:14:14.960 the response phase. How do we mathematically distinguish a bouncing 302 00:14:15.039 --> 00:14:18.320 basketball from like a sliding block of wood? 303 00:14:18.480 --> 00:14:22.200 We decompose the collision response into two orthogonal components. You 304 00:14:22.279 --> 00:14:25.240 have the normal direction, which is perpendicular to the floor. 305 00:14:25.320 --> 00:14:27.960 That's the bounce. Okay, and you have the tangential direction, 306 00:14:28.000 --> 00:14:29.360 which is parallel to the floor. 307 00:14:29.480 --> 00:14:30.320 That's the slide. 308 00:14:30.759 --> 00:14:33.480 Let's look at the bounce first. This is governed by 309 00:14:33.480 --> 00:14:37.320 a material's elasticity, technically called the coefficient of restitution. 310 00:14:37.639 --> 00:14:40.399 I love this part. This dictates the energy returned in 311 00:14:40.440 --> 00:14:41.240 the bounce. All right. 312 00:14:41.440 --> 00:14:46.360 Yes, a value of one means a perfect, completely elastic bounce. 313 00:14:47.039 --> 00:14:49.080 The ball bounce is back up to the exact height 314 00:14:49.159 --> 00:14:53.360 it dropped from. A value near zero means it's heavily inelastic, 315 00:14:53.639 --> 00:14:55.039 resulting in a heavy thud. 316 00:14:55.679 --> 00:14:58.399 Right. The textbook mentioned some real world numbers here, like 317 00:14:58.679 --> 00:15:00.639 a tennis ball has a rest of two of aboutzer 318 00:15:00.639 --> 00:15:03.159 point seventy five. Sounds about right, But what if we 319 00:15:03.200 --> 00:15:06.279 set it above one point zero? The textbook actually reference 320 00:15:06.360 --> 00:15:09.200 that nineteen sixty one movie The Absentminded Professor. 321 00:15:09.399 --> 00:15:09.600 Oh. 322 00:15:09.720 --> 00:15:12.559 Right, setting the math above one point zero is literally 323 00:15:12.639 --> 00:15:16.039 how you create flubber. You're gaining energy out of nowhere 324 00:15:16.080 --> 00:15:16.799 with every bounce. 325 00:15:16.919 --> 00:15:20.799 It completely violates the laws of thermodynamics. Yes, but this 326 00:15:20.919 --> 00:15:23.720 raises an important question It's crucial to remember that these 327 00:15:23.720 --> 00:15:26.080 coefficients aren't just baked into the ball itself. 328 00:15:26.279 --> 00:15:26.840 What do you mean? 329 00:15:27.000 --> 00:15:29.360 They are a function of both colliding materials. It's not 330 00:15:29.440 --> 00:15:31.679 just the ball, it's the floor. The engine has to 331 00:15:31.759 --> 00:15:35.120 account for a rubber ball bouncing on concrete versus a 332 00:15:35.159 --> 00:15:36.840 rubber ball bouncing on soft mud. 333 00:15:36.960 --> 00:15:38.480 Oh right, that makes sense. 334 00:15:38.440 --> 00:15:42.360 And that same principle applies to the tangential response friction. 335 00:15:43.120 --> 00:15:46.600 This dictates the loss of speed as an object slides 336 00:15:46.600 --> 00:15:49.159 across the floor. Now, you could use a simple friction 337 00:15:49.320 --> 00:15:52.320 model that just cuts sliding speed by a flat percentage, 338 00:15:52.559 --> 00:15:55.000 but it severely lacks realism because. 339 00:15:54.720 --> 00:15:57.399 A flat percentage ignores weight. Right. If I try to 340 00:15:57.440 --> 00:16:00.720 slide an empty cardboard box across a floor, it's easy, 341 00:16:00.960 --> 00:16:02.919 but if I fill it with books, it's a. 342 00:16:02.840 --> 00:16:05.840 Lot harder, Which is why robust physics engines use the 343 00:16:05.879 --> 00:16:09.879 Kulam model of friction. This model introduces the normal force. 344 00:16:10.120 --> 00:16:12.399 It accounts for the weight of the object pressing into 345 00:16:12.440 --> 00:16:15.879 the floor. A heavier object mathematically creates more friction. 346 00:16:16.039 --> 00:16:17.679 Okay, that makes perfect sense, And. 347 00:16:17.679 --> 00:16:20.240 The material pairings here can be wild. If you rub 348 00:16:20.320 --> 00:16:24.279 clean silver against clean silver, the friction coefficient can exceed 349 00:16:24.360 --> 00:16:25.039 one point zero. 350 00:16:25.240 --> 00:16:27.559 Wait, really silver on silver? Yeah. 351 00:16:27.840 --> 00:16:30.559 At a microscopic level, the metals are essentially trying to 352 00:16:30.559 --> 00:16:33.440 cold weld to each other. The engine has to account 353 00:16:33.440 --> 00:16:34.559 for all of these realities. 354 00:16:34.639 --> 00:16:37.960 Okay, so the simulation is running perfectly. We have Newton's laws, 355 00:16:38.360 --> 00:16:42.840 air drag, flawless fractional collisions, realistic coolan friction. We drop 356 00:16:42.879 --> 00:16:46.120 the ball, it bounces, the energy chips away, It gets 357 00:16:46.159 --> 00:16:49.120 lower and lower. But when I actually look at this screen, 358 00:16:50.240 --> 00:16:53.799 the ball does never perfectly stop. It just vibrates infinitely 359 00:16:53.840 --> 00:16:56.679 on the floor. Why does the physics engine fail us 360 00:16:56.759 --> 00:16:57.799 right at the finish line? 361 00:16:58.120 --> 00:17:01.200 Ah, the ghost in the machine stop fighting physics and 362 00:17:01.240 --> 00:17:04.680 started fighting computer architecture with go on. The infinite bounce 363 00:17:04.759 --> 00:17:07.759 is a byproduct of numerical precision and round off errors. 364 00:17:08.160 --> 00:17:12.240 Computers use binary floating point formats, right, but they physically 365 00:17:12.319 --> 00:17:14.519 cannot represent all real numbers. 366 00:17:14.160 --> 00:17:16.480 Perfectly because they have limited memory. 367 00:17:16.279 --> 00:17:19.799 Exactly, so they have to round complex fractions. If a 368 00:17:19.839 --> 00:17:22.799 ball loses twenty percent of its energy with every bounce, 369 00:17:23.000 --> 00:17:27.359 you are continuously multiplying its velocity by point eight. Mathematically, 370 00:17:27.400 --> 00:17:30.279 that number gets incredibly small, but it never actually reaches zero, 371 00:17:30.400 --> 00:17:30.680 so it. 372 00:17:30.640 --> 00:17:33.880 Just keeps calculating microscopic bounces, eating up processing power and 373 00:17:33.960 --> 00:17:34.839 vibrating on screen. 374 00:17:34.960 --> 00:17:39.119 Yes, so we introduce tolerances. We create a tiny mathematical 375 00:17:39.160 --> 00:17:42.119 buffer zone. We tell the engine if the velocity drops 376 00:17:42.119 --> 00:17:43.720 below point zero zero one. 377 00:17:43.599 --> 00:17:45.759 Just call it zero to force it to sleep right. 378 00:17:46.079 --> 00:17:50.559 But tolerances introduce a terrifying trap called incidence in transitivity. 379 00:17:50.839 --> 00:17:52.559 Ooh boy, what is that? 380 00:17:52.839 --> 00:17:55.400 Let me give you the textbook example. Imagine we have 381 00:17:55.519 --> 00:17:58.839 three values. A is one point five, B is one 382 00:17:58.880 --> 00:18:01.640 point seven, and C is two point oh and let's 383 00:18:01.640 --> 00:18:04.920 say our tolerance buffer is point four. If two numbers 384 00:18:04.920 --> 00:18:07.720 are within point four of each other, the engine considers 385 00:18:07.759 --> 00:18:08.759 them perfectly equal. 386 00:18:08.839 --> 00:18:11.160 Okay, let me walk through this. If I compare A 387 00:18:11.319 --> 00:18:13.359 and B one point five and one point seven, they 388 00:18:13.400 --> 00:18:15.759 are only point two apart, so they're inside the point 389 00:18:15.839 --> 00:18:18.240 four buffer. The computer says A equals B. 390 00:18:18.480 --> 00:18:19.839 Now compare B and C. 391 00:18:20.160 --> 00:18:23.279 One point seven and two point zero. They're point three apart, 392 00:18:23.480 --> 00:18:25.039 still inside the buffer, so B equal C. 393 00:18:25.799 --> 00:18:28.279 But what happens when the engine compares A and C. 394 00:18:27.920 --> 00:18:30.160 C Wait one point five and two point zero. That's 395 00:18:30.279 --> 00:18:32.920 point five apart. That's outside the tolerance buffer. So the 396 00:18:32.920 --> 00:18:34.640 computer says A does not equal. 397 00:18:34.440 --> 00:18:36.839 C, even though it just mathematically proved that A equals 398 00:18:36.880 --> 00:18:37.720 B and B equal c. 399 00:18:37.880 --> 00:18:41.079 Oh Man, That breaks basic logic. It's exactly like a 400 00:18:41.079 --> 00:18:44.240 game of telephone. Yes, small acceptable errors pass from person 401 00:18:44.240 --> 00:18:46.079