okay, if TNT2 is slow, then don''t even try doing detail textures j/k


The fog takes places in the final step of the rasterization process (after texturing and color sum).
The rasterization gives a fragment.
Then there are some test (like alpha test and depth test) before the fragment goes into blending equations.

In OpenGL Specifications 1.3, see "Figure 3.1. Rasterization" at page 59, and see "Figure 4.1. Per-fragment operations" at page 157 for eye-candy figures


Blending discussion

What I do not know is how RipTorn is able to add signed values in the blending equations.
When you have a grey fragment, how can you configure the blending equations so that the destination fragement remains unchanged ?

Blending produces a fragment C = Func( Cs, Cd, S, D ) where :
C = result of blending
Func = a user-defined function
Cs = source fragment (just computed in the rasterization process)
Cd = destination fragment (already present in the framebuffer)
S = source multiplier (eg GL_SRC_ALPHA, GL_ONE_MINUS_DST_ALPHA, etc)
D = destination multiplier

But the user-defined function is one of the following only (AFAIK) :
FUNC_ADD : C = Cs*S + Cd*D
FUNC_SUBTRACT : C = Cs*S - Cd*D
FUNC_REVERSE_SUBTRACT : C = Cd*D - Cs*S
MIN : C = min(Cs, Cd)
MAX : C = max(Cs, Cd)

If there existed the function :
FUNC_ADD_SIGNED : C = Cs*S + Cd*D - 0.5
then that would be easy. But according to the current available blending functions, I don''t know how to blend

I''d assume that fog is calculated before blending, otherwise additive sprites + fog wouldn''t screw up like it does.

I just tried it, and it works beutifully.. no more faded mipmaps for me

Because it works very well, would you please describe the algorithm using fog ?

If you''re *only* brightening OR darkening then that''s *pretty* easy to do it in one pass using fog.
But if you''re brightening AND darkening in one pass, then I still don''t know how you do it using fog.

tnt2 using 2 texture units uses twice the fill, gf doesnt
>>On the simmilar note. Did anyone try using bumpmapping insted detail map?<<

yes ive stoped using detailmaps a while ago im using bumpmaps instead my setup is sortof like this now
(for terrain mind other surfaces have different requirements)

bumpmap (give the impression of more triangles)
bumpmap (fades out with distance for more detail up close)

http://uk.geocities.com/sloppyturds/gotterdammerung.html

I''ve never used the add_signed blending extension, so I''m just assuming here, but since the component has 128 subtracted first, grey (128,128,128) will have no effect on the blending operation. The range of values becomes -128>127 instead of 0->255. As far as I know.

also note that when it comes to top of the line hardware (GF4 ti) you won''t actually see much, if any, performance boost from using multitexturing over multipass, I think it was carmak who talked about this a while ago. not sure where though. I may be utterly wrong though.

http://www.riptorn.8m.com

RipTorn : nice that it works.. but does it work in 1 pass? I''m gonna try it tonight when I get home from school.. and another bonus is that you can control distance/fade-off of detail texture. And you are right about multipass vs. multiexture on new cards but only if you''re not fillrate limited.

You should never let your fears become the boundaries of your dreams.

RipTorn: The ''blend_add_signed'' extension does not exist. If it existed it could solve the problem.

You assume that "the component has 128 subtracted first", but when ? After the rasterization process ? During the blending process ?

a little extract from glext.h

#define GL_ADD_SIGNED_EXT 0x8574

as I say, I've never used this (although I'd love to use subractive blending, which is an awesome way of doing smoke, and some types of shadow, background of fire/explosion effects... etc..)
but I have no idea of the effect of fog on texture mode of texture units, so I'm not sure if this will work the way it would in (my) theory
but for a generic single pass (not multitexture), fogging does work perfectly.

[edited by - RipTorn on May 23, 2002 6:30:33 PM]

LOL. We all know the GL_ADD_SIGNED token exists. But what we would need is something like GL_FUNC_ADD_SIGNED