Is it possible to restore legacy fog while using the deferred rendering mode?

Unity Engine
, , , ,
1

I’ve recently been looking into deferred rendering recently, as the ability to use a lot of realtime lights is definitely appealing.

1920×939 114 KB

One caveat of course, is that by default deferred rendering does not support the built-in basic fog.
I’m making a retro style game where this style of fog is quite important, so would like to keep it if possible.

It is of course possible to add screen-space fog via the post-processing layer:

1456×606 537 KB

But, I was hoping to avoiding using these post-processing features if possible, as they’re a bit overwhelming. Trying to avoid adding in large systems just for one fix / small feature.

So, my question is, is it possible to restore the legacy / basic fog in deferred somehow? This seems to have been possible in Unity 4 / 5 reading older posts.

I.e. is there a standalone package, or something I can do in the HLSL shader to add fog (controlled by the rendering>lighting panel) ?

Thanks :slight_smile:

2

I’m assuming this is the Built-in Render Pipeline? It’s been a while but as far as I can recall using the Post Processing stack is the only way to get it working with that when using deferred. It really is the intended way Unity expected fog to be implemented and it looks like you’ve already figured out how to use it so you might as well just roll with it. There are many useful features in there that you might want to have for later anyway so its worth using regardless. Color look up tables and color correction being two of the most useful I find.

1 Like
3

Thanks for the advice, fair point to at least look into it if some other features may be needed. Would you by any chance know if the performance impact is big for these small features?

Only other avenue I have found to maybe investigate is to have the fog in shader controlled by the globals fog setting. (somehow). Bottom of this documentation:
https://docs.unity3d.com/520/Documentation/Manual/SL-SurfaceShaderExamples.html

4

The performance impact is entirely dependent on the platform and the power of the hardware as well as the feature being implemented. Obviously AutoExposure or SSAO is going to be more expensive than a simple vignette. And since you only pay for what you use it can always make the fancier features options that can be disabled by the user and have the best of both worlds.

But to put it simply, I’ve never even considered it a top 100 issue when dealing with performance. It always is better to focus on reducing batches/SetPass calls, and physics if you are CPU bound and shader complexity or overdraw if you are GPU bound. Granted, I don’t typically use the fancier effects like AO so your mileage may vary. There really is not much cost in providing the option of post processing even if you don’t use it. And to put things into perspective, the Post Processing stack is built directly into the new pipelines so Unity themselves seems to think it’s not much of an issue if you always have the features available.

1 Like
5

Thanks for the feedback, really appreciate it. Sounds like it’s the way to go then, especially if just using the simple deferred fog option.