4.3 real time game physics
•Download as PPT, PDF•
1 like•281 views
The document discusses numerical simulation techniques for real-time game physics. It introduces particle physics concepts like position, velocity, and acceleration. Finite difference methods are described as the most common approach for incremental numerical solutions when closed-form equations do not exist. Explicit Euler integration is provided as a basic finite difference method, where the state vector is updated over small time steps using the prior state and derivatives. Examples are given of applying explicit Euler integration to simulate 3D projectile motion towards a target.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 4.3 real time game physics
Similar to 4.3 real time game physics (20)
More from Sayed Ahmed
More from Sayed Ahmed (20)
Recently uploaded
Recently uploaded (20)
4.3 real time game physics
- 1. Chapter 4.3 Real-time Game Physics
- 2. Outline Introduction Motivation for including physics in games Practical development team decisions Particle Physics Particle Kinematics Closed-form Equations of Motion Numerical Simulation Finite Difference Methods Explicit Euler Integration Verlet Integration Brief Overview of Generalized Rigid Bodies Brief Overview of Collision Response Final Comments
- 4. 4 Why Physics? The Human Experience Real-world motions are physically-based Physics can make simulated game worlds appear more natural Makes sense to strive for physically-realistic motion for some types of games Emergent Behavior Physics simulation can enable a richer gaming experience
- 5. 5 Why Physics? Developer/Publisher Cost Savings Classic approaches to creating realistic motion: Artist-created keyframe animations Motion capture Both are labor intensive and expensive Physics simulation: Motion generated by algorithm Theoretically requires only minimal artist input Potential to substantially reduce content development cost
- 6. 6 High-level Decisions Physics in Digital Content Creation Software: Many DCC modeling tools provide physics Export physics-engine-generated animation as keyframe data Enables incorporation of physics into game engines that do not support real-time physics Straightforward update of existing asset creation pipelines Does not provide player with the same emergent- behavior-rich game experience Does not provide full cost savings to developer/publisher
- 7. 7 High-level Decisions Real-time Physics in Game at Runtime: Enables the emergent behavior that provides player a richer game experience Potential to provide full cost savings to developer/publisher May require significant upgrade of game engine May require significant update of asset creation pipelines May require special training for modelers, animators, and level designers Licensing an existing engine may significantly increase third party middleware costs
- 8. 8 High-level Decisions License vs. Build Physics Engine: License middleware physics engine Complete solution from day 1 Proven, robust code base (in theory) Most offer some integration with DCC tools Features are always a tradeoff
- 9. 9 High-level Decisions License vs. Build Physics Engine: Build physics engine in-house Choose only the features you need Opportunity for more game-specific optimizations Greater opportunity to innovate Cost can be easily be much greater No asset pipeline at start of development
- 10. Real-time Game Physics The Beginning: Particle Physics
- 11. 11 The Beginning: Particle Physics What is a Particle? A sphere of finite radius with a perfectly smooth, frictionless surface Experiences no rotational motion Particle Kinematics Defines the basic properties of particle motion Position, Velocity, Acceleration
- 12. 12 Location of Particle in World Space SI Units: meters (m) Changes over time when object moves p(t) p ( t+ t) Particle Kinematics - Position zyx ppp ,,=p
- 13. 13 Particle Kinematics - Velocity and Acceleration Velocity (SI units: m/s) First time derivative of position: Acceleration (SI units: m/s2 ) First time derivative of velocity Second time derivative of position )( )()( lim)( 0 t dt d t ttt t t p pp V = ∆ −∆+ = →∆ )()()( 2 2 t dt d t dt d t pVa ==
- 14. 14 Newton’s 2nd Law of Motion Paraphrased – “An object’s change in velocity is proportional to an applied force” The Classic Equation: m = mass (SI units: kilograms, kg) F(t) = force (SI units: Newtons) ( ) ( )tmt aF =
- 15. 15 What is Physics Simulation? The Cycle of Motion: Force, F(t), causes acceleration Acceleration, a(t), causes a change in velocity Velocity, V(t) causes a change in position Physics Simulation: Solving variations of the above equations over time to emulate the cycle of motion
- 16. 16 Example: 3D Projectile Motion Constant Force Weight of the projectile, W = mg g is constant acceleration due to gravity Closed-form Projectile Equations of Motion: These closed-form equations are valid, and exact*, for any time, t, in seconds, greater than or equal to tinit ( )initinit ttt −+= gVV )( ( ) ( )2 2 1 )( initinitinitinit ttttt −+−+= gVpp
- 17. 17 Example: 3D Projectile Motion Initial Value Problem Simulation begins at time tinit The initial velocity, Vinit and position, pinit, at time tinit, are known Solve for later values at any future time, t, based on these initial values On Earth: If we choose positive Z to be straight up (away from center of Earth), gEarth = 9.81 m/s2 : 2 m/s81.9,0.0,0.0ˆ −=−= kgEarthEarthg
- 18. 18 Concrete Example: Target Practice V init F = w e ig h t = m g Target Projectile Launch Position, pinit
- 19. 19 Choose Vinit to Hit a Stationary Target ptarget is the stationary target location We would like to choose the initial velocity, Vinit, required to hit the target at some future time, thit. Here is our equation of motion at time thit: Solution in general is a bit tedious to derive… Infinite number of solutions! Hint: Specify the magnitude of Vinit, solve for its direction Concrete Example: Target Practice ( ) ( )2 2 1 inithitinithitinitinittarget tttt −+−+= gVpp
- 20. 20 Choose Scalar launch speed, Vinit, and Let: Where: Concrete Example: Target Practice φφθφθ sin,cossin,coscos initinitinitinit VVV=V ( ) ( ) ( ) ( ) ( ) ( ) ( )θθ φ θθ sincos 2 1 2 tan sin;cos ,,,, 2 ,, 22 2 2 ,, 2 ,, ,, 2 ,, 2 ,, ,, + +−+ = −+ −± = −−− − = −−− − = xinityinitxtargetytarget init zinitztarget initinit yinitytargetxinitxtarget yinitytarget yinitytargetxinitxtarget xinitxtarget pppp A A V g pp V A g V A gAA pppp pp pppp pp
- 21. 21 If Radicand in tanφ Equation is Negative: No solution. Vinit is too small to hit the target Otherwise: One solution if radicand == 0 If radicand > 0, TWO possible launch angles, φ Smallest φ yields earlier time of arrival, thit Largest φ yields later time of arrival, thit Concrete Example: Target Practice solution!nothen,0 2 1 2if ,, 22 2 < −+ − zinitztarget initinit pp V A g V A gA
- 22. 22 969.31 Target Practice – A Few Examples Vinit = 25 m/s Value of Radicand of tanφ equation: Launch angle φ: 19.4 deg or 70.6 deg 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Trajectory 1 - High Angle, Slow Arrival Trajectory 2 - Low Angle, Fast Arrival
- 23. 23 Target Practice – A Few Examples 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Trajectory 1 - High Angle, Slow Arrival Trajectory 2 - Low Angle, Fast Arrival 60.2 Vinit = 20 m/s Value of Radicand of tanφ equation: Launch angle φ: 39.4 deg or 50.6 deg
- 24. 24 Target Practice – A Few Examples 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Trajectory 1 - High Angle, Slow Arrival Trajectory 2 - Low Angle, Fast Arrival 13.2 Vinit = 19.85 m/s Value of Radicand of tanφ equation: Launch angle φ: 42.4 deg or 47.6 deg (note convergence)
- 25. 25 Target Practice – A Few Examples -290.4 Vinit = 19 m/s Value of Radicand of tanφ equation: Launch angle φ: No solution! Vinit too small to reach target! 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Trajectory with farthest reach barely undershoots target
- 26. 26 Target Practice – A Few Examples 2063 Vinit = 18 m/s Value of Radicand of tanφ equation: Launch angle φ: -6.38 deg or 60.4 deg 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Trajectory 1 - High Angle, Slow Arrival Trajectory 2 - Low Angle, Fast Arrival
- 27. 27 Target Practice – A Few Examples 668 Vinit = 30 m/s Value of Radicand of tanφ equation: Launch angle φ: 39.1 deg or 75.2 deg 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Trajectory 1 - High Angle, Slow Arrival Trajectory 2 - Low Angle, Fast Arrival
- 28. Real-time Game Physics Practical Implementation: Numerical Simulation
- 29. 29 What is Numerical Simulation? Equations Presented Above They are “closed-form” Valid and exact for constant applied force Do not require time-stepping Just determine current game time, t, using system timer e.g., t = QueryPerformanceCounter / QueryPerformanceFrequency or equivalent on Microsoft® Windows® platforms Plug t and tinitinto the equations Equations produce identical, repeatable, stable results, for any time, t, regardless of CPU speed and frame rate
- 30. 30 What is Numerical Simulation? The above sounds perfect Why not use those equations always? Constant forces aren’t very interesting Simple projectiles only Closed-form solutions rarely exist for interesting (non- constant) forces We need a way to deal when there is no closed-form solution… Numerical Simulation represents a series of techniques for incrementally solving the equations of motion when forces applied to an object are not constant, or when otherwise there is no closed-form solution
- 31. 31 Finite Difference Methods What are They? The most common family of numerical techniques for rigid-body dynamics simulation Incremental “solution” to equations of motion Derived using truncated Taylor Series expansions See text for a more detailed introduction “Numerical Integrator” This is what we generically call a finite difference equation that generates a “solution” over time
- 32. 32 Finite Difference Methods The Explicit Euler Integrator: Properties of object are stored in a state vector, S Use the above integrator equation to incrementally update S over time as game progresses Must keep track of prior value of S in order to compute the new For Explicit Euler, one choice of state and state derivative for particle: ( ) ( ) ( ) derivativestate statepriorstatenew t dt d tttt SSS ∆+=∆+ pVS ,m= VFS ,=dtd
- 33. 33 Explicit Euler Integration F=Weight = mg Vinitpinit Vinit = 30 m/s Launch angle, φ: 75.2 deg (slow arrival) Launch angle, θ: 0 deg (motion in world xz plane) Mass of projectile, m: 2.5 kg Target at <50, 0, 20> meters tinit Time p x p y p z mV x mV y mV z F x F y F z V x V y V z 5.00 10.00 0.00 2.00 19.20 0.00 72.50 0.00 0.00 -24.53 7.68 0.00 29.00 Velocity (m/s)Position (m) Linear Momentum (kg-m/s) Force (N) mVinit S = <mVinit, pinit > dS/dt = <mg,Vinit>
- 34. 34 ∆t = .01 s∆t = .1 s Explicit Euler Integration = = = − ∆+ =∆+=∆+ 2900.2 0.0 0768.10 2549.72 0.0 2025.19 9000.4 0.0 7681.10 0476.72 0.0 2025.19 8000.7 0.0 5362.11 5951.67 0.0 2025.19 0.29 0.0 68.7 53.24 0.0 0.0 0.2 0.0 0.10 5.72 0.0 2.19 )()()( tt dt d tttt SSS ∆t = .2 s = = = 2895.2 0.0 0768.10 2549.72 0.0 2.19 8510.4 0.0 1536.10 0476.72 0.0 2.19 6038.7 0.0 5362.11 5951.67 0.0 2.19 Solutionform-ClosedExact,
- 35. 35 A Tangent: Truncation Error The previous slide highlights values in the numerical solution that are different from the exact, closed-form solution This difference between the exact solution and the numerical solution is primarily truncation error Truncation error is equal and opposite to the value of terms that were removed from the Taylor Series expansion to produce the finite difference equation Truncation error, left unchecked, can accumulate to cause simulation to become unstable This ultimately produces floating point overflow Unstable simulations behave unpredictably
- 36. 36 A Tangent: Truncation Error Controlling Truncation Error Under certain circumstances, truncation error can become zero, e.g., the finite difference equation produces the exact, correct result For example, when zero force is applied More often in practice, truncation error is nonzero Approaches to control truncation error: Reduce time step, ∆t Select a different numerical integrator See text for more background information and references
- 37. 37 Explicit Euler Integration – Truncation Error = ==∆ = ==∆ = ==∆ 0005.0 0.0 0.0 2895.2 0.0 0768.10 - 2900.2 0.0 0768.10 0.01s)t(ErrorTruncation 049.0 0.0 0.0 8510.4 0.0 1536.10 - 9000.4 0.0 1536.10 0.1s)t(ErrorTruncation 1962.0 0.0 0.0 6038.7 0.0 5362.11 - 800.7 0.0 5362.11 0.2s)t(ErrorTruncation exactnumerical exactnumerical exactnumerical Truncation ErrorLets Look at Truncation Error (position only)
- 38. 38 Explicit Euler Integration – Truncation Error (1/∆t) * Truncation Error is a linear (first- order) function of ∆t: explicit Euler Integration is First-Order-Accurate in time This accuracy is denoted by “O(∆t)” 0.00 0.20 0.40 0.60 0.80 1.00 0.00 0.05 0.10 0.15 0.20 0.25 ∆t(secs) (1/t)*TruncationError
- 39. 39 Explicit Euler Integration - Computing Solution Over Time 0.00 10.00 20.00 30.00 40.00 50.00 0.00 20.00 40.00 60.00 Horizontal Position (m) VerticalPosition(m) Projectile Launch Position Target Position Closed-Form Explicit Euler The solution proceeds step-by-step, each time integrating from the prior state Time p x p y p z mV x mV y mV z F x F y F z V x V y V z 5.00 10.00 0.00 2.00 19.20 0.00 72.50 0.00 0.00 -24.53 7.68 0.00 29.00 5.20 11.54 0.00 7.80 19.20 0.00 67.60 0.00 0.00 -24.53 7.68 0.00 27.04 5.40 13.07 0.00 13.21 19.20 0.00 62.69 0.00 0.00 -24.53 7.68 0.00 25.08 5.60 14.61 0.00 18.22 19.20 0.00 57.79 0.00 0.00 -24.53 7.68 0.00 23.11 M M M M M 10.40 51.48 0.00 20.87 19.20 0.00 -59.93 0.00 0.00 -24.53 7.68 0.00 -23.97 Velocity (m/s)Position (m) Linear Momentum (kg-m/s) Force (N)
- 40. 40 Finite Difference Methods The Verlet Integrator: Must store state at two prior time steps, S(t) and S(t-∆t) Uses second derivative of state instead of the first Valid for constant time step only (as shown above) For Verlet, choice of state and state derivative for a particle: pS = aFS == mdtd / 22 ( ) ( ) ( ) ( ) derivativestate 2 2 2 2stateprior1statepriorstatenew )(2 ∆+∆−−=∆+ t dt d tttttt SSSS
- 41. 41 Verlet Integration a=<0,0,-g>p S = <p> d2 S/dt2 = <a> )(,)( 2 2 initinit t dt d t SS )(,)( 2 2 tt dt d tt initinit ∆+∆+ SS Since Verlet requires two prior values of state, S(t) and S(t-∆t), you must use some method other than Verlet to produce the first numerical state after start of simulation, S(tinit+∆t) Solution: Use explicit Euler integration to produce S(tinit+∆t), then Verlet for all subsequent time steps Time p x p y p z a x a y a z 5.00 10.00 0.00 2.00 0.00 0.00 -9.81 5.20 11.54 0.00 7.80 0.00 0.00 -9.81 Position (m) Acceleration (m/s2 )
- 42. 42 The solution proceeds step-by-step, each time integrating from the prior two states For constant acceleration, Verlet integration produces results identical to those of explicit Euler But, results are different when non-constant forces are applied Verlet Integration tends to be more stable than explicit Euler for generalized forces Time p x p y p z a x a y a z 5.00 10.00 0.00 2.00 0.00 0.00 -9.81 5.20 11.54 0.00 7.80 0.00 0.00 -9.81 5.40 13.07 0.00 13.21 0.00 0.00 -9.81 5.60 14.61 0.00 18.22 0.00 0.00 -9.81 5.80 16.14 0.00 22.85 0.00 0.00 -9.81 6.00 17.68 0.00 27.08 0.00 0.00 -9.81 M M M 10.40 51.48 0.00 20.87 0.00 0.00 -9.81 Position (m) Acceleration (m/s2 ) Verlet Integration S(t+∆t) S(t) S(t-∆t) )(2 2 t dt d S
- 43. Real-time Game Physics Generalized Rigid Bodies
- 44. 44 Generalized Rigid Bodies Key Differences from Particles Not necessarily spherical in shape Position, p, represents object’s center-of-mass location Surface may not be perfectly smooth Friction forces may be present Experience rotational motion in addition to translational (position only) motion
- 45. 45 Generalized Rigid Bodies – Simulation Angular Kinematics Orientation, 3x3 matrix R or quaternion, q Angular velocity, ω As with translational/particle kinematics, all properties are measured in world coordinates Additional Object Properties Inertia tensor, J Center-of-mass Additional State Properties for Simulation Orientation Angular momentum, L=Jω Corresponding state derivatives
- 46. 46 Generalized Rigid Bodies - Simulation Torque Analogous to a force Causes rotational acceleration Cause a change in angular momentum Torque is the result of a force (friction, collision response, spring, damper, etc.)
- 47. 47 Generalized Rigid Bodies – Numerical Simulation Using Finite Difference Integrators Translational components of state <mV, p> are the same S and dS/dt are expanded to include angular momentum and orientation, and their derivatives Be careful about coordinate system representation for J, R, etc. Otherwise, integration step is identical to the translation only case Additional Post-integration Steps Adjust orientation for consistency Adjust updated R to ensure it is orthogonal Normalize q Update angular velocity, ω See text for more details
- 48. 48 Collision Response Why? Performed to keep objects from interpenetrating To ensure behavior similar to real-world objects Two Basic Approaches Approach 1: Instantaneous change of velocity at time of collision Benefits: Visually the objects never interpenetrate Result is generated via closed-form equations, and is perfectly stable Difficulties: Precise detection of time and location of collision can be prohibitively expensive (frame rate killer) Logic to manage state is complex
- 49. 49 Collision Response Two Basic Approaches (continued) Approach 2: Gradual change of velocity and position over time, following collision Benefits Does not require precise detection of time and location of collision State management is easy Potential to be more realistic, if meshes are adjusted to deform according to predicted interpenetration Difficulties Object interpenetration is likely, and parameters must be tweaked to manage this Simulation can be subject to numerical instabilities, often requiring the use of implicit finite difference methods
- 50. 50 Final Comments Instantaneous Collision Response Classical approach: Impulse-momentum equations See text for full details Gradual Collision Response Classical approach: Penalty force methods Resolve interpenetration over the course of a few integration steps Penalty forces can wreak havoc on numerical integration Instabilities galore Implicit finite difference equations can handle it But more difficult to code Geometric approach: Ignore physical response equations Enforce purely geometric constraints once interpenetration has occurred
- 51. 51 Fixed Time Step Simulation Numerical simulation works best if the simulator uses a fixed time step e.g., choose ∆t = 0.02 seconds for physics updates of 1/50 second Do not change ∆t to correspond to frame rate Instead, write an inner loop that allows physics simulation to catch up with frame rate, or wait for frames to catch up with physics before continuing This is easy to do Read the text for more details and references!
- 52. 52 Final Comments Simple Games Closed-form particle equations may be all you need Numerical particle simulation adds flexibility without much coding effort Collision detection is probably the most difficult part of this Generalized Rigid Body Simulation Includes rotational effects and interesting (non- constant) forces See text for details on how to get started
- 53. 53 Final Comments Full-Up Simulation The text and this presentation just barely touch the surface Additional considerations Multiple simultaneous collision points Articulating rigid body chains, with joints Friction, rolling friction, friction during collision Mechanically applied forces (motors, etc.) Resting contact/stacking Breakable objects Soft bodies Smoke, clouds, and other gases Water, oil, and other fluids
Editor's Notes
- This presentation focuses on the more introductory subjects from the text, and so there is far more detail in basic particle simulation than generalized rigid body simulation. Refer to the text and references for more details on generalized simulation.
- At the present time, asset creation tools are not mature enough for physics to be as automatic as we would like. It currently requires quite a bit of work to get physics “right.” And so the cost of putting physics into a game may not be significantly cheaper than traditional animation approaches at this time. This should change as the physics tools improve. Artists should not worry that physics simulations will soon take over their jobs. This is particularly true for character and character-like animation. Physics and AI engines aren’t to the level yet where they can properly simulate the personality of characters that shows through in their motions!
- Traditional theoretical physics defines a particle as a mass with no volume. We loosen the definition here since we are going to skip over quite a bit of very low level background material
- The importance of using consistent units cannot be stressed strongly enough. Read the text for more details.
- Here, the quantity in parentheses, (t) and (t+Dt), indicates that a value is a function of (t) rather than multiplication by (t) or (t+Dt)
- Here, the terms on the right such as g(t-tinit) indicate multiplication by (t-tinit), rather than g being a function of (t-tinit). The perils of inconsistent and contradictory notation exist throughout math and science. See Chapter Zero in Jim Blinn’s book, Notation, Notation, Notation, for further enlightenment related to this fact! *IMPORTANT NOTE: The closed form equations are exact; HOWEVER, they are only exact when the gravitational field is truly uniform, acting in the same direction throughout the gravitational field. In real life, on real planets, this is not the case, since when you move across the surface the direction to the center of mass of the planet changes. (In real life acceleration due to gravity doesn’t even act exactly towards the center of the planet, since the mass distribution of the planet isn’t constant, and fluctuates ever so subtly). But, for objects moving relatively small distances over the surface of large planets, the assumption of constant g is quite accurate. For space craft simulation, where the distance from the object to planet center is much larger than the planet radius, the assumption of constant g breaks down and isn’t at all accurate. The next step up is to use a central force approximation and use conservation of angular momentum to model the orbital motion. Could also just calculate the force due to gravity based on the relative location of two masses, using Newton’s Law of Universal Gravitation (or something more exotic).
- Under constant gravitional acceleration, projectile path is a parabola
- pinit=&lt;10,0,11&gt; meters ptarget-=&lt;50,0,11&gt; meters g=9.81 meters per second squared
- When Vinit reaches the critical value (producing radicand == 0), the launch angle, phi, will become exactly 45 degrees for the case where the projectile launch altitude and target altitude are the same.
- The launch angle producing the trajectory with the farthest reach is phi = 45 degrees.
- pinit=&lt;10,0,30&gt; meters ptarget-=&lt;50,0,1&gt; meters
- pinit=&lt;10,0,2&gt; meters ptarget-=&lt;50,0,20&gt; meters
- By “closed-form” we mean the solution is one or more simple algebraic equations that we can immediately solve for the object’s exact position or velocity at any time in the future, without time-stepping, based on the conditions at the start of the simulation.
- Numerical “solutions” are never true solutions. They are approximate solutions. Their very derivation introduces error, called truncation error, that is always present in finite difference methods.
- In some VERY special cases, the truncation error in finite difference simulation can be exactly zero. For example, if velocity is constant (zero acceleration), the truncated Taylor series used to derive the explicit Euler finite difference integrator has zero truncation error since the higher-order derivatives are exactly zero. In this case, the numerical method is identical to the closed-form solution and apart from floating point roundoff produces exact results. As in the prior slides, these situations are not usually very interesting!
- Initial state and state derivative are derivated from initial position and velocity mV is the linear momentum of the particle. See text for more info.
- Note that the numerical prediction for linear momentum is the same as the exact solution. This is because the first state derivative of linear momentum is a constant, mg. All of the higher-order time derivatives of linear momentum are exactly zero, and so the truncated Taylor series for explicit Euler integration happens to exactly represent linear momentum. Truncation error for these terms is zero, and the numerical solution is just as good as the closed-form solution. In fact, you can show that it turns out to be exactly the same as the equation on slide #14 for V(t), multiplied by m to obtain a linear momentum equation. Also note that the numerical prediction of px and py are exact. This is because the velocity is constant in x and y. The acceleration (second derivative of state) is zero in x and y and so in these two directions the truncated Taylor series (which does not contain second or higher time derivatives) happens to be exact. In z, however, pz for the numerical prediction is NOT correct. Reason being, the acceleration is nonzero and the truncated Taylor series for explicit Euler integration of position does not contain the second time derivative of position. Explicit Euler integration is what is known as a consistent numerical method. This means that as the time step, t, is reduced, the solution approaches the exact solution. If Dt goes to zero in the limit,explicit Euler would produce the exact, perfect solution.
- We can estimate truncation error easily if we know the exact solution (which we only rarely do----constant force motion is one such case), by just computing the difference between the numerical solution and the exact solution. The truncation errors are not directly comparable until we normalize them by dividing by the time step, e.g., we can directly compare (truncation_error / Dt) for different values of Dt. This is only an estimate because floating point roundoff error is also present, in both the numerical solution and the computed “exact” solution. So the “truncation error” above is really “truncation error + floating point roundoff effects” It actually is possible to estimate truncation error even if we don’t know the exact solution. We can use other finite difference formulas to numerically compute an estimate to the truncation error. This is of interest to hardcore numerical mathematicians who wish to observe the behavior of error as a complex problem progresses.
- Using results from the prior slide, this chart illustrates that explicit Euler integration if first-order accurate in time, e.g., truncation error grows as a linear function of Dt. The truncation error clearly goes to zero when Dt goes to zero, in the limit. This is a characteristic of a consistent numerical method. The only valid numerical methods are those that are consistent, whose error goes to zero in the limit as Dt goes to zero. For more general problems, e.g., those with non-constant forces, the truncation error remains O(t); however, in practice the error is never a perfectly linear curve (or, for O(Dt2) methods, a perfect parabola, etc.) See the text and references for more details on truncation error
- pinit=&lt;10,0,2&gt; meters ptarget-=&lt;50,0,20&gt; meters Vinit=30 meters per second
- IMPORTANT NOTE: The only way to properly use the Verlet integrator shown above is to choose a fixed time step, Dt, for physics simulation. The very derivation of the Verlet finite difference integrator is based on the assumption of a fixed time step!
- Verlet integration as documented here does not track velocity. In order to track velocity, use another integrator, such as explicit Euler, in parallel with Verlet, e.g., use explicit Euler to track velocity and Verlet to track position.