From b37b5398a6afa940acd1138bde922a70838f33af Mon Sep 17 00:00:00 2001 From: 3gg <3gg@shellblade.net> Date: Fri, 4 Jul 2025 10:37:01 -0700 Subject: Add the new low-level renderer, shared between the imm and scene graph renderer. LLR integration with the scene graph renderer not yet done. --- README.md | 44 ++++++++++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 18 deletions(-) (limited to 'README.md') diff --git a/README.md b/README.md index f0b103d..491761d 100644 --- a/README.md +++ b/README.md @@ -20,32 +20,35 @@ educational purposes. ### Gfx The `Gfx` object represents the graphics subsystem and is at the center of the -library's high-level API. The `Gfx` object exposes a `Render` backend and a -`Renderer` and allows the caller to create `Scene`s. +library's high-level API. The `Gfx` object exposes a render backend (`GfxCore`) +and a `Renderer`, and allows the caller to create `Scene`s. ### Render Backend -The `Render` backend is a thin abstraction layer over low-level graphics APIs -like OpenGL or Vulkan. It holds GPU resources such as geometry, textures, -shaders, etc, and exposes functions to manipulate them. +The render backend (`GfxCore`) is a thin abstraction layer over low-level +graphics APIs like OpenGL or Vulkan. It holds GPU resources such as geometry, +textures, shaders, etc, and exposes functions to manipulate them. -Currently there is only one implementation of the `Render` backend based on +Currently, there is only one implementation of the render backend based on OpenGL. #### Ownership -The `Render` backend owns all rendering resources: buffers, geometries, -textures, shaders, etc. Even resources that point to other resources do not own -those other resources (geometries pointing to buffers). +The render backend owns all rendering resources: buffers, geometries, textures, +shaders, etc. Even resources that point to other resources do not own those +other resources (geometries pointing to buffers). -There is no ownership tracking in the render backend. It is up to the client to +There is no lifetime tracking in the render backend. It is up to the client to manage resource lifetime. +### Low-level Renderer + +`ImmRenderer` is a low-level, immediate mode renderer. + ### Scene -A `Scene` encapsulates a scene graph. A scene graph contains the elements that -make up a scene: nodes, cameras, lights, objects, etc. The current scene graph -implementation includes: +A `Scene` graph contains the elements that make up a scene. The current scene +graph implementation includes: - Camera - Light @@ -64,7 +67,8 @@ functions to set the parent node of an object/camera/light. If we exposed the former, the API could create the illusion that the hierarchy can be a DAG. The strict tree hierarchy should not be that restrictive in practice. Even the -glTF 2.0 spec [enforces this](https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#nodes-and-hierarchy): +glTF 2.0 +spec [enforces this](https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#nodes-and-hierarchy): > *For Version 2.0 conformance, the glTF node hierarchy is not a directed > acyclic graph (DAG) or scene graph, but a disjoint union of strict trees. That @@ -76,9 +80,9 @@ glTF 2.0 spec [enforces this](https://github.com/KhronosGroup/glTF/blob/master/s Two use cases for instancing seem to be: 1. Creating N identical clones, but each with a unique transform. (Ex: N -animated characters animated in unison but located in different locations.) + animated characters animated in unison but located in different locations.) 2. Creating N copies of a sub-tree, each now being their own unique tree. (Ex: -The same N animated characters, but each of them now being animated separately.) + The same N animated characters, but each of them now being animated separately.) Some scene graphs ([Panda3D](https://docs.panda3d.org/1.10/python/programming/scene-graph/instancing)) @@ -87,10 +91,10 @@ to have multiple parents. This turns the scene graph into a DAG and adds a number of complications for us: 1. Shared ownership of children. We would now need some sort of ref counting or -deferred GC to delete nodes and their subtrees. + deferred GC to delete nodes and their subtrees. 2. Nodes no longer have a unique parent. 3. Given a node, we can no longer determine its location (which parent link do -you follow?), or any attribute that is derived from its parent(s). + you follow?), or any attribute that is derived from its parent(s). In our case, we stick to strict tree hierarchies. @@ -131,6 +135,10 @@ Code under `util/` provides functionality that need not be in the core part of the library (Gfx, render backend, scene or renderer). This includes functions to compute irradiance maps, create procedural geometry, etc. +### Memory management + +TODO + ## Ideas for Future Work - Render graphs to allow for custom multi-pass rendering algorithms. -- cgit v1.2.3