q3map_skylight q3map_sunext weirdness

(Sub-Zero) #1

I’ve got a map with 4 different sky shaders…they all have the same projected portal (two pass scrolling parallax clouds) but different values for q3map_skylight, q3map_sunext etc… After messing around a bit, q3map2 seems to apply all of these values to ALL of the shaders…so if q3map_skylight is 50 in sky1, 100 in sky2, 200, in sky3 etc, I end up with a super bright sky in ALL the areas! q3map_sunext also seems affected. Right now, I only have those two (along with q3map_lightrgb) set in one of the shaders, but this really isn’t optimal.

Any ideas? I tried to search a bit, but I really have no idea what key words to use in this case.

edit here is an example shader I’m using…
textures/szra3map2/sky1
{
surfaceparm noimpact
surfaceparm nolightmap
surfaceparm sky

q3map_lightmapfilterradius 0 8
q3map_skylight 200 3
q3map_lightrgb .8 .4 .1
q3map_sunext	1 1 0.8 60 30 90 2 3

skyparms - 512 -

{
	map textures/skies/inteldimclouds.tga
	tcMod scale 3 2
	tcMod scroll 0.15 0.15
	depthWrite
}
{
	map textures/skies/topclouds.tga
	blendFunc GL_ONE GL_ONE
	tcMod scale 3 3
	tcMod scroll 0.05 0.05
}

}

The other shaders are exactly the same except for the values for q3map_skylight etc as mentioned above…

(obsidian) #2

I assume you have a different sky shader for each room, and want to have a different sun setting for each area? Bad news is that you can’t use different sky shaders in the same map without having the multiple suns affect each area of your map.

However, not sure what would happen if you set a light entity sun (using a point light targeting an info_null and setting the sun key/value pairs)… might work.

Other than that, move q3map_sunExt above q3map_lightmapFilterRadius. The lightmap filtering directive affects all light directives below it, and you don’ want sunExt to be filtered since it’s already properly “penumbra’ed”.

(Sub-Zero) #3

Oh ok. That is too bad. I will give the ‘light entity sun’ idea a shot and see what happens. Thanks for the other pointers as well. I read that in the docs but forgot to make the changes.

(Sub-Zero) #4

This bug is really placing a damper on things because I’m doing maintenance on some of the ra3maps and a lot of them use different suns for each arena. Is there any hope of it being fixed? I was desperate enough to spend a few hours with the source trying to fix it, but this issue requires more programming skill, source familiarity, and time than I have.

Basically I tried:

  1. adding a char array ‘shader’ to sun_t
  2. stored si->shader in sun->shader during the shaderfile parsing in shaders.c
  3. added a shaderInfo_t pointer to functions that either define/create suns (CreateSun() et al) and/or various functions that do the tracing.
  4. doing a strcmp() between si->shader and sun->shader and then only allowing sun tracing if they are the same.
    The end result is either wacky renders or I get no change, or no sun(s) at all.

Can anyone who is at least partially familiar with the source code point me in the right direction…or even a small patch? From what I can tell, this shouldn’t take a competent programmer who knows the source more than a few minutes to do. Any help in this area would be appreciated. :slight_smile:

(obsidian) #5

It’s not a bug, it’s a feature. :stuck_out_tongue:

Seriously though, how many environments do you have in real life where you have a different angle of sun projection by simply walking into the next room? In terms of implementing something like this, I really don’t think it’s that easy. Probably some form of lightmap localization depending on some kind of area marker is necessary, as well as some kind of localized lightmap occlusion. In other words, you will have to have some way of specifying the area which each sun affects.

Why not just use targeted pointlight to fake it? Should provide fairly close results.

(Sub-Zero) #6

Well, each arena is its own area and some of the maps have arenas with very different environments. They just happen to be in the same BSP. To me, it would make more sense to define multiple suns within a single sky shader than just having them all trace through every sky surface. This worked with the old compiler. I’d switch back to it but then I’d lose a bunch of other q3map2 features I’m currently depending on (like patchmeta).

I tried using a _sun light entity, but the effect is the same. It ‘shines’ globally through all the sky surfaces regardless. Using a regular light entity doesn’t seem to give really good results.