Speaker 1: So, picture of virtual glass, right, being knocked off a
Speaker 1: table in your favorite video game.
Speaker 2: Yeah, we've all seen it.
Speaker 1: Right. It hits the floor and it just shatters perfectly.
Speaker 1: The water splashes everywhere, the little shards they scatter and
Speaker 1: skid to a halt, and it feels like it has weight,
Speaker 1: like it has a real physical presence. But what you
Speaker 1: don't actually see is the frantic, microscopic war of mathematical
Speaker 1: equations firing.
Speaker 2: Off thousands of times a second.
Speaker 1: Exactly thousands of times, just to tell that glass it
Speaker 1: hit the floor instead of falling endlessly into the void.
Speaker 1: Welcome to the deep dive everyone, thanks for having me.
Speaker 2: And yeah, it really is the ultimate illusion. I mean,
Speaker 2: when you think about.
Speaker 1: It, it really is. Today we are pulling apart the
Speaker 1: physics engines that build those illusions. We're getting into the
Speaker 1: actual mechanics, the mathematical cheat codes, and the literal computer
Speaker 1: science battles.
Speaker 2: Oh, it's absolutely a battle.
Speaker 1: Right, the battles that translate these raw equations into that
Speaker 1: feeling of weight and reality on your Yeah. Because we
Speaker 1: expect things to behave in a very specific way, don't we.
Speaker 2: We do. We are so deeply conditioned by reality. You
Speaker 2: know when a virtual object mimics that behavior even closely enough,
Speaker 2: our brains just they don't question it.
Speaker 1: We just accept the reality of the scene exactly.
Speaker 2: We just accept it and move on. Though calling it
Speaker 2: reality might actually be a bit of a stretch.
Speaker 1: What do you mean by that?
Speaker 2: Well, simulating physics isn't really about perfectly mapping the actual
Speaker 2: universe into a computer. I mean it's mostly smoke, mirrors
Speaker 2: and bending the laws.
Speaker 1: Of physics just to trick the human eye.
Speaker 2: Yeah, to trick the eye, and crucially, to save computational power.
Speaker 1: Okay, I love that. So before we get into the
Speaker 1: heavy math, we probably need to draw a line between
Speaker 1: what the human artists do and what the computer does.
Speaker 2: Right, Yeah, that's a good place to start. We are
Speaker 2: specifically looking at what's called secondary animation here.
Speaker 1: Not the core character acting.
Speaker 2: Right right. Primary animation that's the performance. It's the highly
Speaker 2: skilled artistic work, the emotion, the subtle facial expressions.
Speaker 1: The deliberate pacing of how a character walks exactly.
Speaker 2: But secondary animation is the physical fallout of those actions.
Speaker 1: Okay, So like hair blowing in the wind, yeah, or.
Speaker 2: A cape reacting when a hero jumps, or explosion debris
Speaker 2: settling on the ground. It's the environment reacting organically.
Speaker 1: Gotcha. It makes me think of like a movie set.
Speaker 1: The primary animation is the lead actor pouring their heart
Speaker 1: out on screen, right, and the secondary animation is like
Speaker 1: the wind machine and the rain tower in the background,
Speaker 1: making the scene actually believable.
Speaker 2: That is a perfect analogy. And to generate all that
Speaker 2: wind and rain, you know, animators don't painstakingly draw every
Speaker 2: single piece of debris frame by frame anymore. That would
Speaker 2: take forever, it would, so they rely on dynamic simulation.
Speaker 1: Which the textbook notes is distinct from discrete event simulation. Right, Yeah,
Speaker 1: because if I'm simulating, say a factory assembly line, or
Speaker 1: I don't know, an elevator schedule, I really just care
Speaker 1: about things arrive, right. The schedule is just a series
Speaker 1: of discrete events. Yes, But with this, with dynamic simulation,
Speaker 1: we're tracking the continuous evolving momentum of an object in
Speaker 1: three D space. But wait, hold on, if it's a
Speaker 1: dynamic simulation, how strictly do we actually have to follow
Speaker 1: the real rules of physics in these virtual worlds?
Speaker 2: Yeah?
Speaker 1: Like do I have to obey Newton flawlessly?
Speaker 2: Well, what's fascinating here is not if it ruins the shot. Really, yeah,
Speaker 2: I mean the physics engine is ultimately subservient to the
Speaker 2: art direction. Animators reinvent physical laws all the time.
Speaker 1: Oh that makes sense.
Speaker 2: Think of the classic wildly Cuyote gag from the old cartoons.
Speaker 1: Oh yeah, Or he runs off a cliff, right.
Speaker 2: He runs off the cliff, hovers in the air for
Speaker 2: like three full seconds to look at the camera and panic.
Speaker 1: And then he plummets. So the physics engine just what
Speaker 1: takes a coffee break pretty much.
Speaker 2: But consider what happens when he actually does fall. An
Speaker 2: animator might program his mass or the gravity acting on
Speaker 2: him to be completely different from reality.
Speaker 1: Oh so he accelerates twice as fast just to catch
Speaker 1: up on the comedic timing exactly.
Speaker 2: Pure accurate physics would completely ruin the joke there. So
Speaker 2: the physics engine is just a tool to serve the art.
Speaker 2: The physical laws are entirely malleable.
Speaker 1: Okay, that's wild. But let's say we do want that continuous,
Speaker 1: highly realistic movement like a bouncing ball. Sure we have
Speaker 1: to use Newton's second law, right, f equals ma force
Speaker 1: equals mass times acceleration.
Speaker 2: Yep. That's the engine of the simulation. You calculate the
Speaker 2: forces to find acceleration, integrate that to get velocity, and
Speaker 2: integrate velocity to get the position.
Speaker 1: But here's the thing. Computers can't actually process continuous time.
Speaker 1: I mean they process discrete binary data. Right.
Speaker 2: That is the fundamental bottleneck of all simulation. They have
Speaker 2: to calculate in chunks.
Speaker 1: Right.
Speaker 2: We call it the timestep. We essentially tell the processor
Speaker 2: to freeze time, assess all the forces acting on the ball,
Speaker 2: calculate its current velocity, jump forward by a specific.
Speaker 1: Chunk of time one full second.
Speaker 2: Yeah, exactly one second, and then place the ball in
Speaker 2: its new position.
Speaker 1: Yeah.
Speaker 2: This method is called oiler integration.
Speaker 1: Wait, hold on it. If we just freeze time, assume
Speaker 1: the velocity stays constant, and jump forward a full second,
Speaker 1: isn't the ball gonna end up in the wrong place?
Speaker 1: Because if it's falling, gravity's pulling it the entire second.
Speaker 1: It's speeding up that whole time, not just at the
Speaker 1: end of the jump.
Speaker 2: You've just identified the fatal flaw of basic oiler integration.
Speaker 2: No I did, Yeah, because the computer only updates the
Speaker 2: velocity at the end of that timestep. Your virtual ball
Speaker 2: will perpetually lag behind where a real world ball would be.
Speaker 1: Oh wow.
Speaker 2: It assumes a constant velocity during the whole duration of
Speaker 2: the jump, so it constantly undershoots the correct position.
Speaker 1: Mate. It's like, okay, it's like driving down a highway,
Speaker 1: but you're only allowed to open your eyes once every
Speaker 1: ten second.
Speaker 2: That's exactly what it's like.
Speaker 1: You have to guess where you are down the road
Speaker 1: based on the exact speed you are going the moment
Speaker 1: you close your eyes, and you're completely ignoring the fact
Speaker 1: that your foot was pressing the gas pedal the whole time.
Speaker 1: You're blind.
Speaker 2: A perfect analogy. So how do you think we fix
Speaker 2: the undershoot?
Speaker 1: Well? Do I just open my eyes more often? Like
Speaker 1: shrink the timestep down to a tenth of a second
Speaker 1: or I don't know, one hundredth of a second.
Speaker 2: You can. Shrinking the timestep dramatically reduces the error, but
Speaker 2: there is a brutal trade off.
Speaker 1: The computer has to work harder, much harder.
Speaker 2: Every time you cut the time step in half, you
Speaker 2: essentially double the computational load on the machine.
Speaker 1: Yikes.
Speaker 2: Yeah, shrink it too much and your fast paced video
Speaker 2: game slows to like one frame a minute, the processor
Speaker 2: will literally choke on the math.
Speaker 1: Okay, so we can't just brute force it with smaller
Speaker 1: chunks of time. What do we do?
Speaker 2: We have to use better math. Instead of just taking
Speaker 2: the velocity at the start of the time step, we
Speaker 2: can use algorithms that calculate the average velocity over the
Speaker 2: duration of the step. Oh I see for scenarios with
Speaker 2: constant acceleration. This completely eliminates the lag without increasing the
Speaker 2: processor load at all. How you do the math is
Speaker 2: just as important as the math itself.
Speaker 1: It's super clever, it is, but.
Speaker 2: You also have to be meticulous that your math is
Speaker 2: speaking the same language.
Speaker 1: Wait, are you talking about keeping the unit straight like
Speaker 1: the Mars orbiter.
Speaker 2: I am. Indeed, you can have the most elegant integration
Speaker 2: algorithm in the world, but if your variables are misaligned,
Speaker 2: disaster strikes.
Speaker 1: Yeah. For anyone who doesn't know the Mars Climate orbiter.
Speaker 1: In nineteen ninety nine, it literally burned up in the
Speaker 1: Martian atmosphere, a total tragedy, and it was because one
Speaker 1: engineering team programmed their physics simulation using metric newtons of
Speaker 1: force and another team used English pounds.
Speaker 2: Yep, the math itself worked flawlessly, but the mismatched units
Speaker 2: destroyed a multi million dollar spacecraft.
Speaker 1: Just a spectacular, incredibly expensive reminder to always check your
Speaker 1: variables exactly. Okay, so let's assume our math is airtight. Right,
Speaker 1: we have a gravity engine running smoothly. Sounds good, but
Speaker 1: I'm realizing a massive problem here. If we're just calculating
Speaker 1: raw gravity, my virtual bowling ball and a virtual feather
Speaker 1: are going to hit the ground at the exact same time.
Speaker 2: Right, because pure gravity is independent of mass.
Speaker 1: Yeah, Visually, that's going to look completely ridiculous to a player.
Speaker 2: It breaks the illusion immediately. To make a pure gravity
Speaker 2: simulation look real to you, the viewer, we have to
Speaker 2: add what isn't actually there air?
Speaker 1: Oh, drag. We have to simulate the atmosphere pushing back
Speaker 1: against the object as it falls.
Speaker 2: Exactly. Air resistance acts in the direct opposite direction of
Speaker 2: the object's motion, and importantly, the magnitude of that resistance
Speaker 2: increases the faster the object goes.
Speaker 1: Okay, makes sense.
Speaker 2: Animators use a user tunable drag constant. We'll call it
Speaker 2: df PO define how aerodynamic an object is.
Speaker 1: So a low D means the object is sleek and
Speaker 1: slices through the air.
Speaker 2: You got it, And a high D means it's bulky
Speaker 2: or rough and really catches the wind.
Speaker 1: So as the virtual ball drops and accelerates, the upward
Speaker 1: push of the air, resistance just gets stronger and stronger.
Speaker 2: Until you have the c artical balancing point, which is
Speaker 2: terminal velocity.
Speaker 1: Right, This is the.
Speaker 2: Exact mathematical moment where the upward force of drag perfectly
Speaker 2: balances out the downward pull of gravity. The net acceleration.
Speaker 1: Drops to zero, so the object stops speeding up exactly.
Speaker 2: It just continues to fall at a constant, steady rate
Speaker 2: instead of continuously accelerating.
Speaker 1: Okay, that totally fixes the falling aspect. But what about wind?
Speaker 1: Do we have to build an entirely separate physics system
Speaker 1: to simulate wind blowing things around?
Speaker 2: Not at all? And this is actually one of the
Speaker 2: most elegant shortcuts in all of simulation. Oh really, Yeah,
Speaker 2: wind is calculated using the exact same drag equation we
Speaker 2: just talked about. How the only difference is that instead
Speaker 2: of using the object's absolute velocity through the world, the
Speaker 2: engine uses the relative velocity of the object compared to
Speaker 2: the velocity of the wind.
Speaker 1: Wait, wait, wait, here's where it gets really interesting. So mathematically,
Speaker 1: a stationary leaf getting blasted by a fifty mile per
Speaker 1: hour windstorm that's treated identic to a leaf being fired
Speaker 1: at fifty miles per hour through completely dead, still air.
Speaker 1: The math doesn't care who is doing the moving.
Speaker 2: The math only sees the difference in speed. It does
Speaker 2: not care at all. And if we connect this to
Speaker 2: the bigger picture. From a creative standpoint, this gives animators
Speaker 2: an immense amount.
Speaker 1: Of control because they can use wind to direct a
Speaker 1: scene precisely.
Speaker 2: They don't have to just let gravity do all the
Speaker 2: dull work pulling particles straight down. They can inject invisible
Speaker 2: wind forces to physically push sparks or snow or debrithe
Speaker 2: exactly where they want them for the best visual impact.
Speaker 1: That is so cool. Okay, so we're falling, we've got drag,
Speaker 1: we're being blown by the wind. But eventually this virtual
Speaker 1: ball is going to hit the virtual ground.
Speaker 2: It has to land sometime.
Speaker 1: Right, So how does the computer actually know when a
Speaker 1: hit happens without breaking the illusion? Because in reality, collisions
Speaker 1: take time, materials compress, energy transfers.
Speaker 2: Yeah, real collisions are continuous, dynamic events. Like think of
Speaker 2: a high speed camera capturing a golf physically compressing against
Speaker 2: a clubhead.
Speaker 1: Right, it flattens out.
Speaker 2: It does, But in an animation simulation, calculating that atomic
Speaker 2: level deformation of materials is impossibly expensive computationally, So we
Speaker 2: cheat again. We cheat. We treat collisions as instantaneous events
Speaker 2: to save time, and we divide them into three distinct
Speaker 2: algorithmic phases detection, determination, and response.
Speaker 1: Okay, so detection is did it hit? Determination is exactly
Speaker 1: when and where did it hit? And response is what
Speaker 1: happens next exactly.
Speaker 2: Let's look at detection first. The engine constantly calculates something
Speaker 2: called the plane.
Speaker 1: Equation, which is what exactly.
Speaker 2: It tracks the mathematical distance from the center of our
Speaker 2: falling ball to the surface of the floor. As long
Speaker 2: as the result is a positive number, the ball is
Speaker 2: safely up in the air.
Speaker 1: Boait. Because we're moving in discrete chunks of time, those
Speaker 1: timesteps we were just talking about, the ball doesn't smoothly
Speaker 1: approach zero.
Speaker 2: Distance, right, Ah, you're ahead of me.
Speaker 1: Well, it might be like five units above the floor
Speaker 1: at timestep one, and then after jumping forward it's negative
Speaker 1: two units below the floor at timestep two, It literally
Speaker 1: passed through the floor between frames.
Speaker 2: And that negative distance is exactly what triggers the collision detection.
Speaker 2: The engine goes aha, an impact occurred during that last timestep.
Speaker 1: But it can't just leave the ball underground, right.
Speaker 2: And it can't just push it back up to the
Speaker 2: surface either. It needs determination the headache of fractional timesteps, because.
Speaker 1: If it just bums it up, the bounce will look completely.
Speaker 2: Wrong exactly, so the engine actually has to hit the
Speaker 2: rewind button. The algorithm calculates the exact fraction of the
Speaker 2: timestep where the ball's distance to the floor was perfectly zero.
Speaker 2: It moves the ball to that specific point in space
Speaker 2: and time stops. The simulation calculates the new trajectory, and
Speaker 2: then restarts the clock.
Speaker 1: Okay, this explains so much. You know those classic video
Speaker 1: game glitches where a character occasionally just walks straight through
Speaker 1: a solid wall.
Speaker 2: Oh, yes, I know them.
Speaker 1: Well, is this because their speed was so high and
Speaker 1: the timestep was so big that they were in front
Speaker 1: of the wall in frame one and completely behind it
Speaker 1: in frame two. Like the engine didn't check the math
Speaker 1: fast enough, so they just teleported.
Speaker 2: You nailed it. That is a phenomenon officially called tunneling.
Speaker 2: If the timestep is too large and the object is
Speaker 2: moving fast enough, the simulation entirely misses the event.
Speaker 1: Man. That sounds like a nightmare to code around.
Speaker 2: Oh, it gets so much worse. Imagine a ball ricocheting
Speaker 2: inside a small box in a single large timestep. That
Speaker 2: really fast moving ball might mathematically pass through multiple different
Speaker 2: walls at once.
Speaker 1: Oh jeez.
Speaker 2: Yeah, the engine can't just trigger a response for the
Speaker 2: first collision it happens to process in its list. It
Speaker 2: has to test every potential collision, figure out which one
Speaker 2: happened first in time, execute that one, and throw out
Speaker 2: the rest because.
Speaker 1: That first impact changes the ball's direction entirely, so the
Speaker 1: other wall calculations become completely irrelevant. Exactly the amount of
Speaker 1: background math happening before I even see the name next
Speaker 1: frame of a game is staggering.
Speaker 2: It really is.
Speaker 1: Okay, So the engine successfully rewinds time, it finds the
Speaker 1: exact microsecuative impact. We're on the floor. Now we need
Speaker 1: the response phase. How do we mathematically distinguish a bouncing
Speaker 1: basketball from like a sliding block of wood?
Speaker 2: We decompose the collision response into two orthogonal components. You
Speaker 2: have the normal direction, which is perpendicular to the floor.
Speaker 2: That's the bounce. Okay, and you have the tangential direction,
Speaker 2: which is parallel to the floor.
Speaker 1: That's the slide.
Speaker 2: Let's look at the bounce first. This is governed by
Speaker 2: a material's elasticity, technically called the coefficient of restitution.
Speaker 1: I love this part. This dictates the energy returned in
Speaker 1: the bounce. All right.
Speaker 2: Yes, a value of one means a perfect, completely elastic bounce.
Speaker 2: The ball bounce is back up to the exact height
Speaker 2: it dropped from. A value near zero means it's heavily inelastic,
Speaker 2: resulting in a heavy thud.
Speaker 1: Right. The textbook mentioned some real world numbers here, like
Speaker 1: a tennis ball has a rest of two of aboutzer
Speaker 1: point seventy five. Sounds about right, But what if we
Speaker 1: set it above one point zero? The textbook actually reference
Speaker 1: that nineteen sixty one movie The Absentminded Professor.
Speaker 2: Oh.
Speaker 1: Right, setting the math above one point zero is literally
Speaker 1: how you create flubber. You're gaining energy out of nowhere
Speaker 1: with every bounce.
Speaker 2: It completely violates the laws of thermodynamics. Yes, but this
Speaker 2: raises an important question It's crucial to remember that these
Speaker 2: coefficients aren't just baked into the ball itself.
Speaker 1: What do you mean?
Speaker 2: They are a function of both colliding materials. It's not
Speaker 2: just the ball, it's the floor. The engine has to
Speaker 2: account for a rubber ball bouncing on concrete versus a
Speaker 2: rubber ball bouncing on soft mud.
Speaker 1: Oh right, that makes sense.
Speaker 2: And that same principle applies to the tangential response friction.
Speaker 2: This dictates the loss of speed as an object slides
Speaker 2: across the floor. Now, you could use a simple friction
Speaker 2: model that just cuts sliding speed by a flat percentage,
Speaker 2: but it severely lacks realism because.
Speaker 1: A flat percentage ignores weight. Right. If I try to
Speaker 1: slide an empty cardboard box across a floor, it's easy,
Speaker 1: but if I fill it with books, it's a.
Speaker 2: Lot harder, Which is why robust physics engines use the
Speaker 2: Kulam model of friction. This model introduces the normal force.
Speaker 2: It accounts for the weight of the object pressing into
Speaker 2: the floor. A heavier object mathematically creates more friction.
Speaker 1: Okay, that makes perfect sense, And.
Speaker 2: The material pairings here can be wild. If you rub
Speaker 2: clean silver against clean silver, the friction coefficient can exceed
Speaker 2: one point zero.
Speaker 1: Wait, really silver on silver? Yeah.
Speaker 2: At a microscopic level, the metals are essentially trying to
Speaker 2: cold weld to each other. The engine has to account
Speaker 2: for all of these realities.
Speaker 1: Okay, so the simulation is running perfectly. We have Newton's laws,
Speaker 1: air drag, flawless fractional collisions, realistic coolan friction. We drop
Speaker 1: the ball, it bounces, the energy chips away, It gets
Speaker 1: lower and lower. But when I actually look at this screen,
Speaker 1: the ball does never perfectly stop. It just vibrates infinitely
Speaker 1: on the floor. Why does the physics engine fail us
Speaker 1: right at the finish line?
Speaker 2: Ah, the ghost in the machine stop fighting physics and
Speaker 2: started fighting computer architecture with go on. The infinite bounce
Speaker 2: is a byproduct of numerical precision and round off errors.
Speaker 2: Computers use binary floating point formats, right, but they physically
Speaker 2: cannot represent all real numbers.
Speaker 1: Perfectly because they have limited memory.
Speaker 2: Exactly, so they have to round complex fractions. If a
Speaker 2: ball loses twenty percent of its energy with every bounce,
Speaker 2: you are continuously multiplying its velocity by point eight. Mathematically,
Speaker 2: that number gets incredibly small, but it never actually reaches zero,
Speaker 2: so it.
Speaker 1: Just keeps calculating microscopic bounces, eating up processing power and
Speaker 1: vibrating on screen.
Speaker 2: Yes, so we introduce tolerances. We create a tiny mathematical
Speaker 2: buffer zone. We tell the engine if the velocity drops
Speaker 2: below point zero zero one.
Speaker 1: Just call it zero to force it to sleep right.
Speaker 2: But tolerances introduce a terrifying trap called incidence in transitivity.
Speaker 1: Ooh boy, what is that?
Speaker 2: Let me give you the textbook example. Imagine we have
Speaker 2: three values. A is one point five, B is one
Speaker 2: point seven, and C is two point oh and let's
Speaker 2: say our tolerance buffer is point four. If two numbers
Speaker 2: are within point four of each other, the engine considers
Speaker 2: them perfectly equal.
Speaker 1: Okay, let me walk through this. If I compare A
Speaker 1: and B one point five and one point seven, they
Speaker 1: are only point two apart, so they're inside the point
Speaker 1: four buffer. The computer says A equals B.
Speaker 2: Now compare B and C.
Speaker 1: One point seven and two point zero. They're point three apart,
Speaker 1: still inside the buffer, so B equal C.
Speaker 2: But what happens when the engine compares A and C.
Speaker 1: C Wait one point five and two point zero. That's
Speaker 1: point five apart. That's outside the tolerance buffer. So the
Speaker 1: computer says A does not equal.
Speaker 2: C, even though it just mathematically proved that A equals
Speaker 2: B and B equal c.
Speaker 1: Oh Man, That breaks basic logic. It's exactly like a
Speaker 1: game of telephone. Yes, small acceptable errors pass from person
Speaker 1: to person, but by the end of the line, the
Speaker 1: final message makes no sense and breaks the entire simulation.
Speaker 2: This is where simulation stops being pure physics and becomes
Speaker 2: computer science. You are constantly battling the physical limitations of
Speaker 2: the machine itself.
Speaker 1: So how do you actually put the ball to sleep?
Speaker 2: You need a strict resting. The velocity must be near zero,
Speaker 2: it must be touching a plane, and the forces must
Speaker 2: be pushing into the plane unable to overcome static friction.
Speaker 2: Only then can it finally rest.
Speaker 1: This is a staggering amount of invisible architecture. We've gone
Speaker 1: from high level animation concepts to slicing time into chunks
Speaker 1: with Newton, to adding air resistance, detecting precise fractional collisions,
Speaker 1: faking friction.
Speaker 2: And finally wrestling the computer's own memory limits just to
Speaker 2: force a virtual ball to go to sleep.
Speaker 1: So to all of you listening, the next time you
Speaker 1: see an animated character knock a glass off a table,
Speaker 1: you'll know that behind that simple visual is a frantic,
Speaker 1: microscopic war of plane equations, floating point round offs, and
Speaker 1: relative velocities.
Speaker 2: And consider this one final thought from the textbook. Yeah,
Speaker 2: we know these virtual models are heavily simplified, ignoring atomic
Speaker 2: level details to save computation.
Speaker 1: Right.
Speaker 2: Well, if our virtual worlds are just broad phase simulations,
Speaker 2: filtering out the underlying chaos because it's too much to calculate,
Speaker 2: it makes you wonder if our own physical universe has
Speaker 2: an ultimate tolerance buffer at the quantum scale, rounding off
Speaker 2: the math where things get too small to matter.
Speaker 1: Oh wow, okay, that is a thought that will keep
Speaker 1: me staring at the ceiling tonight. Are we just running
Speaker 1: in a universe with a very small timestep? Thank you
Speaker 1: so much for taking this deep dive with us. To
Speaker 1: everyone listening, keep questioning those invisible rules, whether they govern
Speaker 1: your screens or the world right outside your window.