fennec-org/fennec
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- Created Layout for Textures

Browse Source 
- Separated Build and Output directories
This commit is contained in:
Medusa Slockbower
2025-06-14 22:17:46 -04:00
parent 885cca6ca7
commit 096e82f47a
11 changed files with 365 additions and 176 deletions
Download Patch File Download Diff File Expand all files Collapse all files

195
PLANNING.md
View File

@@ -4,20 +4,24 @@
## Table of Contents
1. [Introduction](#introduction)
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)
1. [Introduction](#introduction)
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. [Format Processing](#format-processing-fproc)
8. [Core](#core-core)
1. [Tick](#tick)
2. [Frame](#frame)
9. [Application Layer](#application-layer-app)
10. [Scene](#scene-scene)
11. [2D Graphics](#2d-graphics-gfx2d)
12. [3D Graphics](#3d-graphics-gfx3d)
1. [Structures](#structures-gfx3d)
2. [Stages](#stages-gfx3d)
13. [3D Physics](#3d-physics-physics3d)
14. [Artificial Intelligence](#artificial-intelligence-ai)
@@ -82,7 +86,7 @@ Implement headers related to memory allocation in C++.
## Containers (`containers`)
## Containers Library (`containers`)
All containers of the [C++ Standard Library](https://cppreference.com/w/cpp/container.html) should be implemented.
@@ -96,20 +100,18 @@ Here are essential data-structures not specified in the C++ stdlib:
## Language Processing (`proclang`)
Pronounced [pɹˈɒkh,læŋ](https://itinerarium.github.io/phoneme-synthesis/?w=pɹˈɒkh,læŋ)
## Format Processing (`fproc`)
No, this won't include Machine Learning, it will mostly include tools for processing human-readable files.
fennec should be able to use Doxygen and LaTeX externally. Consider including binaries with releases.
* String Analysis (`proclang/strings`)
* String Analysis (`fproc/strings`)
* Search
* Manipulation
* Delimiting
* Regex
- File Formats (`proclang/formats`)
- File Formats (`fproc/formats`)
- Serialization
- JSON
- HTML
@@ -135,7 +137,7 @@ fennec should be able to use Doxygen and LaTeX externally. Consider including bi
- FBX
**MAYBE**
* Compilation (`proclang/code`)
* Compilation (`fproc/code`)
* Lexical Analysis
* Syntax Analysis
* Semantic Analysis
@@ -212,7 +214,29 @@ implementations than I could write.
## 2D Graphics (`gfx2d`)
- BVH
- Quadtree
- 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
- Start Index 32-bits
- Object Count 32-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
- Generate the Command Buffer for Culled Meshes from the Visible Leaf Buffer
- Count Materials
- Count Meshes per Material
- Generate the Culled Object Buffer by copying objects from the Object Buffer
- Adjust Buffer Size using the counts
- Insert using another atomic buffer
@@ -235,7 +259,10 @@ If you would like to make a fork, have at it, but know that I will hold a deep d
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.
The buffers will be optimized by scene prediction.
This involves tracking the meshes and textures directly and indirectly used by a scene.
A callback function in the graphics system for scene loading can do this.
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.
@@ -243,13 +270,62 @@ This allows the GPU to draw every single deferred rendered mesh in a single draw
Specifications for debugging views via early breaks are included in the stages.
### Structures (`gfx3d`)
Object Structure. The mesh is implicit data.
```c++
struct Object
{
vec3 location, scale; // A matrix would be 64 bytes, this is instead 28 bytes
quat rotation;
int material;
}
```
Textures for 3D rendering are stored in various buffers with sizes of powers of 2.
Ratios of `1:1` and `2:1` are allowed. The `2:1` ratio is specifically for spherical and cylindrical projection.
UVs may be transformed to use a `2:1` as if it were `1:2`.
Cubemaps may only be `1:1`, I would be concerned if you are using any other ratio.
- 8-Bit R Texture `4096, 2048, 1024, 512` (8)
- 8-Bit RG Texture `4096, 2048, 1024, 512` (8)
- 8-Bit RGB Texture `4096, 2048, 1024, 512` (8)
- 8-Bit RGBA Texture `4096, 2048, 1024, 512` (8)
- 8-Bit RGB Cubemap `1024, 512, 256, 128` (4)
* 16-Bit HDR RGB Texture `4096, 2048, 1024, 512` (8)
* 16-Bit HDR RGBA Texture `4096, 2048, 1024, 512` (8)
* 16-Bit HDR RGB Cubemap `1024, 512, 256, 128` (4)
- 16-Bit Shadow Texture `4096, 2048, 1024, 512` (8)
- 16-Bit Shadow Cubemap `2048, 1024, 512, 256` (4)
Documentation should provide guidelines on categories of Art Assets and the resolution of textures to use.
Textures are identified by an 8-bit integer and 16-bit integer.
Artists should be informed on the texture structure of the engine and its limitations.
However, these principles should be followed in other game engines as these are
guided by what is most efficient for typical GPU hardware.
Materials are, for the most part, user-defined. Documentation should make the user aware of this.
Material buffers will be a sequence of the Material Struct instances.
They will at the very least contain the id of their shader.
### 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.
- BVH
- Octree
- Octree `(8 Bpn, 64 bpn) [6-Layers ≈ 2.1MB]`
- Leaf Size and Tree Depth should be calculated by the scene, constraints are as follows:
- Min Object Size
- Max Object Size
@@ -257,60 +333,61 @@ Unless otherwise specified, each stage will be run on the GPU.
- Scene Edge
- Insertions and Updates are done on the CPU
- Nodes
- ID 16-bits
- Start Index 32-bits
- Object Count 16-bits
- Object Count 32-bits
- Objects
- Buffer of Object IDs grouped by Octree Node
- Culling
- Leaf 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
- 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 construction of the Octree output, we have some options
- Ignore Leaf Instances based on occurrences of the mesh in the surrounding 8 Quadtree 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
- Buffer `(15 Bpp, 120 bpp) [1920x1080] ≈ 39.4MB`
- 24-Bit Depth Buffer
- RGB32I Visiblity Info
- R = Object ID
- G = Mesh ID
- B = Material 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
* G-Buffer Pass `(17 Bpp, 136 bpp) [1920x1080] ≈ 35.3MB`
* Depth - Stencil → D24_S8
* S → used to represent the lighting model.
* Diffuse → RGBA8
* A → Ambient Occlusion
* Emission → RGB8
* Normal → RGB8
* Specular → RGB8
* R → Roughness
* G → Specularity (sometimes called metallicism)
* G → Specularity (sometimes called the Metallicness)
* B → Index of Refraction (IOR)
Debug View: Depth, Stencil, Diffuse, Emission, Normal, Specularity
- Lighting Pass
- Deferred Lighting Pass `(10 Bpp, 80 bpp) [1920x1080] ≈ 2 x 16.3MB + 8.3MB ≈ 24.6MB`
- Depth Buffer → D24
- Lighting Buffer → RGB16 (w/ Mipmapping when Bloom or DoF are enabled)
- Stencil Buffer $rarr; S8
- Generate Dynamic Shadows
- Generate Dynamic Reflections (Optional)
- SSAO (Optional)
- Apply Lighting Model
- Output → RGB16
Debug View: Shadows, Reflections, SSAO, Deferred Lighting
@@ -320,11 +397,13 @@ Debug View: Shadows, Reflections, SSAO, Deferred Lighting
* Translucent Materials
* Dual Depth Peeling
Debug View: Deferred and Forward Mask
Debug View: Forward Mask
- Post Processing
- Depth of Field (Optional) → Poisson Sampling
- Bloom (Optional) → Mipmap Blurring
- Depth of Field (Optional)
- When enabled, the Visiblity Buffer, G-Buffer, and Deferred Lighting Pass will be double layered.
- At this point the Lighting Buffers will be Flattened
- Bloom (Optional) → Mipmap Blurring `(6Bpp, 48bpp) [1920x1080] ≈ 16.3MB`
- Tonemapping (Optional)
- HDR Correction
@@ -355,7 +434,7 @@ Systems
* Cloth → Position-Based Dynamics
* Water
* Oceans → iWave
* Reasoning: iWave provides interactive lightweight fluid dynamics suitable for flat planes of water. Simulat
* Reasoning: iWave provides interactive lightweight fluid dynamics suitable for flat planes of water.
<br><br>
* 3D Fluid Dynamics &rarr; Smoothed-Particle Hydrodynamics