Introduce FogExp and consider refactoring+FogLinear

[EliasHasle]

In https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderChunk/fog_fragment.glsl.js, under the FOG_EXP2 ifdef:

float fogFactor = whiteCompliment( exp2( - fogDensity * fogDensity * fogDepth * fogDepth * LOG2 ) );

Is exp2(something*LOG2) intended here? LOG2 is 1/ln(2), and exp2 is the base 2 exponential, so the expression simplifies to exp(something).

I also wonder why the density and depth are squared. What is the physical analogy? For comparison, they are not squared in the implementation here: https://iquilezles.org/www/articles/fog/fog.htm

[WestLangley]

Source of the fog equations...

This: #61 (comment)

references this: http://www.geeks3d.com/20100228/fog-in-glsl-webgl/

which references this: http://ozone3d.net/tutorials/glsl_fog/p02.php

[EliasHasle]

...which references this: http://glprogramming.com/red/chapter06.html#name3 (and another, dead, link)

None of them explain why there is a fogExp2, but it indeed appears to be a concept, alongside foxExp. The ozone3d source repeats the same complication error that I pointed out. Note that the glprogramming source does not. It defines fogExp2 as e^-(density*z)^2, which is equivalent and simpler. The usage of exp2 looks like a mistake, probably motivated by "Exp2" in the name, which apparently refers to the squaring.

I suggest adding a FogExp, which does no squaring.

[mrdoob]

So what would the glsl be for FOG_EXP?

[EliasHasle]

#ifdef FOG_EXP
		float fogFactor = whiteComplement( exp( - fogDensity * fogDepth ) );

And FOG_EXP2 can be simplified to:

#ifdef FOG_EXP2
		float fogFactor = 1.0 - exp( - fogDensity * fogDensity * fogDepth * fogDepth );

You don't even need to apply the whiteCompliment (should that be whiteComplement, no?), because the squaring makes the argument always non-positive and the exp always at most 1 (and still above 0).

[WestLangley]

FYI, Microsoft Fog Formulas (Direct3D 9).

Since there are no complaints, I would not change what is currently supported.

You can change the implementation if you want, as long as it produces the same result.

[EliasHasle]

The DirectX fog types are the same three: linear, exp and exp of square (so-called "exp2", but not using the exp2 function). I may perhaps throw together a PR simplifying the exp2 variant and introducing the simple exp variant, if @mrdoob isn't working on that already. (Probably not in a few days, though.)

[WestLangley]

I may perhaps ... introduce the simple exp variant

As I said, since there are no complaints, I would not introduce additional variants.

[EliasHasle]

Then I complain right now. 🙂 From what I can tell, simple exponential fog is the one of the three that makes the most physical sense. Here is a discussion of different types: http://in2gpu.com/2014/07/22/create-fog-shader/

[EliasHasle]

I consider making two PRs:

1. Simplify the FogExp2 shader code, correct the documentation and rename the fogExp parameter to the more accurate fogExp2. As far as I know, this parameter is used only internally, so shouldn't be a problem.
2. Introduce FogExp class and shader code that uses simple exponential decay. Add full support in all places where FogExp2 is currently mentioned, maybe even in examples. And docs.

Is the plan OK, @mrdoob?

[WestLangley]

Introduce FogExp class and shader code that uses simple exponential decay.

I see no compelling reason to add additional decay functions.

A simple exponential applies more fog close to the camera. ( It has very similar behavior to that of linear fog if fog.near is zero. )