+ Physics is the most basic feature for an open-world game to run. "Physics" here only refers to the + interactions between and kinetics of physical objects in a World, without interference from other energy. + In Orryx, physics may be parameterized for Application Extensive Modules (AXMs) to extend and + customize physics behaviors for their own implementations of worlds. Most of the computations + related to physics shall be run in Ferricia, with certain parameters and attributes configurable + by the Kryon layer. Some of them may even be sometimes constant while variable the other times. +
++ While the entire physics engine is based on Open Dynamics Engine (ODE), most working details would + likely be explained in terms of it. However, several conceptual ideas may also be explained in mechanical + physics, likely with related theories, laws, algorithms and formulae. +
++ Since TerraModulus is tile-based, or block-based, in most of the time, Tiles should be stationary + and rigid with contact of other Tiles. However, Entities may act in any way, with various possible + motions and combinations, even potentially with joints and islands. +
++ Units and coordinate system in physics engine should one-to-one align with the ones seen in Kryon. + This means, the x-axis, y-axis, z-axis must comply exactly the same across those systems. + For basic units, meters and Newtons may also be used, as they are the units used in ODE. +
++ There would likely be special measures for moving Tiles. Since Tiles are expected to be aligned with + integral coordinates, moving instances that do not meet this criterion may be undefined. + Therefore, moving Tiles shall likely be implemented as special Entities with some effects being Tiles, + unless Tiles are instantly moved without any transition. +
++ Most likely all bodies shall have uniform mass, although implementations may still use ununiform + masses in certain bodies for special games. Most bodies likely do not rotate except for certain + bodies in certain Entities, so forces applied on should be uniform without causing torques. +
++ Certain geometry objects would be implemented with special meanings. World boundaries should be + planes, while others may be created in any way for Tiles and Entities. However, Tiles as non-placeable + may be as collision spaces containing several geometry objects including boxes. Some objects without + certain shapes may be made as meshes, but this should not be common. There is no plan to include + arbitrary Worlds, so heightfield and convex shall not be used. Other than these, no custom classes + shall be implemented. It is a question whether Tiles should be implemented as composite bodies. +
++ Although, there is likely no default complete physics implementation, certain common configurations + may still be possible to be made officially as simple implementations for ready-for-production + developments of other contents without having to implement their own ones by their own. +
++ As a simple interpretation of an open world with simple and common interactions in various games, + this implementation may be simple, though certain parameters may still be made. This may resemble + the physics as on Earth, but gravity may be configurable for authors with a default value. +
++ Most Tiles and Entities should be inelastic; world boundaries should also be completely inelastic. + However, certain Tiles and Entities may be elastic, from configurations by authors. + Without specific settings, those bodies should be inelastic, including collisions between Entities. +
++ There would likely be two modes for Tiles, where for one, all Tiles fall while the other only + certain selections of Tiles may fall. +
+
+ Physics Engine shall be initiated via PhyEnv when a World is being initiated
+ along with other World resources. Then, other World, Space, Body and Geom instances are
+ created as initialization of resources. With PhyWorld created under PhyEnv,
+ where PhyEnv handles OdeHandle; PhyWorld also handles
+ OdeWorld, TopLevelSpace and a list of PhyObj, where
+ OdeWorld is a representation of ODE World, and TopLevelSpace
+ is the top-most ODE Space, with each of them handling underlying OdeBody and
+ OdeGeom; PhyObj has two implementations, PhyBody and
+ PhyGeom, where PhyBody is the physics representation of a Body
+ which is either or both associated with an OdeBody, or having one or more
+ OdePlaceableGeom. Associations of ODE Geom and ODE Body are handled by
+ the abstraction of them, PhyBody; ODE Bodies are always created in OdeWorld
+ while ODE Geoms are always created in TopLevelSpace.
+
+ User-defined data should not be stored in ODE objects, but only on our side with those handling
+ the interactions with those ODE objects. Mostly, phy::ode module handles abstraction
+ of actions provided by ODE's interface, while other higher level operations should reside in
+ phy module directly. Seemingly, Kryon's internal would directly interact with
+ objects in phy, and indirectly with objects in phy::ode.
+
+ PhyEnv shall also handle collision activities observed by executing ODE's loop.
+ CollisionHandler from PhyEnv handles collisions by generating
+ OdeContactJoint from OdeContactGeom, while all parameters depend on
+ properties of objects in interaction. Those properties should be defined by properties of
+ Tiles and Entities, so they are fully up and subject to Kryon.
+