mslockbo/fennec
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
fennec/PLANNING.md

11 KiB
Raw Blame History

Planning Documentation for fennec

Table of Contents

  1. Introduction
  2. TODO
  3. C++ Language
  4. Math Library
  5. Memory Library
  6. Containers Library
  7. Language Processing
  8. Core
    1. Tick
    2. Frame
  9. Scene
  10. 3D Graphics
  11. 3D Physics
  12. Artificial Intelligence

Introduction

This file serves as a general planning document for engine structure, systems, pipelines, and implementation.

Implementations of core engine systems should strive to be O(1) in implementations, both in terms of runtime and memory performance. This is obviously not a realistic goal, so rather than the entire engine striving to be O(1) we should more specifically look at achieving O(1) performance on hot paths.

Functions should be highly verbose, and in debug mode any bugprone or erroneous behaviour should throw assertions. DO NOT USE EXCEPTIONS.

System implementations should be independent of architecture or platforms. i.e. the code of the graphics system should 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. A full implementation should be worked on continuously.

Math Library (math)

Implement math functions according to the OpenGL 4.6 Shading Language Specification.

Additional extensions should be implemented to provide standard definitions for functions predominantly related to Linear Algebra, Mathematical Analysis, and Discrete Analysis. Additional extensions will be implemented on a as-needed basis.

Memory Library (memory)

Implement headers related to memory allocation in C++.

  • Smart Pointers
  • Memory Allocation

Containers (containers)

All containers of the C++ Standard Library 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æŋ

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)
    • Search
    • Manipulation
    • Delimiting
    • Regex
  • File Formats (proclang/formats)
    • Serialization
      • JSON
      • HTML
      • XML
      • YAML
    • Configuration
      • INI
      • TOML
    • Documents
      • ODF
      • Markdown
      • PDF
    • Spreadsheets & Tables
      • ODS
      • CSV
    • Graphics Formats
      • BMP
      • JPG
      • PNG
      • TIFF
      • DDS
      • Wavefront OBJ
      • FBX

MAYBE

  • Compilation (proclang/code)
    • Lexical Analysis
    • Syntax Analysis
    • Semantic Analysis
    • Intermediate Code Generation
    • Optimization
    • Target Code Generation

Core (core)

This will be the core of the engine.

  • Event System
  • Core Engine Loop
    • System Manager
    • Ticks vs. Frames

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
    • Newtonian Commit
      • Apply Forces (Updates Acceleration and Torque)
      • Apply Torque & Acceleration (Updates Velocities)
      • Apply Velocities (Updates Position and Rotation)
    • Constraint Resolution
    • Collision Detection
    • Collision Resolution (Adjust for Clipping)
      • Soft Bodies resolve before Rigid Bodies
    • Collision Response
      • Calculate Forces

Frame

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.
  • Bounding Volume Hierarchy
    • Octree

2D Graphics (gfx2d)

3D Graphics (gfx3d)

Links:

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.

  • 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
      • 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

3D Physics (physics3d)

Links:

Systems

  • 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. Simulat

      • 3D Fluid Dynamics → Smoothed-Particle Hydrodynamics

        • 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 a glass.

      • 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.