Update
This commit is contained in:
parent
2efc415ac4
commit
70c10acfc5
61 changed files with 1970 additions and 1954 deletions
|
@ -8,7 +8,7 @@ Physics engine is a [software](software.md) (usually a [library](library.md) or
|
|||
|
||||
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 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:
|
||||
Physics engine is a quite wide term -- even though one usually imagines something akin to 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](pseudo3d.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.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue