Increased Detail of 3D Graphics Pipeline Stages

PLANNING.md

@@ -5,8 +5,20 @@
 ## Table of Contents
 
  1. [Introduction](#introduction)
- 2. [C++ Language](#c-language)
+ 2. [TODO](#todo)
- 3. [Math Library](#math-library)
+ 3. [C++ Language](#c-language-library-lang)
+ 4. [Math Library](#math-library-math)
+ 5. [Memory Library](#memory-library-memory)
+ 6. [Containers Library](#containers-containers)
+ 7. [Language Processing](#language-processing-proclang)
+ 8. [Core](#core-core)
+    1. [Tick](#tick)
+    2. [Frame](#frame)
+ 9. [Scene](#scene-scene)
+ 10. [3D Graphics](#3d-graphics-gfx3d)
+ 11. [3D Physics](#3d-physics-physics3d)
+ 12. [Artificial Intelligence](#artificial-intelligence-ai)
+
 
 
 ## Introduction
@@ -26,10 +38,26 @@ System implementations should be independent of architecture or platforms. i.e.
 not care if OpenGL or Vulkan is used and should not use any direct calls to OpenGL or Vulkan.
 
 
+
+
+
+## TODO
+
+ - 2D Graphics (`gfx2d`)
+ - 2D Physics (`physics2d`)
+ - 2D & 3D Audio (`audio`)
+
+
+
+
+
 ## C++ Language Library (`lang`)
 
 Implement header files for standard functions relating to the C++ Language.
-So far this is implemented on an as-needed basis.
+So far this is implemented on an as-needed basis. A full implementation should be worked on continuously.
+
+
+
 
 
 ## Math Library (`math`)
@@ -41,6 +69,9 @@ to Linear Algebra, Mathematical Analysis, and Discrete Analysis. Additional exte
 as-needed basis.
 
 
+
+
+
 ## Memory Library (`memory`)
 
 Implement headers related to memory allocation in C++.
@@ -49,6 +80,22 @@ Implement headers related to memory allocation in C++.
  - Memory Allocation
 
 
+
+
+## Containers (`containers`)
+
+All containers of the [C++ Standard Library](https://cppreference.com/w/cpp/container.html) should be implemented.
+
+Here are essential data-structures not specified in the C++ stdlib:
+ - Graph → AI `graph`
+   - Necessary for 2D and 3D navigation.
+ - Rooted Directed Tree `rd_tree`
+   - Defines the scene structure.
+
+
+
+
+
 ## Language Processing (`proclang`)
 
 Pronounced [pɹˈɒkh,læŋ](https://itinerarium.github.io/phoneme-synthesis/?w=pɹˈɒkh,læŋ)
@@ -78,6 +125,14 @@ fennec should be able to use Doxygen and LaTeX externally. Consider including bi
    - Spreadsheets & Tables
      - ODS
      - CSV
+   - Graphics Formats
+     - BMP
+     - JPG
+     - PNG
+     - TIFF
+     - DDS
+     - Wavefront OBJ
+     - FBX
 
 **MAYBE**
  * Compilation  (`proclang/code`)
@@ -89,6 +144,9 @@ fennec should be able to use Doxygen and LaTeX externally. Consider including bi
    * Target Code Generation
 
 
+
+
+
 ## Core (`core`)
 
 This will be the core of the engine.
@@ -96,12 +154,17 @@ This will be the core of the engine.
  - Event System
  - Core Engine Loop
    - System Manager
+   - Ticks vs. Frames
 
-The priority sequence of the main systems is as follows:
+The following systems are not essential to the core engine, but are instead major systems that should be defined
+in their operation order:
 
 **3D Systems will apply *before* their 2D Variants**
 
+
+### Tick
  - **Update**
+   - Events
    - Scripts
    - AI
  - **Physics**
@@ -115,10 +178,28 @@ The priority sequence of the main systems is as follows:
      - Soft Bodies resolve before Rigid Bodies
    - Collision Response
      - Calculate Forces
-   - 
- - **Graphics**
 
-## 3D Scene (`scene3d`)
+
+### Frame
+ - **Graphics**
+   - See [Stages](#stages-gfx3d)
+ - **Audio**
+
+
+
+
+
+## Application Layer (`app`)
+
+This is the core windowing system of fennec. The implementation will initially be an SDL3 wrapper.
+Custom implementation may be further down the roadmap, however this is extremely complicated and there are better
+implementations than I could write.
+
+
+
+
+
+## Scene (`scene`)
 
 * In-Array Directed Tree
   * Elegant method for providing `O(1)` insertions and `O(log(n))` deletions.
@@ -126,78 +207,185 @@ The priority sequence of the main systems is as follows:
     * Octree
 
 
+
+
+
+## 2D Graphics (`gfx2d`)
+
+
+
+
+
+
+
 ## 3D Graphics (`gfx3d`)
 
 Links:
- - https://en.wikipedia.org/wiki/Octree
+- https://en.wikipedia.org/wiki/Octree
- - https://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/
+- https://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/
- - https://learnopengl.com/PBR/Lighting
+- https://learnopengl.com/PBR/Lighting
- - https://learnopengl.com/PBR/IBL/Diffuse-irradiance
+- https://learnopengl.com/PBR/IBL/Diffuse-irradiance
- - https://en.wikipedia.org/wiki/Schlick%27s_approximation
+- https://en.wikipedia.org/wiki/Schlick%27s_approximation
- - https://pixelandpoly.com/ior.html
+- https://pixelandpoly.com/ior.html
- - https://developer.download.nvidia.com/SDK/10/opengl/screenshots/samples/dual_depth_peeling.html
+- https://developer.download.nvidia.com/SDK/10/opengl/screenshots/samples/dual_depth_peeling.html
 
-**DirectX will never have official support.** If you would like to make a fork, have at it, but know I will hold a deep disdain for you.
+**DirectX will never have official support.** 
+If you would like to make a fork, have at it, but know that I will hold a deep disdain for you.
+
+The graphics pipeline will have a buffer with a list of objects and their rendering data.
+This will be referred to as the Object Buffer. There will be two, for both the Deferred and Forward Passes.
+
+The buffers will be optimized by scene prediction. This involves tracking the meshes directly and indirectly used by a scene.
+
+Materials and Lighting models will be run via a shader metaprogram to make the pipeline independent of this aspect. 
+This allows the GPU to draw every single deferred rendered mesh in a single draw call for each stage of the renderer.
+
+Specifications for debugging views via early breaks are included in the stages.
+
+
+### Stages (`gfx3d`)
 
 This is the set of stages for the graphics pipeline that runs every frame:
+Unless otherwise specified, each stage will be run on the GPU.
 
- - LOD Selection
+ - BVH
- - Visibility Buffer & Culling
+   - Octree
+     - Leaf Size and Tree Depth should be calculated by the scene, constraints are as follows:
+       - Min Object Size
+       - Max Object Size
+       - Scene Center
+       - Scene Edge
+     - Insertions and Updates are done on the CPU
+     - Nodes
+       - ID 16-bits
+       - Start Index 32-bits
+       - Object Count 16-bits
+     - Objects
+       - Buffer of Object IDs grouped by Octree Node
+   - Culling
+     - Starting at each Octree Leaf, traverse upwards.
+     - Insert Visible Leaf IDs
+       - Track using atomic buffer
+   - Output: Buffer of Visible Leaves
 
- * G-Buffer Pass
+* LOD Selection
-   * Depth - Stencil
+  * Generate the Command Buffer for Culled Mesh LODs from the Visible Leaf Buffer
-     * 24-Bit Depth Buffer
+    * Track counts using atomic buffers
-     * 8-Bit Stencil Buffer, used to represent the lighting model.
+    * To avoid double counting due to the structure of the Octree output, we have some options
-   * Diffuse - RGB8
+      * Ignore Leaf Instances based on occurrences of the mesh in the surrounding 16 Octree Leaves. This would require
-   * Emission - RGB8
+        a bias towards a specific corner of the filter.
-   * Normal - RGB8
+      * Perform a preprocessing step on the CPU to erase duplicate elements and fix the buffer continuity.
-   * Specular - RGB8
+      * Let the duplicates be rendered.
-     * R → Roughness
+  * Generate the Culled Object Buffer by copying objects from the Object Buffer
-     * G → Specularity (sometimes called metallicism)
+    * Adjust Buffer Size using the counts
-     * B → Index of Refraction (IOR)
+    * Insert using another atomic buffer
+
+Debug View: Object ID, Mesh ID, LOD
+
+- Visibility
+  - Buffer - RGB32I w/ Depth24
+    - G = Object ID
+    - B = Mesh ID
+  - Regenerate the Command Buffer for Visible Mesh LODs
+  - Regenerate the Culled Object Buffer
+
+Debug View: Visibility Buffer
+
+* G-Buffer Pass
+    * Depth - Stencil
+        * 24-Bit Depth Buffer
+        * 8-Bit Stencil Buffer, used to represent the lighting model.
+    * Diffuse - RGB8
+    * Emission - RGB8
+    * Normal - RGB8
+    * Specular - RGB8
+        * R → Roughness
+        * G → Specularity (sometimes called metallicism)
+        * B → Index of Refraction (IOR)
+
+Debug View: Depth, Stencil, Diffuse, Emission, Normal, Specularity
+
+- Lighting Pass
+    - Generate Dynamic Shadows
+    - Generate Dynamic Reflections (Optional)
+    - SSAO (Optional)
+    - Apply Lighting Model
+    - Output → RGB16
+
+Debug View: Shadows, Reflections, SSAO, Deferred Lighting
+
+* Forward Pass
+    * BVH, Same as Above
+    * LOD Selection, Same as Above
+    * Translucent Materials
+      * Dual Depth Peeling
+
+Debug View: Deferred and Forward Mask
+
+- Post Processing
+    - Depth of Field (Optional) → Poisson Sampling
+    - Bloom (Optional) → Mipmap Blurring
+    - Tonemapping (Optional)
+    - HDR Correction
 
- - Lighting Buffer - RGB16
- - Lighting Pass
-   - Generate Dynamic Shadows
-   - Generate Dynamic Reflections (Optional)
-   - SSAO (Optional)
-   - Apply Lighting Model
 
- * Forward Pass
-   * Translucent Materials
-   * Materials with Forward Shading enabled.
 
- - Post Processing
-   - Depth of Field (Optional)
-   - Bloom (Optional)
-   - Tonemapping (Optional)
-   - HDR Correction
 
 ## 3D Physics `(physics3d)`
 
 Links:
- - https://www.researchgate.net/publication/264839743_Simulating_Ocean_Water
+- https://www.researchgate.net/publication/264839743_Simulating_Ocean_Water
- - https://arxiv.org/pdf/2109.00104
+- https://arxiv.org/pdf/2109.00104
- - https://www.youtube.com/watch?v=rSKMYc1CQHE
+- https://www.youtube.com/watch?v=rSKMYc1CQHE
+- https://tflsguoyu.github.io/webpage/pdf/2013ICIA.pdf
+- https://animation.rwth-aachen.de/publication/0557/
+- https://github.com/InteractiveComputerGraphics/PositionBasedDynamics?tab=readme-ov-file
+- https://www.cs.umd.edu/class/fall2019/cmsc828X/LEC/PBD.pdf
 
 Systems
 
- * Rigid Body System
+* Rigid Body Physics
- - Particle Physics
+    * Newtonian Physics and Collision Resolution
- * Soft Body Physics
+    * Articulated Skeletal Systems
-   * Elastics → Finite Element Simulation
+        * Inverse Kinematics
-   * Cloth → Position-Based Dynamics
+        * Stiff Rods
-   * Water
+- Particle Physics
-     * Oceans → iWave
+* Soft Body Physics
-       * Reasoning: iWave provides interactive lightweight fluid dynamics suitable for flat planes of water. 
+    * Elastics → Finite Element Simulation
-         <br><br>
+    * Cloth &rarr; Position-Based Dynamics
+    * Water
+        * Oceans &rarr; iWave
+            * Reasoning: iWave provides interactive lightweight fluid dynamics suitable for flat planes of water. Simulat
+              <br><br>
 
-     * 3D Fluid Dynamics &rarr; Smoothed-Particle Hydrodynamics
+        * 3D Fluid Dynamics &rarr; Smoothed-Particle Hydrodynamics
-       * Reasoning: This is the simplest method for simulating 3D bodies of water. This should exclusively be
+            * Reasoning: This is the simplest method for simulating 3D bodies of water. This should exclusively be
-         used for small scale simulations where self-interactive fluids are necessary. I.E. pouring water into
+              used for small scale simulations where self-interactive fluids are necessary. I.E. pouring water into
-         a glass. 
+              a glass.
-         <br><br>
+              <br><br>
 
-     * 2D Fluid Dynamics &rarr; Force-Based Dynamics
+        * 2D Fluid Dynamics &rarr; Force-Based Dynamics
-       * Reasoning: This model, like iWave, provides lightweight interactive fluid dynamics, but is more easily
+            * Reasoning: This model, like iWave, provides lightweight interactive fluid dynamics, but is more easily
-         adapted to flowing surfaces such as streams and rivers.
+              adapted to flowing surfaces such as streams and rivers.
+
+
+
+
+
+## Artificial Intelligence (`ai`)
+
+This artificial intelligence method only differs in static generation between 2D and 3D.
+The solvers are dimension independent since they work on a graph.
+
+The general process is; 
+
+Static:
+ - generate a static navigation graph (sometimes called a NavMesh)
+
+Update:
+ * resolve dynamic blockers
+ * update paths using dijkstra's algorithm
+ * apply rigid-body forces with constraints
+
+The update loop for artificial intelligence should only update every `n` ticks. Where `n <= k`, with `k` being the
+tick rate of the physics engine.

include/fennec/lang/float.h

@@ -30,7 +30,7 @@
 #ifndef FENNEC_LANG_FLOAT_H
 #define FENNEC_LANG_FLOAT_H
 
-#include <bits.h>
+#include <fennec/memory/bits.h>
 
 #define FLT_HAS_INFINITY 1
 #define FLT_HAS_QUIET_NAN 1