fog with pixel shaders < 3.0

[H. Verbeet]

On 12/03/07, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> With per
> fragment fog we have linear, exp and exp2. With glsl we can make it a
> parameter, but for arb shaders we have to hardwire it in the shader.
I don't think we really want to use branching for that anyway.

> What we need for the start I think is the ability to recompile the shader.
> (Destroying the arb / glsl programs, removing it from the linked glsl shader
> table and reset the shader object). Henri, do you have any patches for that
> handy or should I take a look? With that I can then also add the signedness
> fixup for the bump map formats if no suitable extension is available.
No, but the hash table functions in utils.c should be generic enough
to help at least a little bit with keeping track of the different
states.

> If we want to manage multiple compiled shaders with fog on/off then we should
> extend that to the whole parameter set. We already have sampler type(2D, 3D,
> cube), texture transform flags(D3DTTF_PROJECTED) and now fog and pixel format
> coming. My concern is that managing this will get too expensive and grow the
> amount of linked glsl programs vastly.
Up to a certain point. This should only be an issue for pre-2.0
shaders, and MSDN does hint that changing some states (like eg. the
sampler type) might cause a shader recompilation, so applications
doing that will probably be in trouble on Windows as well.

> Somehow you will have to get the fog parameters into the shader. Start and End
> won't be of much issue, but the formula will be a problem. Not so much with
> glsl, but arb will be hard.
See my comment above wrt. branching.

I think it's important here to know what exactly is the problem, and
under which conditions this happens. It would be a shame if we started
adding lots of complexity because of this, only to find out later that
it could have been avoided by eg. simply always using per vertex fog
when a pixel shader is used.