Increased Detail of 3D Graphics Pipeline Stages
This commit is contained in:
parent
fae7f601c9
commit
885cca6ca7
220
PLANNING.md
220
PLANNING.md
@ -5,8 +5,20 @@
|
||||
## Table of Contents
|
||||
|
||||
1. [Introduction](#introduction)
|
||||
2. [C++ Language](#c-language)
|
||||
3. [Math Library](#math-library)
|
||||
2. [TODO](#todo)
|
||||
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,6 +207,17 @@ The priority sequence of the main systems is as follows:
|
||||
* Octree
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 2D Graphics (`gfx2d`)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 3D Graphics (`gfx3d`)
|
||||
|
||||
Links:
|
||||
@ -137,12 +229,67 @@ Links:
|
||||
- https://pixelandpoly.com/ior.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
|
||||
- Visibility Buffer & Culling
|
||||
- BVH
|
||||
- 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
|
||||
|
||||
* LOD Selection
|
||||
* Generate the Command Buffer for Culled Mesh LODs from the Visible Leaf Buffer
|
||||
* Track counts using atomic buffers
|
||||
* To avoid double counting due to the structure of the Octree output, we have some options
|
||||
* Ignore Leaf Instances based on occurrences of the mesh in the surrounding 16 Octree Leaves. This would require
|
||||
a bias towards a specific corner of the filter.
|
||||
* Perform a preprocessing step on the CPU to erase duplicate elements and fix the buffer continuity.
|
||||
* Let the duplicates be rendered.
|
||||
* Generate the Culled Object Buffer by copying objects from the Object Buffer
|
||||
* Adjust Buffer Size using the counts
|
||||
* 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
|
||||
@ -156,40 +303,59 @@ This is the set of stages for the graphics pipeline that runs every frame:
|
||||
* G → Specularity (sometimes called metallicism)
|
||||
* B → Index of Refraction (IOR)
|
||||
|
||||
- Lighting Buffer - RGB16
|
||||
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
|
||||
* Materials with Forward Shading enabled.
|
||||
* Dual Depth Peeling
|
||||
|
||||
Debug View: Deferred and Forward Mask
|
||||
|
||||
- Post Processing
|
||||
- Depth of Field (Optional)
|
||||
- Bloom (Optional)
|
||||
- Depth of Field (Optional) → Poisson Sampling
|
||||
- Bloom (Optional) → Mipmap Blurring
|
||||
- Tonemapping (Optional)
|
||||
- HDR Correction
|
||||
|
||||
|
||||
|
||||
|
||||
## 3D Physics `(physics3d)`
|
||||
|
||||
Links:
|
||||
- https://www.researchgate.net/publication/264839743_Simulating_Ocean_Water
|
||||
- https://arxiv.org/pdf/2109.00104
|
||||
- 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
|
||||
* Newtonian Physics and Collision Resolution
|
||||
* Articulated Skeletal Systems
|
||||
* Inverse Kinematics
|
||||
* Stiff Rods
|
||||
- Particle Physics
|
||||
* Soft Body Physics
|
||||
* Elastics → Finite Element Simulation
|
||||
* Cloth → Position-Based Dynamics
|
||||
* Water
|
||||
* Oceans → iWave
|
||||
* Reasoning: iWave provides interactive lightweight fluid dynamics suitable for flat planes of water.
|
||||
* Reasoning: iWave provides interactive lightweight fluid dynamics suitable for flat planes of water. Simulat
|
||||
<br><br>
|
||||
|
||||
* 3D Fluid Dynamics → Smoothed-Particle Hydrodynamics
|
||||
@ -201,3 +367,25 @@ Systems
|
||||
* 2D Fluid Dynamics → Force-Based Dynamics
|
||||
* Reasoning: This model, like iWave, provides lightweight interactive fluid dynamics, but is more easily
|
||||
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.
|
||||
@ -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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user