You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow individual brush faces to be assigned a tint color, similar to what is already possible with model based ents using rendercolor.
Below is a rough outline for the suggested implementation:
UI changes in Face Edit Sheet
Add a new entry field for the color and a color picker attached to it
Add a button inside the Replace Textures sub-menu to change the color on all brush faces that share that same color
For the above, add an option to limit the color replacement to faces with the same material or set of materials, as opposed to all brushes with the same color
General
The color information could be stored in the vmf, like the UV information is, for example, During map compilation, VBSP could handle tinted brush faces like it handles env_cubemap materials. It would create a copy of the material for each tinted face, apply the final color to it, and save these new VMTs directly into the BSP file. Naturally, faces with identical tint and material would share the same VMT.
With a system like this in place mappers can quickly experiment with different color schemes for entire chunks of their levels without needing to create and assign new materials for every variation. This would also reduce the size of the required material library.
This should also have an added benefit of encouraging artists to actually use the tint system more, since they will not need to leave the editor and meddle with the materials on disk on an individual basis.
Non-essential features
Potentially, if the target material's shader supports tint mask as a separate texture input, instead of being channel packed, an additional UI option could be added which would allow to pick a custom tint mask for the specific faces from the existing vtf library. This could be implemented in the UI as a button which opens a texture browser from the Face Edit Sheet menu.
In general, there are at least a few other cases where such editor based functionality could be useful, like being able to set texture lights on a per-face basis. I will describe them in separate issues.
The text was updated successfully, but these errors were encountered:
Which component should be improved?
Hammer
Describe your feature suggestion in more detail
Allow individual brush faces to be assigned a tint color, similar to what is already possible with model based ents using rendercolor.
Below is a rough outline for the suggested implementation:
UI changes in Face Edit Sheet
General
The color information could be stored in the vmf, like the UV information is, for example, During map compilation, VBSP could handle tinted brush faces like it handles env_cubemap materials. It would create a copy of the material for each tinted face, apply the final color to it, and save these new VMTs directly into the BSP file. Naturally, faces with identical tint and material would share the same VMT.
With a system like this in place mappers can quickly experiment with different color schemes for entire chunks of their levels without needing to create and assign new materials for every variation. This would also reduce the size of the required material library.
This should also have an added benefit of encouraging artists to actually use the tint system more, since they will not need to leave the editor and meddle with the materials on disk on an individual basis.
Non-essential features
Potentially, if the target material's shader supports tint mask as a separate texture input, instead of being channel packed, an additional UI option could be added which would allow to pick a custom tint mask for the specific faces from the existing vtf library. This could be implemented in the UI as a button which opens a texture browser from the Face Edit Sheet menu.
In general, there are at least a few other cases where such editor based functionality could be useful, like being able to set texture lights on a per-face basis. I will describe them in separate issues.
The text was updated successfully, but these errors were encountered: