+ Alpha and Beta Stages of Orryx would be proposed separately. Until the end of the Stage, + its proposal would be held Provisional. +
++ In Alpha Stage, versions are under the theme of "Basis of Basics", with the major version zero. + During this Stage, no storage systems and customizations would be implemented, but rather + demonstrations of basic mechanisms of Orryx. This is unlike demo testing. +
++ All versions are incremented only on the minor version in the Primary Version, starting from + version 0.0.1. +
++ Demonstration may be basically based on physics implementation of Simple Terra with certain + extra features to interact with the World. At least, some functionalities should have been + available in this version. +
++ Random bodies may be generated to test for collisions and various features. Those bodies may + resemble certain kinds of Tiles and Entities. Players may control a sphere around the World. + For bodies, it may be possible to test for mechanisms for continuous Tiles in physics. + Tiles may be kinematic to be static for other moving bodies. +
++ On start, there would be no menus, but directly in a physics World after an animation. +
+ Various functionalities would be reserved for later implementations of other features. + However, for basic functions, basic body, mass and collision information should be done. + Later in the future if possible, it is possible to also test Bullet's Engine, as a comparison. +
+
+ An instance for each of PhyEnv, World and HashSpace
+ would be created on start of application. All Geom instances would be added
+ to the same Hash Space, with a Body of a Sphere the Player-controlled. Those instances
+ would include Boxes, Spheres, Capsules and Cylinders. There would also be a Plane at y=-100,
+ without other World boundaries.
+
+ Some Objects in the World would not be associated with any Body to be static. Certain Geom + may also be implemented as Composite Bodies to test for difference in functionalities. + Some Bodies with sets of continuous cubes with length of one meter with 3D random patterns + may also be generated in the World. +
++ For rendering, parallel projection over the level of the player character would be done. + Also, players would be able to fly around and move on the surface in any way. +
+- On start, there would be no menus, but directly in a physics World after an animation. + On start, there would be no menus, but directly in a physics World after a startup animation. + The content of the animation is yet purely demonstrative and not ready for production.
+ Different classes should hold different responsibilities precisely.
+ TerraModulus hold a major GuiManager and another manager that
+ is unrelated to User Interface (UI) as World.
+ Since the implementation of World is demonstrative and temporary, related classes shall be
+ placed under net.terramodulus.void package.
+
+ GuiManager shall hold Window, RenderSystem,
+ ScreenManager, and temporarily InputSystem.
+ In each frame, all pending Multimodel UI (MUI) events shall be polled and analyzed,
+ including storing all key events and processing them through InputSystem.
+ Then, ScreenManager shall update and refresh events to prepare for rendering.
+ Eventually, Window's Canvas shall be cleared and rendered with contents of
+ Screen(s) before swapping framebuffers.
+
+ In World, there shall be an isolated Thread ticking Ferricia's
+ World at a constant rate of 20 Hz. Ideally, time deltas should be calculated
+ for more accurate ticking, ensuring expected ticks being processed for a duration.
+ PhyEnv and PhyWorld must be created accordingly, with objects
+ generated afterward. Objects shall be stored in a map with ObjId using randomly
+ generated unique unsigned integers, with objects other than random test cubes created in
+ a fixed way for main character and spawn point cube. In the creation of World,
+ an instance of Ymir as the representative of preceding management in Client
+ with association to rendering and its properties. Ideally, generations of objects shall be
+ in parallel such that progress may be tracked on UI, without any invocation to OpenGL
+ during generation but after the end of generation when the role of generation handed back
+ to the main thread.
+
+ GameplayScreen handles initialization of World and rendering of it.
+ This includes the construction of Ymir and related VoidGeom classes.
+ In the Screen, a helper dummy Component GameplayRenderer is used to render
+ World objects after sorting, via renderGwrGeo from Ferricia.
+ A representative of player character as PlayerVoidGeom shall also be stored
+ in the GameplayScreen, though, it should not be a responsibility of a Screen.
+ At the same time, objects stored in World must also provide ability to access
+ information for rendering information without having to implement actual rendering-related
+ functions and interfaces directly in World, isolating rendering responsibility.
+ Events related to World should be handled in update functions, while others
+ related to UI should be handled via event listeners; controlling of player-directed events
+ shall also be handled via GameplayScreen.
+
+ ScreenManager initially adds LaunchingScreen, showing an animation
+ of logo of the host organization. Then, it transits to ResourceLoadingScreen,
+ showing the logo of TerraModulus; it is intended to track progress of resource loading, but
+ at the moment, there is no resource to load, a period of a second to stay on the logo without
+ showing a progress bar may be realized instead. Eventually, normally it should transit to
+ TitleScreen, but at this stage, GameplayScreen generated by
+ RenderSystem instead; though, it is not ideal to pass RenderSystem
+ through update functions.
+
@@ -66,11 +125,49 @@
+ In World, there shall be a sphere as the player-controlled character, a spawn point cube + and randomly generated cubes. While the sphere and the spawn point cube are always generated + at fixed positions, as (0, 1, 0) and (0, 0, 0) respectively; the sphere should be just placed + on the spawn point cube. Random cubes as test objects are generated using a fixed algorithm + with sets of random continuous patterns for each five meters apart; those cubes are generated + like maze generation that are branched from the origin and other branches. +
++ All objects must be in unit size of one meter in range of [-1,1] for local space. + However, for unit objects with only a single shape, its dimensions must align the limits. + This means the diameters or widths of the shapes should be two meters. As unit objects, + rotation and scaling may be identity, but must be scaled half in model transformation. +
++ Cubes shall be generated randomly in three colors, plain red, plain green and plain blue, + while the sphere shall be in full white. +
++ The sphere shall move at the speed of pi meters per second for each direction without + unit vector normalization. At each frame, the position of objects are fetched to render + the geometries, especially for the sphere. Also, players would be able to fly around and + move on the surface in any way, affected by collisions with other objects. +
+
- For rendering, parallel projection over the level of the player character would be done.
- Also, players would be able to fly around and move on the surface in any way.
+ Basically, since menus are incomplete at the current stage, temporary solutions for rendering
+ shall be employed just for basic startup animations and Gameplay World Rendering (GWR).
+ World rendering shall be handled by GameplayScreen via functions of GWR.
+
+ For rendering, orthogonal projection over the level of the player character would be done; + all objects shall be rendered without perspective transformation and culling. +
++ For camera and sizing, standard scaling shall be 64 screen pixels per meter in World space, + while normally it is expected that each Tile is rendered as 32-pixel width textures. + This means each texture pixel should be rendered as two times two screen pixels.
World,
an instance of Ymir as the representative of preceding management in Client
with association to rendering and its properties. Ideally, generations of objects shall be
- in parallel such that progress may be tracked on UI, without any invocation to OpenGL
- during generation but after the end of generation when the role of generation handed back
- to the main thread.
+ in parallel such that progress may be tracked on Graphical UI (GUI), without any invocation
+ to OpenGL during generation but after the end of generation when the role of generation
+ handed back to the main thread.
GameplayScreen handles initialization of World and rendering of it.
@@ -111,17 +111,65 @@
Later in the future if possible, it is possible to also test Bullet's Engine, as a comparison.
- An instance for each of PhyEnv, World and HashSpace
- would be created on start of application. All Geom instances would be added
- to the same Hash Space, with a Body of a Sphere the Player-controlled. Those instances
- would include Boxes, Spheres, Capsules and Cylinders. There would also be a Plane at y=-100,
+ The physics of World shall be initiated starting from PhyEnv along with other
+ top-level managers like PhyWorld and their internal management, upon creation.
+ All Geom instances along with just a single OdeGeom without a Body shall be added
+ to the same lower-level Hash Space; another Geom if Sphere with a Body shall be Player-controlled,
+ stored directly in the Top-Level Space. There shall also be a Plane at y=-100 as a floor boundary,
without other World boundaries.
- Some Objects in the World would not be associated with any Body to be static. Certain Geom
- may also be implemented as Composite Bodies to test for difference in functionalities.
- Some Bodies with sets of continuous cubes with length of one meter with 3D random patterns
- may also be generated in the World.
+ The PhyWorld holding all physics objects belonging to it is created byPhyEnv.
+ Most likely all physics objects should have respective owned handles, and the PhyWorld
+ and its underlying structures should only hold references to them. PhyObj has
+ two implementations, PhyBody and PhyGeom, where PhyBody
+ is the physics representation of a Body or Geom, and PhyGeom is the physics
+ representation of a non-placeable Geom. PhyRawGeom fully holds a Geom initially
+ upon creation but translation to PhyGeom destroys it.
+
+ In the structures with ODE, PhyEnv shall hold OdeHandle handling library
+ utilities and CollisionManager for collision handling assistance.
+ PhyWorld shall hold OdeWorld, TopLevelSpace and a list of
+ PhyObj. TopLevelSpace is the top-most Space, holding OdeSpace.
+ OdeWorld is used to handle OdeBody while OdeSpace is used
+ to handle OdeGeom. PhyBody holds either or both an OdeBody,
+ or one or more references of OdePlaceableGeom. Associations of ODE Geom and ODE Body
+ are handled by the abstraction of them in 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.
+
+ For flexibility to support other physics libraries, the abstraction layer in phy
+ module should be generalized enough with certain supporting functions in the future development
+ for the flexibility for other physics backends, most likely using traits as abstraction, with
+ the actual implementations initiated during initialization. This includes that library-dependent
+ interfaces should not be exposed across the Java-Native Interface.
+
+ Some Objects in the World would not be associated with any Body to be static. If some Objects + need to move but without inference from other Objects, they still need to be kinematic Bodies. + In a later stage, some Objects may be associated with a same Body as a Composite Body to test + for Body dynamics of Bodies composite of multiple Geom instances. +
+
+ PhyEnv shall also handle collision activities observed by executing ODE's loop.
+ PhyCollisionManager from PhyEnv handles collisions via underlying
+ OdeContactManager by generating OdeJoint from OdeContactParams
+ in near_callback, while all parameters depend on properties of objects in interaction.
+ Those properties should be later defined by properties of Tiles and Entities, so they should
+ be fully up and subject to Kryon.
+
+ At this stage, very basic optimization on the collision algorithm shall be done. This includes + benchmarked methods of using collision bits, intra-Space collision detection ignore list, + and a finer Hash Space for the Space of cubes.
- All objects must be in unit size of one meter in range of [-1,1] for local space. - However, for unit objects with only a single shape, its dimensions must align the limits. - This means the diameters or widths of the shapes should be two meters. As unit objects, - rotation and scaling may be identity, but must be scaled half in model transformation. + Currently, only geometries of unit sizes, lengths of one, are being generated. However, + at later stage, more geometries shall be tested for support of more complex models that + may appear in certain Tiles and Entities in reality. Also, those objects shall never rotate + upon external forces as torques are mostly not valid in the principles of mechanisms in TerraModulus.
Cubes shall be generated randomly in three colors, plain red, plain green and plain blue, - while the sphere shall be in full white. + while the sphere shall be in full white. Since the colors are plain, the differentiation + to identify relative location would likely be difficult without shadows or other mechanisms + that may help distinguishing distances of objects. +
++ In order to support feedbacks of collisions, the strategy to set velocities upon movement + may not be compatible, as those impacts seemed to be handled by instantaneous forces, which + result in calculated velocities. This means movements and other activities shall also act + forces on it to make effects in motions of the objects to avoid conflicts and malfunctions. + Therefore, movement shall be done by the unit direction vector resulted from player-directed + movement direction commands via keys of movement commanding, which shall be W, + S, A, D, Shift and Space. The movement + commands should direct the intended direction for forces to be exerted on. +
++ The recommended amounts of forces and limits to be applied on should be well tested, so they + may not be fixed even in the coming versions for balancing testing purposes. With plain + guessing of effects without actual calculations, those numbers currently are:
+- The sphere shall move at the speed of pi meters per second for each direction without - unit vector normalization. At each frame, the position of objects are fetched to render - the geometries, especially for the sphere. Also, players would be able to fly around and - move on the surface in any way, affected by collisions with other objects. + The movement calculation shall be done when the direction is not zero. Acceleration may not + be applied at a tick when maximal velocity (as speed) has been attained with that direction. + This is done by scalar projection of the instantaneous velocity on the target direction. + If the scalar projection is less than the maximal speed, an acceleration shall be applied. + Subtraction of the projection from the maximal speed is the maximal velocity to attain, + but it has to be clamped by the epsilon and the maximal acceleration. The final force exerted + shall be multiplication of the acceleration product of delta velocity and direction, and + a mass of 1.0.
@@ -161,28 +243,112 @@ World rendering shall be handled byGameplayScreen via functions of GWR.
- For rendering, orthogonal projection over the level of the player character would be done; - all objects shall be rendered without perspective transformation and culling. + During rendering, Geom objects shall be sorted first by y ascendingly, then z ascendingly. + At the moment, depth buffer is not yet used to render better z-ordering for occlusion. + There are currently only simple shapes and geometries being rendered, yet no more complex + rendering at this stage, but more different rendering properties shall be tested later. +
++ All Geom objects must be in unit size of one meter in range of [-1,1] for local space. + However, for unit objects with only a single shape, its dimensions must align the limits. + This means the diameters or widths of the shapes should be two meters. As unit objects, + rotation and scaling may be identity, but must be scaled half in model transformation. +
+
+ Graphical Menu Presentation (GMP) rendering is placed under mui::rendering
+ while Gameplay Field Visualization (GFV) rendering is placed under mui::rendering3d,
+ but ideally, certain functionalities and mechanisms should have been generalized out of them.
+ GMP may involve both two-dimensional (2D) and three-dimensional (3D) rendering but GFV only
+ involves 3D rendering in a different style from GMP rendering, so it may be complex handling.
+ In general, GMP may composite simpler geometries and general graph rendering; GFV may involve
+ composited meshes and combinations of different geometries as a whole.
+ "Field" of GFV indicates the Field of Camera View (FVC) while GMP may be described as
+ Plane Interface; Gameplay Scene Depiction (GSD) is the underlying environment of GFV.
+
+ There are special treatments for View and Projection matrices in GFV. For the View, + it is done by having a direction downward with an inclination of 30 degrees towards negative + z-axis. For the Projection, the dimensions are constrained directly by canvas dimensions while + there is no z-culling from viewpoint, along with magnification scaling and offset centering. + Perspective transformation is invalid as per the Principles, but culling should be applied + for most of the time to represent the Field in perspective of Player Character; this shall + be implemented and tested at later stage. +
++ For Camera and sizing in GFV, standard magnification scaling shall be defined by 64 screen pixels + per meter in World space, while normally it is expected that each Tile is rendered as 32-pixel + width textures. This means each texture pixel should be rendered as two times two screen pixels. +
++ There is simple basic light rendering to help differentiate the faces of geometries being + rendered in GFV, by a single directional light towards between negative y-axis and positive + z-axis, in addition to 10% ambient effect. Currently, they are all white light. However, + advanced light rendering like perspective occlusion and shadows shall be implemented later. +
+
+ Among 3D Geom structures in mui::rendering3d, only the Mesh variant is used.
+ In order to simplify the codebase and amount of work, utilizing an existing geometry library
+ that provides sufficient but not excessive functionalities shall be preferred in production.
+ At later stage, refactoring the codebase to utilize more existing libraries to avoid reinventing
+ the wheels shall be conducted under proper examination of libraries without violations to
+ the intended features and functionalities, but with feasible flexibilities and adaptions.
+
+ Basically, users can control the sphere using the aforementioned hotkeys, along with other + debugging hotkeys. Those keys can query states of the World and the sphere, and modify + attributes of those, including World gravity, gravity influence, friction attributes given + the capabilities of the physics engine. +
++ In details, movement keys add direction vectors when held; other hotkeys and functions include:
+- For camera and sizing, standard scaling shall be 64 screen pixels per meter in World space, - while normally it is expected that each Tile is rendered as 32-pixel width textures. - This means each texture pixel should be rendered as two times two screen pixels. + The units of vectors are directly come from the underlying physics engine. It is worth noting + that resulted acceleration or force is hidden and difficult to be queried, so it is ignored. + This includes the situation when multiple force sources exist to exert on, resulting a complex + state to be queried directly, so effective frictions can be hard to be examined easily. + The sphere can be either be influenced or not influenced by World gravity, according to + the effective mode; there are value boundaries for gravity to be tweaked, and there is + currently the parameter of downward (negative y-axis) gravity. There are three modes for + friction: Zero, Limited and Infinite; where Limited friction means a finite value of + the friction parameter shall be exerted, with a limited range of values. There was an + attempt to reset coordinates of the sphere to the spawn point, but the consistency of + physical states is difficult to be resolved, and thus currently only the velocity can be reset. + Zoom level of camera ranged from 1/4 to 4, with 1 the default scaling factor.