On 12/03/07, Stefan Dösinger stefandoesinger@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.