Enhancement: Better Env_Cubemap assignment process in the compiler.

[November-N]

What would this enhancement be for?

Other

Describe your enhancement suggestion in more detail

(Brush) Materials using env_cubemap as a environment map source are reassigned a new material in the compile process, pointing to a specific cubemap entity. This can cause a number of issues, for example material_modify_control will not work with any cubemapped material (Yeah there are workarounds but it's inconvenient at best of times). Another example could be for custom asset overrides, compiled cubemapped materials are named differently to their sources and you cannot modify the source to change any of the duplicates, meaning a major hit to the power of asset overrides.

This issue might be able to be solved by something like the patch shader, have the compiler put the original material in a include bracket and inserts the name of the cubemap. Maybe after it has been compiled the user can remove the original $envmap parameter and it will also stop using the cubemap in the game.

Going a bit crazy now, but it would also be cool to be able to override them in maps that have been compiled for other source versions, maybe an autodetect that can find the initial material's name by removing the postfix, then reading that and copying that over the material in the map (with the exception of the $envmap parameter in the new material of course).

[TeamSpen210]

VBSP already uses a patch shader for the new material it makes - really the problem there is that the MaterialModify proxy doesn’t have special casing for this situation.