-
Notifications
You must be signed in to change notification settings - Fork 41
Open
Labels
cat:performanceperformanceperformancecat:refactorrefactor/clean up/simplifications/etc.refactor/clean up/simplifications/etc.diff:advancedadvanced skills requiredadvanced skills requiredfeat:rendergraphrendergraphrendergraphfeat:renderingrenderingrendering
Description
Is your feature request related to a problem?
After rendergraph2 is finished, I initially wanted to implement a simple texture renderer. The best approach is to start with a material system for octrees now.
Description
Rendergraph is composed of different render modules. A simple renderer for octrees with textures could be introduced as a separate render module. The following questions come up now:
- The current render module design allows for an arbitrary number of pipelines, shaders, or passes per render module. If a render module should be separate instead of being part of another one (for example textured octree renderer should not be combined with colored triangles octree renderer), it is the responsibility of the programmer to account for the desired granularity of render modules!
- How to associate the
Cube
class with renderers? We could give each render module astd::weak_ptr<Cube>
to the cube that needs to be rendered. - The problem here is: Where to store the vertices and indices and the material data for the
Cube
class? - Keep in mind that an instance of
Cube
can represent different things (see Invent a consistent terminology #561) - How to separate materials from material instances? A material is composed of the data required to build the pipeline for it, so it is currently associated with render modules, meaning that each render module can have one or many material (=pipelines) it can create and render. Where should the data for that rendering be kept though? The data should not be in the
Cube
class and it should not be in the render module. Instead, the render module should have a vector of pointers to material instances (=the data required to render using a specific material). - Don't forget that each material also comes not only with its own shaders, but also
VkVertexInputAttributeDescription
andstd::vector<VkVertexInputBindingDescription>
. - During rendergraph compilation, the material instances and the instances of
Cube
associated with it are sorted into the correct render modules automatically.
Alternatives
Implementing a simple textured octree renderer which applies one texture with fixed texture coordinates to all vertices of a cube works too, but we need to think towards abstraction anyways. Doing it the simple way now only produces more work for us later.
Affected Code
Rendergraph and render modules code, also cube code
Operating System
All
Additional Context
None
Metadata
Metadata
Assignees
Labels
cat:performanceperformanceperformancecat:refactorrefactor/clean up/simplifications/etc.refactor/clean up/simplifications/etc.diff:advancedadvanced skills requiredadvanced skills requiredfeat:rendergraphrendergraphrendergraphfeat:renderingrenderingrendering
Type
Projects
Status
Todo
Milestone
Relationships
Development
Select code repository
Activity
IAmNotHanni commentedon May 23, 2025
So it breaks down to: