Physics engine Study Guide

📖 Core Concepts Physics Engine – Software that approximates classical dynamics (rigid‑body, soft‑body, fluid) for interactive or offline use. Real‑Time Engine – Prioritizes speed; uses simplified calculations so the frame rate stays high (e.g., video games). High‑Precision Engine – Prioritizes accuracy; runs slower and is used for scientific research or pre‑rendered movie effects. Collision Geometry – An invisible, simplified shape (bounding box, sphere, convex hull) used for fast collision checks; distinct from the visible mesh. Broad‑Phase vs. Narrow‑Phase – Two‑step detection: broad‑phase quickly discards non‑colliding pairs using simple shapes; narrow‑phase performs detailed mesh‑on‑mesh tests on the remaining pairs. Continuous Collision Detection (CCD) – Checks the swept path of fast objects each step to avoid “tunneling” when frame rates are low. Sleep Mechanism – Temporarily disables physics updates for objects that have been static for a short period, saving CPU cycles. Simulation Paradigms Penalty – Treats contacts as mass‑spring systems. Constraint‑based – Solves equations that enforce physical laws (e.g., joints). Impulse‑based – Applies instantaneous momentum changes; a special case of constraint solving using an iterative solver. Hybrid – Combines two or more of the above. Specialized Hardware – PPU (dedicated physics processor) and GPGPU (general‑purpose GPU computing) accelerate the heavy linear algebra of physics solvers. --- 📌 Must Remember Physics engines are approximate, not exact, simulations of classical dynamics. Real‑time ⇒ speed > accuracy; High‑precision ⇒ accuracy > speed. Collision geometry is simplified (box, sphere, convex hull) for performance. Broad‑phase eliminates most pair tests; narrow‑phase does the precise check. CCD solves the “tunneling” problem caused by low frame rates. Sleep reduces CPU load; objects wake up when a collision or external force exceeds a threshold. Penalty = spring‑like forces; Constraint = solve equations; Impulse = apply momentum change iteratively. Solver convergence issues (e.g., slow Projected Gauss‑Seidel) can cause jitter or unrealistic forces. Higher precision → more CPU/GPU cost; trade‑off must be managed. PPU and GPGPU offload physics from the main CPU, similar to how a GPU offloads graphics. --- 🔄 Key Processes Collision Detection Pipeline Broad‑phase: Insert each object’s collision geometry into a spatial acceleration structure (e.g., AABB tree). Pair pruning: Quickly discard pairs that cannot intersect. Narrow‑phase: Perform detailed triangle‑or‑edge checks on the remaining pairs. Contact generation: Create contact points, normals, and penetration depths. Collision Response (Impulse‑based) Compute relative velocity at contact. Calculate impulse magnitude using the coefficient of restitution and inverse masses. Apply impulse to each body’s linear and angular momentum. Iterate (Gauss‑Seidel) until contacts converge or a max iteration count is reached. Sleep / Wake Cycle Track linear & angular velocity each step. If both stay below a tiny threshold for N consecutive frames → mark object asleep (skip dynamics & collision updates). Any collision or external force above the threshold → wake the object. Hybrid Solver Workflow Use penalty springs for soft‑body deformation. Apply constraint solver for rigid joint limits. Resolve contacts with impulse solver. Iterate through all three sub‑solvers each time step. --- 🔍 Key Comparisons Real‑Time vs. High‑Precision Real‑Time: simplified force integration, fewer solver iterations, perceptual accuracy. High‑Precision: fine‑grained integration, many solver passes, scientifically accurate results. Broad‑Phase vs. Narrow‑Phase Broad‑Phase: cheap bounding‑volume tests, reduces candidate pairs. Narrow‑Phase: expensive mesh‑level tests, provides exact contact data. Penalty vs. Constraint vs. Impulse Penalty: forces proportional to penetration (spring‑like). Constraint: solves exact equations (e.g., joint limits). Impulse: instantaneous momentum change; iterative, often used for contacts. Rigid Body vs. Soft Body Rigid: no deformation; dynamics governed by translation & rotation only. Soft: internal finite elements/ springs; deformation, stress, fracture simulated. PPU vs. GPGPU PPU: specialized physics chip, fixed‑function pipelines. GPGPU: general‑purpose GPU cores repurposed for physics via parallel kernels. --- ⚠️ Common Misunderstandings “Physics engines give exact physics.” – They use approximations; energy may not be perfectly conserved. “Collision geometry must match the visual mesh.” – It is deliberately simplified for speed. “Sleeping objects never move.” – They are only inactive until a sufficient external influence occurs. “Impulse and constraint methods are unrelated.” – Impulse solvers are a subset of constraint solvers using an iterative approach. “Higher precision always improves gameplay.” – The extra CPU cost can lower frame rates, hurting player experience. --- 🧠 Mental Models / Intuition Physics Engine = Fast “Guess” of Reality – Think of it as a rapid, iterative sketch that looks right enough for the eye. Collision Detection = “First filter, then inspection.” – Broad‑phase is the security guard; narrow‑phase is the detailed ID check. Sleep = “Object takes a nap until disturbed.” – No calculations while the object is quiet; a collision is the alarm clock. Penalty vs. Constraint = “Soft spring vs. Rigid ruler.” – Springs let things wiggle; rulers enforce exact distances. --- 🚩 Exceptions & Edge Cases Tunneling – Extremely fast objects can pass through thin colliders between frames; CCD mitigates but may still fail at very high speeds. Solver Divergence – Poorly conditioned constraint systems can cause the iterative solver to oscillate, producing jitter or exploding forces. Interpenetration Corrections – After a collision, engines may push objects apart with a large corrective impulse, causing “popping” artifacts. Low Frame Rate – Increases the chance of missed collisions and larger positional errors. --- 📍 When to Use Which Game Development → Real‑time engine with broad‑phase bounding volumes, impulse‑based contacts, and sleep mechanisms. Scientific / Film Pre‑render → High‑precision engine, continuous collision detection, and soft‑body finite‑element solvers. Soft‑Body Objects → Penalty or hybrid method (springs + constraints) for realistic deformation. Rigid‑Body Characters (Ragdolls) → Constraint‑based joint limits combined with impulse contacts. Performance‑Critical Scenes → Switch to simpler collision geometry, enable sleep, reduce solver iterations. GPU‑Rich Platforms → Offload bulk force calculations and broad‑phase to GPGPU kernels. --- 👀 Patterns to Recognize Bounding volume listed first → Expect broad‑phase optimization. Frequent “sleep” flags → Engine is conserving CPU; look for wake‑up conditions in the problem. Mention of “impulse” or “iterative solver” → Likely an impulse‑based contact resolution. “Continuous collision detection” → Problem involves fast‑moving projectiles or thin obstacles. “Finite element” or “tessellation” → Soft‑body dynamics, stress/strain calculations. --- 🗂️ Exam Traps Distractor: “Physics engines always conserve total energy.” – Wrong; numerical damping and constraint corrections can add or remove energy. Distractor: “Collision geometry must be the exact visual mesh.” – Incorrect; simplified geometry is purposefully used. Distractor: “Sleep disables all physics for the object forever.” – False; objects wake on impact or external force. Distractor: “PPU and GPU are interchangeable.” – Not true; PPUs are dedicated physics processors, GPUs are general‑purpose parallel processors. Distractor: “Continuous collision detection eliminates tunneling completely.” – Even CCD can miss collisions at extreme speeds or with insufficient time steps. ---