Surfacelight & Skylight have wierd colors

(RabidCow) #1

I have been having a problem with the quality of surfacelight and skylight. I have been finding that both of those types of light leave major color stains on surfaces that are close to gray and are in shadow. The problem is exacerbated by the use of the default r_overbrightbits 1 setting but appears in a less gross form even with r_overbrightbits 0. It looks as though the light is in low-bit color, ie uneven transitions between colors. For this reason I have been shunning the use of skylight and surfacelight in favour of an entity sun with ambient (of course high levels of ambient light has it own problems). Now, however, I am being plagued by the color casts being added by pointlights, which use surfacelight. Here are a couple of screenies from ut_rommel’s latest version released yesterday in Urban Terror beta 3.0. Since I was trying to isolate the problems I was seeing, I changed my skybox editor image to white, removed ambient light, removed the entity sun and just left a few pointlights that were being used for local lighting. The color casts are all over the map…

notice the rainbow of colors on the side of the building…

again, the surfacelight based shader is causing ugly colored shadows…when no surfacelight or skylight (they both do this) is present at all and an entity sun is used with only ambient to brighten the shadows, the color casts are completely gone…

Anyone have any suggestions? As I mentioned, certain types of lighting on flat colored textures make it most obvious, while well lit outdoor areas may make the problem nearly invisible…

Thanks, for you time :slight_smile: and Ydnar thanks again for the wonderful advances you have given us with q3map2 :slight_smile:

(ydnar) #2

Try setting r_ext_compresstextures 0.

Also, set your texture depth to 32.

16-bit textures and DXTC texture compression sacrifice color fidelity for size. If lightmaps are compressed, they get trashed.

High ambient/minlight is not the best way to get good sky lighting.

If you want to set the exact color of the sky/surfacelight from a shader, add a q3map_lightimage directive to the shader that specifies an exact TGA for lighting purposes.

y

(RabidCow) #3

Thanks Ydnar but r_ext_compressed_textures is set to 0 and my color depth is 32 bit, trilinear filtering, high detail, everything is set for best graphics quality…I double checked all of those possibilities. It only happens with surfacelight and skylight. This problem is the only reason that I ever use ambient light in my maps…
I’ll try specifying the color of surfacelight with the light image and see what happens

(ydnar) #4

Check your detonator settings.

Nvidia does less-than-scrupulous things to squeeze a few more FPS out of their cards, including, but not limited to lowering texture quality and overriding application setttings. *

y

  • Edit: Yes, ATI does this as well, to some extent. :slight_smile:
(RabidCow) #5

Checked my detonator settings but they were all set to highest quality (except for anti-alaising). The q3map_lightimage seems to have helped the skylight from the skybox shader but the normal pointlights have ugly colors. Again, I have to stress that some of this stuff is much less obvious if I use r_overbrightbits 0. The problems are still there but are less visible. The pointlights had a color of 1 .81 .49 so I changed that to 1 1 1 for a test. The problem was lessened but still visible. Is there any setting that would increase the precision of the lighting calculations for standard lights, including surface/skylight so color gradations are not visible? I have experimented with not using -fast in the lighting stage but this didn’t help…only the use of just the sun and ambient light removed all traces of the color cast. I have now experimented extensively on 3 different maps and have been unable to find a high quality solution…haha, oh yeah, if you want to see the problem in all of its gory glory, just add a large dab of _minlight to the mix…ack! That and the default q3 r_overbrightbits 1 setting, with a skybox with q3map_surfacelight 90 or q3map_skylight 90 2. Use that with a map that has lots of shadows and midtones. What was just a small problem is shown in “technicolor” :). The difference, in terms of color purity, when compared to only an entity sun with ambient light is striking…
Thanks again for the help Ydnar! (BTW, does the lighting code do more precise samples from the .tga lightimage, and if so, can I apply that to standard lights or is the solution to not use standard lights and only make my own shader lights with specific q3map_lightimage references? I still need to try the skylight with a colored lightimage…white may just be covering up some of the problem :)).

(ydnar) #6

Is this problem exhibited on other maps as well?

You’re seeing color artifacts that can’t possibly be created by Q3Map2… something is hosing the lightmaps.

Can you try an r_lightmap 1 shot?

y

(RabidCow) #7

I tried r_lightmap 1 but no change occurred. I built a small test map today and added only a spawn point and a skybox ceiling with reasonably neutral colors for the walls. The skybox shader was

textures/jeffj/box25
{
//q3map_lightimage textures/jeffj/box25.tga
//q3map_globaltexture
q3map_skylight 80 2

//q3map_sun .76 .695 .721 80 180 37
//q3map_surfacelight 40
q3map_backsplash 0 0

surfaceparm sky
surfaceparm nolightmap
surfaceparm noimpact
surfaceparm nomarks

skyparms env/box25/box25 - -

}

The image used to represent the skybox was pure white, no other lights of any kind were used. I saw some color in the walls…but the gridlight went crazy as I moved around the tiny box…

This may not be directly related to my main problem, since it was not a gridlight issue but here are the results…

btw, q3map2.5.5 test 13

This position in the box looked fine…

however, as I moved around the box…

I had someone else compile the testmap on a completely different PC and the results are the same…

Maybe I’m just missing something about small boxes, but I didn’t expect these results…

(ydnar) #8

Have your coders check where it’s sampling the lightgrid for the gun (and gun components). From what I could tell playing the new version (nice job, BTW) was that every single part of a gun, including all the rounds in the belt for the big machine gun were being lit independently. This is, of course, slower. Maybe you should have them recode it to get the light value for the model from a single point, say the camera origin.

You might want to try that same map in vanilla quake 3 and see if it exhibits the same problem.

y

(RabidCow) #9

Thanks Ydnar, I’ll have our coders have a look. The results with vanilla quake 3 are exactly the same however, just with quake3 weapon…on this little test map (I added another room just to see if that was the problem, but no change).

As before, some areas are fine…

Other areas, specifically the corners, are engulfed in color…

(ydnar) #10

Mind sending me the map? I’ve never seen this bug before… :slight_smile:

y

(RabidCow) #11

Hmm, before sending the .map to you I decided to see if I could reproduce the problem with a different size testmap…I made a single room that was larger and the problem didn’t exist. I then went back to my original test map and “cleaned up” the construction ie: mitered the corners of the box, made sure there was caulk between all joints etc but the problem still appears.

http://64.180.91.204/testmap.zip

The testmap has two rooms but the problem existed in the one with the extra wall in the middle before I added the second room. Thanks for having a look Ydnar :slight_smile:

(ydnar) #12

OK, the grid light thing is a bug. And it’s not one I can fix.

That test map happens to be taller than 128 (the default lightgrid cell height) and less than 256 (twice that). Since the lightgrid size calculations are done in both Q3Map and the engine, there’s no way to fix it without a patch. Additionally the floor brushes are so thin that the lightgrid sample point is outside the 8x3x1 grid the map coords generates.

So basically don’t make a map that short.

Back to lightmap problem…

y

(Hewster) #13

it looks to me, like you have your gamma way up ?
what does the map look like with default graphic settings ?
how much _minlight or ambient is there applied ?

I know most maps look too dark with default settings (mainly cos the
gamma slider doesn’t work on most systems until you r_ignorehwgamma)

I have recently been using the " q3map_lightmapGamma" in my shaders
to brighten up the shadows… I can now get pretty decent brightness
even with default graphic settings using this, without the need to use
_minlight or ambient, although you do need to give it plenty of
_minlightgrid, to make sure the player models are lit enough.

Just a thought :slight_smile:

Hewster