Feature/fog colour

[huwb]

Status: Experimental / feedback PR

We currently set the fog via raw density values and its hard to tweak. A better approach for this is to provide a colour parameter which gives the fog colour at 5m distance, and then do a calculation to compute the density values. The colour alpha channel scales the overall density.

While it has its own quirks, its much easier to explorer looks by tweaking fog colour HSV rather than raw density values.

Biggest question is what to do with the existing density param. This PR removes it so people will lose their fog values and may need to retweak. An alternative i thought of was to set the fog colour black by default, and then only drive the density values from C# if the colour was non black. I did this in teh previous commit but ended up reverting it now as it feels a bit elaborate and potentially confusing (the user would be given fog density values that do nothing unless the fog colour is black). A third option would be to have an opt in tickbox for tweaking via fog colour. This is probably the softest route i guess..

[daleeidd]

Any breaking changes can always be introduced in Crest 5.0. So we could use an opt-in for now and remove it later?

Another option could be that if the new fog colour is not set, then report what value the new fog colour should be based on the fog density value stored on the material?

[huwb]

i wish to add a local shader keyword to enable/disable it...

i am determined to make local shader keywords work for us. unfortunately, they do not. i tried on 2020 and when i add more than a few keywords, i start getting mysterious null reference exceptions. i upped the shader variation limit in the perferences and verified this fixes the exceptions. "d'oh".

in 2019 i also get null ref exceptions which were probably due to the same thing (so i guess i just need to set the limit to something high for development - at the risk of it hiding issues that users will encounter if their limit is lower).

[daleeidd]

Most people don't use the graph so hitting that limit might be okay until Unity (hopefully) increases the default.

We can use enums to reduce variants. If we get desperate, we could pack as many keywords into enums as possible. It would be ugly but (hopefully) workable. We should be using enums already for a few things like foam and foam with 3D lighting. And even transparency and caustics.

[huwb]

Oh that is a good point - yeah we could up the limit locally.. for now..

You mean use enums and dynamic branches in the shader? Yeah that is true

[huwb]

I believe this is no longer relevant, next big asset store release will have this.