skybox circles?

(Quaker-X) #1

Is there a fix for this weird sky effect?

shader:

textures/klesk_1/sky
{
	qer_editorimage textures/klesk_1/sky.tga
	q3map_lightsubdivide 768
	q3map_backsplash 0 0
	q3map_sun 1 1 1 100 180 90
	q3map_surfacelight 100
	surfaceparm sky
	surfaceparm noimpact
	surfaceparm nolightmap

	skyparms textures/klesk_1/env/lostatseaday - -
	
	nopicmip
	nomipmaps
	{	
		clampmap textures/klesk_1/arc.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		tcMod transform 0.956 0 0 0.956 -1 -1 
		rgbGen identityLighting
	}
}

Thanks.

(ydnar) #2

Use non-compressed, 32-bit textures. Check your Q3 settings as well as your video driver settings.

y

(ratty redemption) #3

ydnar, is there any advantage to using compressed tex if we have gfx cards with 64mb or more video ram?

(gerby) #4

I get this lots.
I believe (IE waiting to be contradicted here!) that there´s bugger all you can do about it, and here´s how I come to that conclusion :slight_smile:

any texture loaded in, unless specified otherwise, is brightened / darkened by various factors (eg gamma, specific brightness / overbrightness settings).
what starts out as a smooth set of RGB values then gets multiplied / divided / added to etc as these brightness parameters are applied. Now either at each stage or at the end (probably at each stage, I doubt anyone would bother converting rgb characters to float, but I could well be wrong). The problem is, at the end, your values have to be rounded down / off (no idea which, doesn´t really matter) to end up back in plain old rgb format. And you get rounding errors (are they called quantization errors?).

As an example:

0 0 0 = black
1 1 1 = dark grey
127 127 127 = mid grey
because of gamma they get multiplied by say 1.4. In floats we might have:

black becomes 0.0 0.0 0.0
dark grey becomes 1.4 1.4 1.4
mid grey becomes 177.8 177.8 177.8

when they get converted back to integer values for the RGB, they become:

black = 0 0 0 (no change)
dark grey = 1 1 1 (no change)
mid grey = 178 178 178

I´ve used extreme values to illustrate how discrepencies occur when scaling up, but the same (or worse) is true when scaling down, because then adjacent values ´collapse´ to the same values as near ones, which is what is often what you see from banding.

Now, I don´t actually know that any scaling down is possible (assuming gamma etc are greater than default?) but I do remember reading somewhere that multiply texture layers use 2* multiply. This may account for why all default textures are so dark, I´m not sure, but it´s slightly (Ie not likely) that textures get darkened by default, which may account for some of the banding.

Or, in short!

Anytime a smooth gradient gets altered by multiplying or dividing (here through brightness settings) some banding may occur :confused:

Now, I await the ´wrong!´ posts :slight_smile:

(ratty redemption) #5

gerby, “right” or “wrong” it`s an interesting theory and helps me better understand why banding could happen.

off topic: is your normal email accounts working? cus I emailed you over xmas and haven`t heard anything back yet.

(Quaker-X) #6

Yes, interesting read for sure. I am still getting the banding effect on my skybox. Uncompressed, 32bit TGA, my Q3 settings are fine, same thing. It’s odd.

(gerby) #7

Well, the theory should be fine, I have this problem in my own games when doing brightness settings. It also occurred to me that the banding depends on how things are brightened, they may not necessarily be multiplied, they may have fixed values added (which may explain oversaturation / overbrightness) etc. I really don´t know what they do exactly without looking in the source, and that´s something I´ve put off doing because I already have too much to play with :slight_smile:

off topic: is your normal email accounts working? cus I emailed you over xmas and haven`t heard anything back yet.
Yar it do be, but I´m not picking it up. I am at my gf´s family´s place, on 56k modem, so I´m only on my hotmail address. I signed off all my lists, but I really didn´t fancy downloading 100+ spam each day over crap-band technology :frowning:
Am back in just under a week now though, so hooray!

(ratty redemption) #8

understood and I`ll email you again when I see you back to your normal login account on the forums :slight_smile:

(Hewster) #9

I don’t mean to sound condisending, but is the banding in your
actual texture ?

If you originally created your texture and saved it in any lossy type
fotmat, then simply opening the texture and re-saving as 32bit tga
won’t “magically” restore any lost image information.

maybe post it here so we can take a peek

You may of course fully understand the above, in which case I
appologise for stating the obvious :slight_smile:

Hewster

(ydnar) #10

Check the driver settings. Both ATI and Nvidia have settings to override an application and use compressed or lower-bit-depth textures.

y

(seremtan) #11

I’ve noticed this a lot on Terragen skies with little or no cloud cover. Maybe the explanation regards rounding of the RGB values is correct, but the banding doesn’t occur anywhere except on clear skies (like in the screens above). Using soft clouds removes the banding entirely.

Banding also occurs in lightmaps on curved single-colour surfaces (i.e. where there are shadows), which would suggest it’s a more general engine issue.

(ratty redemption) #12

I`ve just tried running ja with r_ext_compress_textures 0 in my ja cfg files, and the first sp map went from an average of 50-70fps down to 2-3fps, and this is without dynamic glow which seems to cut the fr on my radeon 9800 pro in half anyway.

so it would seem some games do need compressed tex, yes?

or is there a difference between us saving them compressed formats, and the engines loading them and compressing in video memory?