We have material.lod and the "lodx" naming convention for shader techniques. The problem is, i can't make use of either one.
In Shade-C i'm using deferred shading, which requires the generation of a gBuffer which holds all relevant data (depth, normals, albedo, material data, etc). To do that, every object in the scene needs a special shader which renders the gBuffer data to MRTs.
To make things easier for the user, i created an ubershader, which you can:
a) fit to your needs by defining properties in the shader header
b) extend/change by using given hooks (custom position, custom normals, etc) without changing the actual ubershader
Very basic example of how such a shader looks
//------------------------------------------------------------------------------
//----- Basic Properties -------------------------------------------------------------
//------------------------------------------------------------------------------
//assign skins
#define SKIN_ALBEDO (skin1.xyz) //diffusemap
#define SKIN_ALPHA (skin1.w) //alpha
#define SKIN_NORMAL (skin2.xyz) //normalmap
#define SKIN_GLOSS (skin2.w) //glossmap
//...
#define NORMALMAPPING //do normalmapping?
#define GLOSSMAP //entity has glossmap?
#define GLOSSSTRENGTH 0 //glossmap channel will be set to this value if GLOSSMAP is not defined
//------------------------------------------------------------------------------
// Custom Extensions
//------------------------------------------------------------------------------
#include <scHeaderObject>
#define CUSTOM_VS_TEX
#ifndef VECTIME
#define VECTIME
float4 vecTime;
#endif
#ifndef VECSKILL1
#define VECSKILL1
float4 vecSkill1;
#endif
float2 Custom_VS_Tex(vsIn In)
{
return In.Tex.xy + vecTime.w*vecSkill1.xy*0.001;
}
#include <scObject>
Using the "lod" naming convention for techniques currently won't work. I'd have to create 3 additional ubershaders in the same file, then change the parameters to something like
#define NORMALMAPPING_LOD0 //activate normalmapping on lod0
#define NORMALMAPPING_LOD1 //activate normalmapping on lod1
etc.
to make it work. Depending on how complex the lod0 shader gets (= how much features the users activates) things will get really messy and hard to read. And it's useability that i'm after. Otherwise i could scrap the whole "build your own shader from #defines" thing and just force the user to write his own shader from scratch. Shade-C is meant to be a tool for shader newbies and pros alike. Those who do know how to write shaders, can do so and extend the given shaders. Those who have no clue about shaders, should still be able to build shaders which fit their needs.
The material.lod parameter also won't work, as a default Acknex shader will be used when the lod kicks in, thus no gBuffer data will be written. I could attach a basic gBuffer shader to mtl_flat, mtl_shaded, etc. to write out basic gBuffer data once the lod kicks in, but what if the user created an emissive shader and applies it to an object where 90% will be emissive. It would look really odd once the lod shader gets activated and an almost full emissive object goes full diffuse.
The Material Lod i have in mind could look like this:
- Create a material
- optionally set its lod1, lod2, lod3 material
MATERIAL* myMaterial_lod3 =
{
...
}
MATERIAL* myMaterial_lod2 =
{
...
}
MATERIAL* myMaterial_lod1 =
{
...
}
MATERIAL* myMaterial =
{
...
lod1 = myMaterial_lod1;
lod2 = myMaterial_lod2;
lod3 = myMaterial_lod3;
}
Or use a naming convention. myMaterial is the master material and materials with the same name but the ending _lod1, _lod2, _lod3 are the master material's lod materials.
Third option could be some sort of link between materials:
MATERIAL* myMaterial_lod3 =
{
...
}
MATERIAL* myMaterial_lod2 =
{
...
lod = myMaterial_lod3;
}
MATERIAL* myMaterial_lod1 =
{
...
lod = myMaterial_lod2;
}
MATERIAL* myMaterial =
{
...
lod = myMaterial_lod1;
}
I have no idea how hard it would be to implement something like this. But implementing one of the mentioned three options would really help me improve Shade-C's performance
Please note that i'm only using the above object ubershader as reference. There are other cases where such a material lod system would be really helpful like rendering dynamic lights: Near lights have specular and shadows activated, middle range lights have specular activated and far lights only do diffuse lighting. Currently, lights also use #defines and one light-ubershader, which makes the use of lod techniques impossible.
If all this is already possible, i'm sorry. I've looked through the manual and searched the forums but could not find a satisfacting solution.
