diff --git a/efp/efp015/main.xml b/efp/efp015/main.xml new file mode 100644 index 0000000..423c855 --- /dev/null +++ b/efp/efp015/main.xml @@ -0,0 +1,124 @@ + + + + + + + + +
+ +

+ 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. +

+ +
+
+
+ + +
  • Open Dynamics Engine (ODE) Community Wiki
    • +     +     +
    + +