Skip to content

Latest commit

 

History

History
70 lines (58 loc) · 6.25 KB

level-0-the-basics.md

File metadata and controls

70 lines (58 loc) · 6.25 KB

time steps

  • If we had a single moving object, like a ball accelerating downwards due to gravity, we could deterministically compute its physical variables (like position and velocity) as a function of time ... $$ \begin{aligned} y(t) &= \dfrac{g}{2} \cdot t^2\ v(t) &= g \cdot t \end{aligned} $$

  • But in more complex simulations the position and velocity of a moving object depend on the interactions it has with its environment, whose results we most oftenly can't easily express as a function of time.

    • Example: If we simulate the balls on a billiard table (like we will do, starting in level 4), the collisions between the balls are too complex and interrelated to be able to predict the position of each ball as a function of time.
    level-6-billiard-example
  • The universal approach to such complex simulations is breaking it up into small incremental time steps (eg. time steps of length 1 millisecond).

    level-0-time-step-diagram
  • Because the time steps are really small, we are allowed the following approximations:
    • (1. Approxim.) The motion update which happens during each time step is free/uninterrupted from any interactions/collisions. Only after (or before) the motion update in each time step we check for and execute updates for any interactions/collisions. This eliminates the complex interrelation of motion and interactions/collisions. We simply divide it into to distinct procedures.
    • (2. Approxim.) Physical variables like the velocity or the acceleration of an object may be assumed to be constant during a time step, because they should not change much during such small time anyway.
  • Because of these two approximations, our simulations are not 100% accurate. But they're pretty close. And the smaller the time steps, the more accurate the approximation.
  • To get the time steps really small, you will want to have more than 1 time step per frame, because your render frame rate is typically only 60Hz or even lower (this is a pretty low resolution for a good simulation).
    • So we perform multiple sub-steps per frame. A technique sometimes also called subsampling.
    • In our code examples the number of sub-steps per frame is fixed, eg. 20 sub-steps per frame.
  • And finally one last thing. There are different "styles" of updating the physical variables of objects like position, velocity and acceleration with the time step equations. I call them "styles" because all of them are just approximations.
    • A common difference between these styles of updating motion in the time step equations is whether they assume forces and velocities to be strictly constant during the time step or if they actually take some kind of averaging approach, for example assuming the physical variables change linearly from one state to another.
    • Don't worry about this, for now. This concept will be revisited a couple of times.



collisions

  • A collision between two simulated objects (eg. a ball and another ball) is detected by checking whether their geometric shapes (circles in our case) overlap. Because if they overlap, the objects must have bumped into each other.
    level-0-collision-diagram-(1)
  • The same applies to a collision between a ball and a wall. If the ball "sticks" in the wall (overlaps with it) it must have bumped into it.
    level-0-collision-diagram-(2)



dimensions, coordinate system

  • We stick to 2D simulations.
    • 3D simulations would basically work the same way, but we don't want to rush, right? 😁
  • So we have the $x$ and the $y$ dimension in a cartesian coordinate system.
    level-0-coordinate-system
  • Some physical variables of the balls thereby become vectors, meaning they're split up in their respective $x$ and $y$ components: $$ \vec{p} = \begin{pmatrix}x\ y\end{pmatrix} \quad \vec{v} = \begin{pmatrix}v_x\ v_y\end{pmatrix} \quad \vec{a} = \begin{pmatrix}a_x\ a_y\end{pmatrix} $$