Update

physics_engine.md

@@ -2,13 +2,13 @@
 
 { [LRS](lrs.md) now has a very small 3D physics engine called [tinyphysicsengine](tinyphysicsengine.md). ~drummyfish }
 
-Physics engine is a [software](software.md) (usually a [library](library.md)) whose purpose is to simulate physics laws of mechanics, i.e. things such as forces,  [rigid](rigid_body.md) and [soft](soft_body.md) body collisions, [particle](particle.md) motion, fluid dynamics etc.
+Physics engine is a [software](software.md) (usually a [library](library.md) or [framework](framework.md)) whose purpose is to simulate mechanical laws of real life physics, i.e. things such as forces, [rigid](rigid_body.md) and [soft](soft_body.md) body collisions, [particle](particle.md) motion, fluid dynamics etc. Where to draw the line between physics engines and "other software" is not exactly clear, a lot of software somehow takes real life physics into account without being called "physics engine", typically e.g. [3D rendering](3D_rendering.md) software, but in general if it focuses on motion, forces, collision etc., it may fall into this category.
 
 { When it comes to classic 3D rigid body physics engines, they're extremely hard to make, much harder than for example an advanced 3D rendering engine, especially when you want to make them [LRS](lrs.md) (without floating point, ...) and/or general and somewhat physically correct (being able to simulate e.g. the Dzhanibekov effect, satisfying all the conservation laws, continuous collision detection etc.). Good knowledge of mechanics and things like [quaternions](quaternion.md) and 3D rotations is just the beginning, difficulties arise in every aspect of the engine, and of those there are many. As I've found, 32 bit fixed point is not enough for a general engine (even though it is enough for a rendering engine), you'll run into precision problems as you need to represent both relatively high and low energies. You'll also run into stability issues such as stable contacts, situations with multiple objects stacked on top of each other starting to bounce on their own etc. Even things such as deciding in what order to resolve collisions are very difficult, they can lead to many bugs such as a car not being able to drive on a straight road made of several segments.  Collision detection alone for all combinations of basic shapes (sphere, cuboid, cylinder, capsule, ...  let alone general triangle mesh) are hard as you want to detect general cases (not only e.g. surface collisions) and you want to extract all the parameters of the collisions (collision location, depth, normal etc.) AND you want to make it fast. And of course you'll want to add acceleration structures and many other thing on top. So think twice before deciding to write your own physics engine.
 
 A sane approach may be to write a simplified engine specifically for your program, for example a Minetest-like game may just need non-rotating capsules in a voxel environment, that's not that hard. You can also get away with a bit of cheating and faking, e.g. simulating rigid bodies as really stiff soft bodies, it may not be as efficient and precise but it's simpler to program. It may be [good enough](good_enough.md). Well, that's basically what [tinyphysicsengine](tinyphysicsengine.md) does anyway. Old playstation game Rally Cross apparently did something similar too. ~drummyfish }
 
-Physics engine is a wide term even though one usually imagines the traditional 3D rigid body engine used in games such as [GTA](gta.md). These engines may nevertheless have different purposes, features and even basic paradigms, some may e.g. be specialized just for computing precise ballistic trajectories for the army, some may serve for simulating weather etc. Some common classifications and possible characteristics of physics engines follow:
+Physics engine is a quite wide term -- even though one usually imagines something akin the typical real time 3D rigid body engine used in [games](game.md) such as [GTA](gta.md), there are many other types with vastly different purposes, features and even basic paradigms, some may e.g. be specialized just for computing precise ballistic trajectories for the army, only spitting out numbers without providing any visualization, some may serve for simulating and forecasting weather, some may simulate the evolution of our [Universe](universe.md) etc. Some common classifications and possible characteristics of physics engines follow:
 
 - **[2D](2d.md) vs [3D](3d.md)**: 2D engines are generally much more simple to implement than 3D, for example because of much more simple math for rotations and collision detection. Graphics and physics are usually loosely interconnected (though they should be [decoupled](coupling.md)) in that the way in which we represent graphics (2D, general 3D, [BSP](bsp.md), [voxels](voxel.md), ...) usually also determines how we compute physics, so that there may also exist e.g. "[pseudo 3D](pseudo_3d.md)" physics engines as part of "pseudo 3D" renderers, e.g. the one used in [Doom](doom.md) etc.
 - **[real time](real_time.md) vs [offline](offline.md)**: Real-time ones are mostly intended to be used in the entertainment industry, i.e. [games](game.md), movies etc. as they can compute somewhat realistic looking results quickly but for the price of dropping high accuracy (they use many [approximations](approximation.md)). Scientific engines may prefer to be offline and taking longer time to compute more precise results.