This system needs more refinement but I'm so exhausted. Merging now as basic functionalities are working.
Initial backlog
Currently all material shader variations are hard-coded.
I can't make a full GUI-based material editor now, but at least let's make a material assembler that generates material shaders.
Material shaders only define specialized things - vertex position offset, texture input, Gbuffer attributes, so on. Common code is provided by a material template.
The assembler generates final material shaders, replacing various parts of a material template with a given concrete material.
Complete rework of material shader management
Previous implementation defined a hard-coded base pass shader, a subclass of Material, and a corresponding render pass class.
For example, for a material that samples PBR textures:
Vertex shader deferred_pack_pbr_texture_vs.glsl
Fragment shader deferred_pack_pbr_texture_fs.glsl
class PBRTextureMaterial : public Material { ... };
class Deferred_Pack_PBR_Texture : public Deferred_Pack_Base { ... };
These things were defined for each material type, and I also had to add ad-hoc logic for depth prepass and shadowmap pass if a material has non-trivial depth only shader (that is, final position is not just MVP * localPosition, due to vertex animation or manual control of gl_FragDepth, etc.).
Everything above is now gone. No separate VS/FS shaders, no subclasses, no separate render pass classes.
Now there is a material template that acts as a kind of uber shader. It supports both deferred shading and forward shading pipeline.
Material files provide minimal definitions to fill placeholders in the template, including shading model, uniforms, input textures, gbuffer output, and vertex position offset. At startup the engine reads material files and generate MaterialShaders.
When instantiating a Material, it is related to a MaterialShader. Material clones uniform and texture parameters info from its MaterialShader.
If multiple Materials are created from the same MaterialShader, they have different instance IDs. Even if two Materials have the same MaterialShader, they can have their own parameters.
In rendering pipeline, mesh batches are split into an opaque mesh list and a translucent mesh list. Each list is first sorted by material shader, then by material instance ID. The opaque list is rendered in depth prepass and base pass. The translucent one is rendered in translucency pass.
TODO
Detect which input elements and texture units are necessary in more smart way.
Cleanup parsing logic in material_shader_assembler.cpp. It's quite dirty.
This system needs more refinement but I'm so exhausted. Merging now as basic functionalities are working.
Initial backlog
Currently all material shader variations are hard-coded.
I can't make a full GUI-based material editor now, but at least let's make a material assembler that generates material shaders.
Material shaders only define specialized things - vertex position offset, texture input, Gbuffer attributes, so on. Common code is provided by a material template.
The assembler generates final material shaders, replacing various parts of a material template with a given concrete material.
Complete rework of material shader management
Previous implementation defined a hard-coded base pass shader, a subclass of
Material, and a corresponding render pass class.For example, for a material that samples PBR textures:
deferred_pack_pbr_texture_vs.glsldeferred_pack_pbr_texture_fs.glslclass PBRTextureMaterial : public Material { ... };class Deferred_Pack_PBR_Texture : public Deferred_Pack_Base { ... };These things were defined for each material type, and I also had to add ad-hoc logic for depth prepass and shadowmap pass if a material has non-trivial depth only shader (that is, final position is not just MVP * localPosition, due to vertex animation or manual control of gl_FragDepth, etc.).
Everything above is now gone. No separate VS/FS shaders, no subclasses, no separate render pass classes.
MaterialShaders.Material, it is related to aMaterialShader.Materialclones uniform and texture parameters info from itsMaterialShader.Materials are created from the sameMaterialShader, they have different instance IDs. Even if twoMaterials have the sameMaterialShader, they can have their own parameters.In rendering pipeline, mesh batches are split into an opaque mesh list and a translucent mesh list. Each list is first sorted by material shader, then by material instance ID. The opaque list is rendered in depth prepass and base pass. The translucent one is rendered in translucency pass.
TODO