[Official] Changing how Fog is done in Unity shaders?

Thats just like light attenuation, kinda of a hassle the first time but then it's all gravy

Does this means i can have different object getting affected by fog in a different way, say color for example? I can see some usefulness in there

 

i see, thx for the explanation, i've gotta say i never did anything serious with the current fog system, hence my confusion

I've noticed this current system uses a textcoord, light attenuation already uses 2, aren't we getting a bit short on these? I remember having created a complex shader that used all of the available ones, does using arrays of them help or solve the problem?

 

It sounds good, but the thing is there is not much to play with fog except what unity already provides, we just need an additional height based fog.
While we can write our own, it would be nice to have an option on the editor for global settings rather than adjusting fog for individual materials.
Soo, just add the height based macro there and thats done.
Or, just expose a fog function somewhere which we can overwrite with our own(if needed)?

 

Ohh...this is interesting, so this will change/remove the FinalColor in surface shader??

 

I see...Hmmm oh hey about changing the built in fog into the shader as long as it make it better then i vote yes.
Sure we have to adapt and if it's give better result then why not...

 

Woops...i mean "in the shader" not "into the shader", sorry
Problem with GlobalFog is it doesn't work well with some transparent object ,out of the box of course except it's already changed in 5 .
Alright i don't want to derail this thread into GlobalFog discussion .
Except if it is included in this thread topic.

 

Wooh seems like a great chance Aras, the less shader patching the better. What kind of unity specific shader patching is still being done? Any improvments to lower memory and prewarming times are very welcome (does 5.0 still store shaders in hex instead of binary format?)

 

I do not agree with Aubergine, Fog also needs to be used as complex fog volume if we want to have a seamless transition between over the water to under the water the way Crytek and Ubi does it. What Aras proposes is a good thing in order to make fog matching any type of mesh for example.

 

I just made some tests. It seems OK but Legacy Shaders should use the old way. Otherwise porting 4.x projects to 5.x will be a nightmare if we have to add these macros in every shader we've already created.

 

"It sounds good, but the thing is there is not much to play with fog except what unity already provides, we just need an additional height based fog.": Aubergine.

I do not agree about the fact we "only need additional height based fog".. That's what I mean. Fog can be used in a lot of different ways, and if we want to have a fog matching a moving surface for example, we need to access to how the fog is calculated and possibly change it.
Also having access to the Grabpass code and being able to modify it would be great (but it is another subject)

 

Well, I already do fog in shader as it's a lot faster and looks practically the same as Unity fog (we just do it per vert and pass in few floats globally).

Since fog is the job of shaders, having it outside of shaders is just misleading at this point. We need less mystery and more tweakability just my two cents.

5 will change a lot of things. Physics, code, shaders. This is the best time to make changes. Some people will moan about changing their shaders, but really is that more than 5 mins work? I don't see it as a reason to worry.

I'd like it to be explicitly asked for in the shader via a macro or whatever to avoid shipping 4x the amount, of course since not all my shaders use fog. Obviously

 

You can already do whatever you want, moving CUSTOM fog around surfaces is already possible as well as any type of fog.

 

hi there,

i am pretty glad that i have found this thread and the little and new #pragma nofog!
using the new deferred rendering you have to add fog as global image effect as only objects using forward rendering will get fog applied to.
so objects that are not transparent but still uses a forward shader (due to a custom lighting function e.g.) while the camera is set to deferred will get the double amount of fog: 1 x by shader + 1 x image effect.

and to give a pretty realistic example: tree creator leaves would not render correctly without #pragma nofog!

lars

 

I just ran into the issue where, as of Unity 5, I cannot change fog modes at runtime. You mention:

• In case you do need that, we'll provide some UI somewhere to explicitly tell "hey I'll need these fog modes in the game".

But I can't find any reference to how this is actually done. Can someone point me in the right direction? Took me a long time to track down the source of this bug, and I'd really like to get it fixed. It's difficult because changing fog modes at runtime does work in the editor, just not the build. Very confusing.

 

Nevermind! I found it under the "graphics settings". Thanks Aras!

 

Does anyone know of a way to use a custom property value for the density of an exponential fog, while still using the macros?
I don't really know the shader syntax yet, so I suppose I could learn that and write it explicitly. But i still don't know which calculations the macros do.

 

Sorry for resurrecting this old thread but ive hit a wall regarding the fog.
Ive a standard shader with an additional pass to add some detail as soft additive blending. Fog is applied to the 2nd pass and no fog in the first surface shader, but then fog color is also additively blending and it looks weird.
I can solve the issue with a 3rd pass to only add fog, though is there a way to finish it with 2 passes only?

 

One thing that I don't understand is why the default unity particle additive shader use "UNITY_APPLY_FOG_COLOR(i.fogCoord, col, fixed4(0,0,0,0)); to fog towards black".
In what circumstance would we need a black fog effects on the particle?

 

Since it’s additive, it practically means it fades out.

 

Yeah,it makes sense.But sometimes particles are needed to be rendered to a gui RT image,so the RGB value extracted from the original render could be wrong(towards pure black or blackish),if using this black fade calculation,despite the alpha value would be right,I can change the RT cameras setting to deal with that although.

 

Why is it that fog is computed per-object in forward and only as an image-effect in deffered, anyway? What limitations or advantages led per object fog, and why can't it apply to deferred rendering?