- Started interface for renderers
- Renamed fproc -> langproc (I'll probably never settle on a naming convention for this) - Refactored set to use median psl
This commit is contained in:
134
PLANNING.md
134
PLANNING.md
@@ -12,7 +12,7 @@
|
||||
4. [Math Library](#math-library-math)
|
||||
5. [Memory Library](#memory-library-memory)
|
||||
6. [Containers Library](#containers-library-containers)
|
||||
7. [Format Processing](#format-processing-fproc)
|
||||
7. [Format Processing](#format-processing-langproc)
|
||||
8. [Core](#core-core)
|
||||
1. [Tick](#tick)
|
||||
2. [Frame](#frame)
|
||||
@@ -143,7 +143,7 @@ trivially cracked locally, you can scrape most assets from the GPU and Audio Car
|
||||
|
||||
I have managed to solve the specific case provided at the top of this section, which was done by wrapping C I/O calls
|
||||
into a file wrapper. This wrapper can handle a few different mode flags and has specific conditions for the flags. See
|
||||
the documentation for `fennec/fproc/io/file.h` for more info.
|
||||
the documentation for `fennec/langproc/io/file.h` for more info.
|
||||
|
||||
One question remains unanswered on this front; should a read/write file open as `r+` or `a+`. `rewind` is slightly faster
|
||||
than `fseek(SEEK_END)`, however for the case of save files and editor assets, `r+` makes more sense from a usage perspective
|
||||
@@ -247,7 +247,7 @@ Here are essential data-structures not specified in the C++ stdlib:
|
||||
|
||||
|
||||
|
||||
## Format Processing (`fproc`)
|
||||
## Language Processing (`langproc`)
|
||||
|
||||
This library contains information for any data that is formatted. This includes basic string formats, file formats,
|
||||
and eventually programming languages
|
||||
@@ -256,13 +256,13 @@ fennec should be able to use Doxygen and LaTeX externally. Consider including bi
|
||||
|
||||
### Notes
|
||||
|
||||
* String Analysis (`fproc/strings`)
|
||||
* String Analysis (`langproc/strings`)
|
||||
* Search
|
||||
* Manipulation
|
||||
* Delimiting
|
||||
* Regex
|
||||
|
||||
- File Formats (`fproc/formats`)
|
||||
- File Formats (`langproc/formats`)
|
||||
- Serialization
|
||||
- JSON
|
||||
- HTML
|
||||
@@ -293,9 +293,68 @@ fennec should be able to use Doxygen and LaTeX externally. Consider including bi
|
||||
- OTF
|
||||
- SVG
|
||||
- TTF
|
||||
- Models
|
||||
- Models
|
||||
unfortunately, most formats are esoteric due to copyright/trademark/etc. I will be using assimp for the
|
||||
time being, below is a list of formats supported by assimp.
|
||||
- 3D
|
||||
- 3DS
|
||||
- 3MF
|
||||
- AC
|
||||
- AC3D
|
||||
- ACC
|
||||
- AMJ
|
||||
- ASE
|
||||
- ASK
|
||||
- B3D
|
||||
- BVH
|
||||
- CSM
|
||||
- COB
|
||||
- DAE/Collada
|
||||
- DXF
|
||||
- ENFF
|
||||
- FBX
|
||||
- Wavefront OBJ
|
||||
- glTF 1.0 + GLB
|
||||
- glTF 2.0
|
||||
- HMB
|
||||
- IFC-STEP
|
||||
- IQM
|
||||
- IRR / IRRMESH
|
||||
- LWO
|
||||
- LWS
|
||||
- LXO
|
||||
- M3D
|
||||
- MD2
|
||||
- MD3
|
||||
- MD5
|
||||
- MDC
|
||||
- MDL
|
||||
- MESH / MESH.XML
|
||||
- MOT
|
||||
- MS3D
|
||||
- NDO
|
||||
- NFF
|
||||
- OBJ
|
||||
- OFF
|
||||
- OGEX
|
||||
- PLY
|
||||
- PMX
|
||||
- PRJ
|
||||
- Q3O
|
||||
- Q3S
|
||||
- RAW
|
||||
- SCN
|
||||
- SIB
|
||||
- SMD
|
||||
- STP
|
||||
- STL
|
||||
- TER
|
||||
- UC
|
||||
- USD
|
||||
- VTA
|
||||
- X
|
||||
- X3D
|
||||
- XGL
|
||||
- ZGL
|
||||
- Video Formats
|
||||
- MP4
|
||||
- AVI
|
||||
@@ -303,7 +362,7 @@ fennec should be able to use Doxygen and LaTeX externally. Consider including bi
|
||||
- MOV
|
||||
|
||||
**TODO LATER**
|
||||
* Compilation (`fproc/code`)
|
||||
* Compilation (`langproc/code`)
|
||||
* Lexical Analysis
|
||||
* Syntax Analysis
|
||||
* Semantic Analysis
|
||||
@@ -482,33 +541,41 @@ struct Object
|
||||
{
|
||||
vec3 location, scale; // A matrix would be 64 bytes, this is instead 28 bytes
|
||||
quat rotation;
|
||||
int material;
|
||||
uint32 material, lighting;
|
||||
}
|
||||
```
|
||||
|
||||
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.
|
||||
Cubemaps and 3D textures 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 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)
|
||||
- 8-Bit R Cubemap `1024, 512, 256, 128` (4)
|
||||
- 8-Bit RGB Cubemap `1024, 512, 256, 128` (4)
|
||||
|
||||
* 16-Bit HDR RGB Texture `4096, 2048, 1024, 512` (8)
|
||||
* 16-Bit HDR R Texture `4096, 2048, 1024, 512` (8)
|
||||
* 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 HDR R Cubemap `1024, 512, 256, 128` (4)
|
||||
* 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)
|
||||
|
||||
* 8-Bit 3D R Texture `256, 128, 64, 32` (4)
|
||||
* 8-Bit 3D RGB Texture `256, 128, 64, 32` (4)
|
||||
* 16-Bit 3D HDR R Texture `256, 128, 64, 32` (4)
|
||||
* 16-Bit 3D HDR RGB Texture `256, 128, 64, 32` (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.
|
||||
- `int8` → the texture buffer
|
||||
- `int16` → the layer in the buffer
|
||||
Textures are identified by a 32-bit integer.
|
||||
- `8 bits` → the texture buffer
|
||||
- `24 bits` → the layer in the buffer
|
||||
|
||||
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
|
||||
@@ -519,6 +586,14 @@ Materials are, for the most part, user-defined. Documentation should make the us
|
||||
Material buffers will be a sequence of the Material Struct instances.
|
||||
They will at the very least contain the id of their shader.
|
||||
|
||||
Types of materials:
|
||||
- Surface (Vertex & Fragment)
|
||||
- Opaque / Masked
|
||||
- Translucent (Forward)
|
||||
- Volume (Path Traced Volumetrics / Forward)
|
||||
- Light (Lighting Model)
|
||||
- Post-Process
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -585,17 +660,28 @@ Debug View: Visibility Buffer
|
||||
|
||||
Debug View: Depth, Stencil, Diffuse, Emission, Normal, Specularity
|
||||
|
||||
- Generate Dynamic Shadows
|
||||
- Generate Dynamic Reflections (Optional)
|
||||
- SSAO (Optional)
|
||||
- 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)
|
||||
- Lighting Buffer → `RGB16` w/ Mipmapping
|
||||
- Stencil Buffer $rarr; `S8`
|
||||
- Generate Dynamic Shadows
|
||||
- Generate Dynamic Reflections (Optional)
|
||||
- SSAO (Optional)
|
||||
- Apply Lighting Model
|
||||
|
||||
|
||||
Debug View: Shadows, Reflections, SSAO, Deferred Lighting
|
||||
|
||||
We can combine all of these into one framebuffer:
|
||||
|
||||
- Depth - Stencil → `D24_S8`
|
||||
- Visibility Info → `RGB32I`
|
||||
- Diffuse → `RGBA8`
|
||||
- Emission → `RGB8`
|
||||
- Normal → `RGB8`
|
||||
- Specular → `RGB8`
|
||||
- Lighting Buffer → `RGB16` w/ Mipmapping
|
||||
- One more slot left open for another
|
||||
|
||||
* Forward Pass
|
||||
* BVH, Same as Above
|
||||
* LOD Selection, Same as Above
|
||||
|
||||
Reference in New Issue
Block a user