Optionally expose water state to post-processing shader
Currently, water post-processing shaders have the drawback that they need to use the normals, but not the colors, from the built-in water shader. This means that the water shader has to be manually modified, and that the post-processing shaders are subject to normal map encoding imprecision, any bugs the engine has regarding normal mapping, and just generally have the built-in water shader do a ton of work just to throw it out. Water post-processing shaders could, instead, do everything in post, including normals calculation, but there are certain things that are not exposed to post-processing shaders that make this impossible:
- they don't have enough information about weather (the behavior/meaning of each weather id is opaque to the shader); to contrast, the built-in water shader is given uniforms for rain strength etc. some, but not all, aspects of the weather are exposed directly, like sun visibility. fleshing out the array of things that are exposed directly would be very helpful. alternatively, functions for 'interpreting' a given weather id could serve the same function, like
omw_GetWeatherRainStrength(int weatherID)
or something, but that would be less flexible. - they don't have access to the information necessary to use the new actor motion ripples
- same for rain occlusion (though this is an issue with built-in water atm too; see #7157)
The first issue could be handled with lua scripts or by writing morrowind-specific helper functions into the shader (not ideal because post-processing shaders should be maximally game-agnostic). The second requires explicit engine support; exposing it to all post-processing shaders would probably be expensive, so it should be optional. Third is an ongoing "we'll get there eventually" with the same 'probably expensive' caveat.