What the heck does the switch for light phase “-cheap” do? :banghead:
Please explain visually as shown below.
Thanks in advance.


What the heck does the switch for light phase “-cheap” do? :banghead:
Please explain visually as shown below.
Thanks in advance.


Is this a joke or something? What generated those pictures? Certainly not -light or -light -cheap, which has zero affect on a surface’s triangles.
y
Just if y didn’t already make it clear, this is not cheap.
Cheap is a switch that clamps light values, so once they go above 255 or whatever, light stops calculating it. This is faster but has the side effect of much less accurate light in many circumstances.
More than just Q3map2 has this, many compilers for other games do to. Zoner’s Half-Life Tools for example. It has nothing to do with triangles. 
can -cheap work with -fast?
I guess this would be fine for test compiles where lighting is not as important as brush and tex work.
Pics above are nothing more than examples.
They have no meanings nor were they intended to be a joke.
It might be confusing. My bad English. 
Correctly,
Please explain using your appropriate 2 pictures.
One is on another offf.
BTW is it O.K. to think of this like this?
280=255 (cheap on)
280=280 (cheap off)
BTW how can I specify rbg value of 280 in paintshop?
Its limit is 255.
Strange. :disgust:
The Quake 3 engine uses a few internal hacks to get lighting precision. I think Carmack once said he got it up to something like 10 or 12-bit internally. This scale falls outside the normal range a renderer can produce, so the scale is dynamic in effect.
You still have 8888RGBA color, but internally the engine has greater precision. Overbright bits are the effect we see in game. Cheap is a way of cutting off lighting by clamping the scale to a strict linear range.
The dynamic range is effectively 9 bits with r_overbrightBits 1, but due to r_mapOverbrightbits defaulting to 2, actual precision is 6 bits.
The only time using -cheap matters is if you have Cranky Steve lighting or don’t use radiosity or care to bounce the out-of-gamut light.
y
so I guess it`s fine for test maps, but should we use it with -fast, or do they conflict with each other?
Thank you guys for your answers.
But color depth is 32 bits in max.
Can hardware distinguish such an overranged color?
And can human, too?
(of course, I recognize the difference between r_overbrightBits on and off.)
sigh
32-bits is used when you have an alpha channel (transparency/translucency), using 8-bits per channel.
32-bits total
The actual colour range is the same as if you’re using 24-bits, it’s just that you have an extra alpha channel for transparency.
Oblivion, I’m asking about “greater color range.” :disgust:
8bits becomes 10bits?
or some sort of overall color shift is performed?
Thanks in avance.
O.K.
I was foolish. :disgust:
pic01

pic02

Maybe Quake3 has limited color range by default like pic01.
But overbrightbits extends it like pic02 if not to all range.
Then call it “greater color range.”
Just an assumption though.
Is this right?
Shader manual does not help.
Thanks in advance.
I’m O-b-s-i-d-i-a-n… please don’t get me confused with Oblivion, that’s someone else.
You asked this question:
Therefore my reply above, since it doesn’t seem to me as if you understand how the computer processes colour.
sorry, obsidian. 
BTW
“such an overranged color” = above 32bits, i.e. 256bits
It might be confusing.
Anyway it makes no nosense. :lol:
Hi, again.
r_overbrightbits 1:
Lightmaps which look like pure white with r_lightmap 1, seem to look like containing shadows with r_lightmap 0.
r_overbrightbits 0:
Lightmaps just seem to have less color range with r_lightmap 1.
So the trick lies in lightmap blending? :???:
And why my unix cannot set r_overbrightbits 1. :???:
Lastly should we care about both r_overbrightbits on and off when making maps? :???:
Thank you very much in advance.
Forget you even heard of the term r_overbrightbits and just compile with -gamma 2 -compensate 4. It takes care of everything for you.