I've been thinking, maybe a better way would be to cull stages/instructions of materials when used for shader 2.0, and actually manage that in the files? Different folders and duplicate names sounds like asking for trouble, unless they could be identified in this way, anyway. I get the impression this is already happening for the fancy stuff, the game will still work with shader 3.0 (64+ instructions) in the highMaterial files with shader 2.0 settings, so everything still works but not able to compile the cache (still allowing a partial compile) because it seems the engine already accounts for its (non-)compatibility and simply doesn't try to use it. That's stuff like "halfLambert" and other new stuff showcased in the Village Demo.
When it comes to other stuff like "diffuse*Map" with scaling, which layers of really eats up instructions, cubemap reflections, specularity, etc, understandably there's no way to know how to turn it off for shader 2.0 compatibility, because it's all so standard, just used in combinations that are too much work for shader 2.0. On top of that, there's no way to automatically know which features will change the visuals of the material in unwanted ways. Maybe the cubemap reflection is subtle and can be disregarded, or maybe it's prominent and vital to the appearance of the surface, far more than detail-mapping at "diffuse2Map". There's no way for code to automatically know this.
So I'd like to suggest a way to manage this within the highMaterial files themselves, so that they know what standard things to cull for shader 2.0 compatibility. It could very well be just 1 option and save a lot of instructions, so for example:-
- Code: Select all Expand view
highLevelMaterial "cc1/apartmentdoor"
{
template = ShaderBaseMaterial
shader2cull = reflection <--- new code
receiveSimpleShadows = True
reflectionColor = 1 1 1
reflectionSpecificCubemap = "Types\\Base\\SkyBox\\env_water1.jpg"
specularColor = 1 1 1
specularPower = 1
specularShininess = 512
...
becomes like the equivalent of (for shader 2.0):-
- Code: Select all Expand view
highLevelMaterial "cc1/apartmentdoor"
{
template = ShaderBaseMaterial
shader2cull = reflection
receiveSimpleShadows = True
// reflectionColor = 1 1 1
// reflectionPower = 1
// reflectionSpecificCubemap = "Types\\Base\\SkyBox\\env_water1.jpg"
specularColor = 1 1 1
specularPower = 1
specularShininess = 512
...
shader2cull = reflection / specular / emission / diffuse2map / diffuse3map / diffuse4map...
Only these, mainly, because it's surprising what eats up instructions and what does not.
That's the simple version of the idea, I guess. Perhaps Incin's folder idea is better because when we get right into complicated effects, it's the only true way to go to make things as visually correct as possible, but I fear it may increase loading times too much, which is important to avoid. Having more control inside the actual one set of highMaterial files themselves shouldn't harm loading times and like I said, 99% of the time it really could be that simple.
