To me, the only advantage of doing fog in a post-process is to reduce the number of pixels treated (as would happen with a Z-prepass).
Being able to tune the formula for how height influences fog can be done during lighting as well, but without the weakness you mention, so I don't think having it as a post-process is the best way to go.
To me the drawbacks of having it in the lighting pass are:
- need a #include system (which we don't have for now) to avoid code duplication
- number of shader combinations (not a problem for STK at the moment).

So I suggest we keep going with post-process for now but would benefit from having it in the lighting pass later on. Except if the limitation for transparent objects ends up not being too much of a burden for the artists...

2013/9/13 Lauri Kasanen <>

As you know, fog was removed months ago from cluttering all shaders, to
be put into a post-process effect. It's now implemented, with
additional flexibility over fixed-function fog (height tunables, for
example for subsea, or for some mountainous level [1]).

Mansion is looking very fine now. However lighthouse shows the weak
point: a PP effect cannot distinguish a transparent mesh against the
sky from the sky. Sky obviously shouldn't get foggy.


This should be taken into account in level design - trees visible
against the sky (in foggy levels) should preferably be solid, ie use
alpha_ref transparency.

- Lauri


How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
Supertuxkart-devel mailing list