blendFunc GL_DST_COLOR GL_SRC_COLOR

[a13n]

You know the minor blendFunc GL_DST_COLOR GL_SRC_COLOR which is mainly used for detail texture.
But when it is used for $lightmap blending, it can help to achieve greater color range or higher contrast.
This blend mode really works with r_overbrightbits 0, in windowed mode or on unix.
Here is a comparison between GL_DST_COLOR GL_ZERO(namely filter) and GL_DST_COLOR GL_SRC_COLOR.



Both of these pics are captured with r_overbrightbits 0.
Above pic is a dull default blending.
Below is a new blending.

[EDIT]
This high contrast can only be achieved with the texture of 50% gray or above.(or photo realistic texture?)
In the pics above simple flat (0.5 0.5 0.5) texture is used.
So this method won't work properly for most of the default q3 textures which have a color range below (0.5 0.5 0.5) for obb1.

[a13n]

Here is a sample script.

Code: Select all

textures/flat/50
{
  {
    map textures/flat/50.tga
    rgbGen identityLighting
  }
  {
    map $lightmap
    blendFunc GL_DST_COLOR GL_SRC_COLOR
    rgbGen identityLighting
  }
}

$lightmap * 50.tga + 50.tga * $lightmap
[from 0 to 1] * [0.5] + [0.5] * [from 0 to 1] = [from 0 to 1]

If the rgb values of base texture are lower than 0.5 or darker(i.e. 0.3), apparently final blending never exceeds 0.6, resulting in low contrast or dull lighting.

And here is another sample screenshot.(a bit oversaturated due to the quickieness)


[merit]
1. There is a large possiblity that generic free textures on Internet could be used without excessive adjustment.
2. Map runs much faster thanks to obb0. :lub:
3. Mappers can test their maps without going to fullscreen. :icon14:
4. Lighting can be consistent between full-screen and windowed or unix. :lub:
5. Mappers no longer have to raise the value of gamma in radiant.

[demerit]
1. This method is completely dependent on source textures.(Almost all of the textures for q3 won't work, whether they are default or custom-made, unless they would be adjusted accordingly.)
2. Every texture need its own shader script.
3. Lighting tends to be more oversaturated or sensitive.

[a13n]

One more important note on blendFunc GL_DST_COLOR GL_SRC_COLOR...

1stly, take a look at these pics.
img 1

img2

img3

img4


img1 has no detail texture.
img2 & img3 have a detail texture stage.
In img2 it comes after $lightmap.
In img3 it comes before $lightmap.
Last pic, img4 shows the shader script for img3.

[conclusion]
Unlike filter'ed $lightmap, detail stage should come before "map $lightmap".

[leilei]

now try with overbrights set to 1.

This is why no one multiplies lightmaps. Ever. Plus model lighting would be inconsistent.

[Amphetamine]

Would also make the shaders incompatable with lightstyles.

[a13n]

@leilei
You're missing the point here.
This is an approach to be free from mal-consuming(M$-wise) obb1.
Because each texture needs a shader script, mappers can designate "rgbGen identityLighting" there.

As for model lighting, you might be right but there should also be model-specific workarounds.

@Amphetamine
Does q3 really need flickering lights?

[Silicone_Milk]

yes.

[a13n]

yes.

All right. :icon30:

But just remember that as well as this "initial(earlier)" blending mode mappers or texturers can still hold the option of using the default $lightmap blending, namely filter.
This means they have more controls over the way materials are lit.
They can also even configure the specularity with custom detail textures afterwards if necessary.
Sounds exciting, doesn't it?

[obsidian]

Not really. This is light being emitted from a light source and bouncing off surfaces. By multiplying light sources, you effectively make it look like the walls are the light source itself. That's not how it works in real life. If you wanted brighter lightmaps, just use a brighter light source. Does it look better? Maybe if you were creating a map of a disco club or something.

I'm sure you can use additive lightmap blends as well, and that would achieve other "effects" as well, but why would you want to? You're just making lightmaps behave less realistically while running into more limitations.

[Amphetamine]

Does q3 really need flickering lights?

I would say animated lights rather than flickering, since there is a lot more you can achieve with them than just "flickering" if you put a little thought into their usage.

I'm sure you can use additive lightmap blends as well, and that would achieve other "effects" as well, but why would you want to? You're just making lightmaps behave less realistically while running into more limitations.

I've tried addative fake lightmaps and could never get them to look right unfortunately.

Agreed that there are a lot of things which can be done with shaders, that may or may not make your level look better, but there's always a limitation somwhere along the line. The trick is figuring out if that limitation is worth sacraficing other things for the sake of an effect. I'd say this one could safely be put to bed in the "not worth it" pile, purely because I don't think what it adds to the look of a level is worth the effort of writing a shader for every single texture used and loosing the ability to use lightstyles.

[a13n]

But this is the only way to get higher contrast in windowed mode or on unix.
Mappers have only to be more careful to oversaturation.

If you browse through the texture sets of SoFII, you'll find that those textures are really appropriate for this method in terms of rgb levels.
In fact most of the official MP maps of SoFII are way too dark to play decently, forcing users to raise gamma.
(Note: In SoFII MP, obb is 0 by default)

BTW, below is a ref pic of ut2k3.


Anyway, from now on, my maps will go with it.
Thanks for the replies.

[obsidian]

Okay then... have fun with that. :icon22: