What would this enhancement be for?
Rendering
Describe your enhancement suggestion in more detail
Shaders, especially the more complex ones like PBR, make use of the color channels of textures to optimize the overall amount of textures specified for a material. However, a lot of this color channel specification is very hardcoded, and as such, requires specific combinations of texture channels when materials are made.
This enhancement suggests a large refactoring of this system, allow material creators to manually specify the color channels that are used for texture data. This would allow optimization for textures on the user end and a plethora of new texture combinations that would've been otherwise locked behind shader technicalities.
An immediate example of this being useful would be cutting down on the amount of textures for the PBR shader. A lot of materials for the shader don't typically make use of the tint mask or metallic channels in the MRAO texture, and a significant optimization could be made if there was a way to manually tell the shader to use the alpha channels of the bumpmap and basetexture to store the ambient occlusion and roughness maps (effectively cutting the mrao texture out entirely for a lot of materials).
The way this could be done in the vmt could be similar to how individual rgb channels are specified in proxies for stuff like $color. The individual greyscale textures that are usually specified for a shader, such as the roughness texture for PBR, could have "texturename[1]" which would tell the material that the roughness texture is stored from a texture's green channel. So a material using this feature would look like this:
VertexLitGeneric
{
//This material only uses three textures on the disc,
//but manually references the channels of all three for texture data
$basetexture "base/texture/directory"
$bumpmap "bump/map/directory"
$envmapmask "base/texture/directory[3]"
$selfillummask "bump/map/directory[3]"
$phongexponenttexture "misc/texture/directory[0]"
$phongmask "misc/texture/directory[0]"
$tintmasktexture "misc/texture/directory[2]"
$rimmask "misc/texture/directory[1]"
}
The channels of a lot of shaders would have to be exposed for this change, but I think it would be a meaningful change to do that regardless. To address the limits to the total amount of textures that a shader can reference, a warning in the console and a material that doesn't draw could be done to indicate the limit has been exceeded.
Additionally, there could also be the possibility of inverting the read channels with a symbol (maybe '-' ?) before the number, which would allow a possibility for something like a detail mask reading from an inverted version of the ambient occlusion texture without needing a separate texture mask.
What would this enhancement be for?
Rendering
Describe your enhancement suggestion in more detail
Shaders, especially the more complex ones like PBR, make use of the color channels of textures to optimize the overall amount of textures specified for a material. However, a lot of this color channel specification is very hardcoded, and as such, requires specific combinations of texture channels when materials are made.
This enhancement suggests a large refactoring of this system, allow material creators to manually specify the color channels that are used for texture data. This would allow optimization for textures on the user end and a plethora of new texture combinations that would've been otherwise locked behind shader technicalities.
An immediate example of this being useful would be cutting down on the amount of textures for the PBR shader. A lot of materials for the shader don't typically make use of the tint mask or metallic channels in the MRAO texture, and a significant optimization could be made if there was a way to manually tell the shader to use the alpha channels of the bumpmap and basetexture to store the ambient occlusion and roughness maps (effectively cutting the mrao texture out entirely for a lot of materials).
The way this could be done in the vmt could be similar to how individual rgb channels are specified in proxies for stuff like
$color. The individual greyscale textures that are usually specified for a shader, such as the roughness texture for PBR, could have"texturename[1]"which would tell the material that the roughness texture is stored from a texture's green channel. So a material using this feature would look like this:The channels of a lot of shaders would have to be exposed for this change, but I think it would be a meaningful change to do that regardless. To address the limits to the total amount of textures that a shader can reference, a warning in the console and a material that doesn't draw could be done to indicate the limit has been exceeded.
Additionally, there could also be the possibility of inverting the read channels with a symbol (maybe '-' ?) before the number, which would allow a possibility for something like a detail mask reading from an inverted version of the ambient occlusion texture without needing a separate texture mask.