Overbrightbits and Flags, other trans effects.

[Hipshot]

Is there a way to get the same colors and so when running default fullscreen, that is overbrightbits 1, as when running with overbrightbits 0, as it seems to do in winmode? Now, my water and sun, which is both transparent effects, looks very different, also, I have a flag, (copy protoflag) which has a lightmap, it's totaly black, when turning into overbright 0, it's normal again. Haven't notice this so much before, but it's really annoying. Is there a shader variable that I can use to fix this problem on noted shaders? If not, how do I do to get the flag working? Feels pretty stupid having a totaly black flag with nothing on it...

[$NulL]

Can you post at least one of the shaders please. Its probably an rgbgen fix, changing to identity or identitylighting. But without seeing the shaders i dont want to commit myself and windup looking a fool

[Hipshot]

SOrry. I know my posts sucks when I'm tired, now I have slept =)
The flag, you should know that the same thing happens with the protoflag that iD made, this is about the exact same shader, I've already tried changing the rgbGen...

Code: Select all

textures/hipshot_dm6/flag_01
{
     cull disable
     surfaceparm alphashadow
     surfaceparm trans	
     surfaceparm nomarks
     tessSize 64
     deformVertexes wave 30 sin 0 3 0 .2
     deformVertexes wave 100 sin 0 3 0 .7
     
        {
                map textures/hipshot_dm6/flag_01.tga
                alphaFunc GE128
		depthWrite
		rgbGen vertex
        }
        {
		map $lightmap
		rgbGen identity
		blendFunc filter
		depthFunc equal
	}


}

[Black_Dog]

Switching between rgbGen identity and identityLighting doesn't have exactly the same effect as switching between r_overbrights 1 and 0, in my experience - meaning there are four different "brightnesses" which a given texture might be displayed at in q3. More, if you consider that you can choose a different rgbGen for lightmap and texture.

Fuck that shit.

[$NulL]

I just had a quick test of the shader with my own textures and found rgbgen identity in the first stage works best.

Filtering a lightmap over a vertex lit stage is just asking for trouble.

[Shallow]

It always seemed to me that if you applied a lightmap over an alpha stage, the end result would seem darker than an identically lit surface that didn't use alpha blending. I'd never noticed overbrightbits having any effect but it makes sense since when I was trying to fix issues related to this I was alt-tabbing between Quake 3 and Editpad.

I think id noticed this as well and their habit of using rgbGen vertex on the texture stage must be related to it. It only worked for them since the vertex lighting in the original q3map was really rather bright compared to the lightmaps. Once you switch to q3map2 you get much more accurate vertex brightness so applying this workaround doesn't help much.

You might want to try messing around with the vertex lighting to make it a bit brighter. I think there is a switch in q3map2 which makes it use the old vertex code?

[obsidian]

Perhaps try -gamma 2 and compensate 4?

[Hipshot]

Perhaps try -gamma 2 and compensate 4?

Been using that since the feature came...

[Hipshot]

So like 18 years later, no one seems to have a solution to this. But having forced into this stupid thing again, I found a so-so solution that seems to work at least in an acceptable way

I added this at the end, it's an add stage that goes above the lightmap stage, that brightness the entire thing a bit. By tweaking the rgb const values, one can find a good middle way between brightbits 1 or 0.

(the issue is the alphaFunc GE128, that makes the following lightmap too dark, for some reason)

Code: Select all

{
	map textures/hipshot_m16/leaf.tga
	rgbGen vertex
	blendFunc add
	depthFunc equal
	rgbGen const ( 0.35 0.35 0.3 )
}

Maybe someone have a better solution after all this time.