Quake 3 Levels too dark

Started by
6 comments, last by weasalmongler 22 years, 1 month ago
I''ve got my Quake3 bsp renderer up and running, with lightmaps and textures displayed as well as geometry. My problem now is that the levels look WAY too dark with the lightmaps added. I am using OpenGL and hardware Multitexturing. Basically I have tried increasing lightmap brightness by manually by multiplying each pixel colour by a scalar, but that only results in distorting the colours (it is an RGB lightmap!). I have tried adding a number too each one but that brightens the whole lightmap too much. I have also tried brightening the textures rather than lightmaps, with inadequate results. Currently I am setting up ''glTexEnvi()'' for the main texture as GL_REPLACE and as GL_MODULATE for the lightmap. I have also tried GL_ADD for the lightmap (which actually generated OK results, but the level ended up too bright!). Does anybody have any ideas on how to brighten up the levels? -Weasalmongler
Advertisement
Well, you could use a gamma ramp type calculation, which is what I plan to do one of these days.

At the moment, I just multiply all the values by 1.4, which seems to work well for me.

I follow the shaders as far as the order of textures and blend mode goes, and they generally GL_REPLACE the lightmap and GL_MODULATE with the ''base'' texture. So try that and see if you like the results that way.
I''ve done the same thing in DirectX, you can use gamma-ramps where the hardware supports them, but to my mind it would be better if you manualy adjusted the colour values (textures etc). Then it would work on non-hardware gamma systems as well.

,Jay
I don''t suppose you would be willing to post your resources that you found on loading .BSP files, would you? I would like to try to do the same thing in DirectX.

Moe''s Site
Try this function I modified a gamma correction program and it works very nicely.

static void gamma_rgb(byte map[128][128][3], float factor)
{

for (int y = 0; y < 128; y++)
for (int x = 0; x < 128; x++)
{
float r,g,b;
r = map[x][y][0] * (factor / 255.0f);
g = map[x][y][1] * (factor / 255.0f);
b = map[x][y][2] * (factor / 255.0f);

float scale = 1.0f;
float tmp;
if (r > 1.0f)
{
tmp = 1.0f/r;
if (tmp < scale) scale = tmp;
}
if (g > 1.0f)
{
tmp = 1.0f/g;
if (tmp < scale) scale = tmp;
}
if (b > 1.0f)
{
tmp = 1.0f/b;
if (tmp < scale) scale = tmp;
}
scale *= 255.0f;
r*=scale;
g*=scale;
b*=scale;

map[x][y][0] = r;
map[x][y][1] = g;
map[x][y][2] = b;


}
}


Right, I''ve fixed it.

I run this code at the beginning of my texture loading portion of the renderer:

glPixelTransferf(GL_RED_SCALE, 1.7f);
glPixelTransferf(GL_GREEN_SCALE, 1.7f);
glPixelTransferf(GL_BLUE_SCALE, 1.7f);

This brightens all textures by a scalar of 1.7. Is this a good way of doing it? Would it be better to change the values manually (last time I tried that for some reason some pixels would turn red or green for no apparent reason!)?

Thanks for everyones help so far though.

-Weasalmongler
The reason that your pixels changed colour rather than lightened is probably due to inconsistancy in colour depth. If your glPixelTransfer method works with little or no overhead then I would use that, try profiling it.

,Jay
The reason your pixels turned colors is probally due to the fact that you added a certain value to them, but forgot to stop at 255, looping back to the beginning.

For instance:

You start with the color 244, 81, 192 Which looks likeTHIS

If you add 30 to every value you get 274, 111, 222 This turns out to be 19, 111, 222 because each value only goes to 255.

19,111,222 looks like THIS which is a very different color then intended.

If you lock at 255 you get 255,111,222 which looks like THIS much closer to the intended result.

Those who dance are considered insane by those who cannot hear the music.

This topic is closed to new replies.

Advertisement