bsp -light with light-emitting skies

[wedge2211]

I'm now beginning work on a map for which the setting is an ancient city...so it's one, big, outdoor space. I used the yavin sky, ran a compile which took 2 minutes, and tried it out, but realized that skies/yavin does not emit light. So I made a new sahder document containing a shader code for a yavin_light sky, pasting the yavin sky code and adding the lines:

 

q3map_surfacelight 75

q3map_lightsubdivide 512

sun 1 1 1 100 90 65

 

[EDIT: I got those lines directly from another sky code.]

 

Now the sky emits light but compile time is up to 2 hours! Is there something wrong with that code? The full sky code is now

 

textures/city/yavin_light

{

qer_editorimage textures/city/yavin_up.jpg

q3map_surfacelight 75

q3map_lightsubdivide 512

sun 1 1 1 100 90 65

surfaceparm sky

surfaceparm noimpact

surfaceparm nomarks

notc

q3map_nolightmap

skyParms textures/city/yavin 512 -

}

 

Is there an error in there?

 

Another related question...I'd like to be able to split my city up into a couple vis areas, so frame rates aren't abominable. I think this would be done with hint brushes...how do those work? Do they just create a new VIS area where there wouldn't ordinarily be one, or do they do other funky stuff as well?

[Shadriss]

No, the shader code has nothing wrong with it. The problem is tht you are making it "one big area", ,one of the things that this engine absolutely HATES. My suggestion would be to design the level around the interior areas, and connect them in such a way that it APPEARS to be a big outdoor area, but isn't.

 

That build time is only going to get worse as time goes on and brushes are added into the map. Even if they were all detail, it's gonna get REAL ugly, REAL fast.

[wedge2211]

Couple questions:

 

(1) It's the light part of the compile that takes up 95% of the time. Wouldn't it be the VIS process that would hate large areas?

 

(2) If I restructure the level as you describe, won't it elimenate the ability to get on the roofs of buildings or see all the way across the city and such? Most of the buildings are only one or two stories tall, a level 3 force jump could make it to the top of plenty of them...

 

(3) Hint brushes?

[Leslie Judge]

(1) True. But with skies and the q3map_surfacelight the problem is that (as the name says) every surface you cover with the sky shader will emit light as any other light emitting surface. So the compiler has to calculate them all.

 

I'd like to suggest the using of q3map_skylight instead of q3map_surfacelight and the latest q3map2 but I'm not sure it will be faster to compile (for me it was definetely slower). What I'm sure that the result will be far better, something like radiosity (light will come from everywhere not from the surfaces you've used), and you can control how many times the light has to bounce.

 

Try both and use which fits your needs better.

[wedge2211]

So replace "q3map_surfacelight 75" with "q3map_skylight 75?" Or is the usage of that line different?

 

Also, some sky shaders use the line "q3map_sun x y z a b c" instead of just "sun x y z a b c." Is ther a difference there as well?

[wedge2211]

um, okay, just for the sake of experimentation, I commented out the q3map_surfacelight and q3map_lightsubdivide lines, and the thing compiled in under 2 minutes. The lighting still works in game, though a little less exact. I had to crank up the sun from 100 to 250 brightness and increase the elevation to noon in order to get rid of the much more pronounced shadows, but hey, it's good for test compiles at the very least.

[Leslie Judge]

q3map_skylight <amount> <bounces>

 

And yes, sun works fine with sof2map but Evader told me it doesn't with q3map2 (he has 2.3.32) for him. I always use q3map_sun.

[wedge2211]

I'm now using the lates version of Gtk and q3map (woo! me likey!). The shader code for ym skybox now looks like this:

 

textures/city/oceansky_light

{

qer_editorimage textures/city/oceansky_rt.jpg

q3map_skylight 75 2

q3map_lightsubdivide 512

q3map_sun 1 1 1 250 90 65

surfaceparm sky

surfaceparm noimpact

surfaceparm nomarks

notc

q3map_nolightmap

skyParms textures/city/oceansky 512 -

}

 

However, when I run a fast (q3map2) compile, the entire level is unlit, except for a few building interiors that I've put light ents in. The rest is black, with the exception of the sky itself. NOW what's my problem? My best guess is that there's something with the q3map_lightsubdivide line or I don't have a good number of bounces fromt he skylight. Any suggestions?

 

[Or, another thought, I know q3map2 does lighting a little less 'aggressively' than sof2map, do I just need to crank up the sunlight level a whole lot?]

 

thanks

[Leslie Judge]

q3map2 makes darker maps when fast lighting is used. But 75 for the amount is too small in the skylight I geuess. I used 300 and that was nearly enough. t depends on the sky texture since the average color of that is used to enlight the scene. You can control that if you include a q3map_lightimage <texture>. Then that picture will be averaged to calculate the light color.

 

BUT you have 250 for sun, so it should make some light anyway though it's directional not ambient as skylight appears.

[wedge2211]

Okay, hmm, I changed skylight to 300, and I have the same problem. When I run q3map2, the sky is visible (bright) but there is obviously no sunlight in the level, everything else that I haven't lit with light ents is black.

 

I ran a bsp (relight) 1/2 using sof2map, and it corrected the problem (cept for some reason the light is shining through patches, probably cause of the 1/2 lighting passes).

 

So it's looking like my final compile will have to be a sof2map one. Or a q3map one and a sof2map relight. Ick. I wish there was some other way to fix this...at least the compile is a decent time other than 2 hours.

[Leslie Judge]

You have q3map 2.3.32, right?

[wedge2211]

I have whichever came with the latest Gtk.

[Leslie Judge]

That's 2.3.32. I use the same and the skylight works well. The only difference is I set the bounce value to 6.

[wedge2211]

I changed the bounces to 6, and ran a q3map compile, I saw this in the light process output:

 

ERROR: textures/city/oceansky_light is not a shader, it's a texture.

--- CreateLights ---

8 point lights

0 spotlights

0 diffuse (area) lights

0 sun/sky lights

 

So it doesn't even think the sky light is there! sof2map registers it, so what's wrong with my sky code that q3map hates?

[Leslie Judge]

I can't see any errors. Weird. Oh, sof2map doesn't understand q3map_skylight.

 

Look, here's my sky shader:

 

textures/twoofakind/sky_golthancity

{

qer_editorimage textures/skies/sky.tga

q3map_skylight 500 6

q3map_lightsubdivide 512

q3map_sun 1.000000 1.000000 1.000000 250 350 50

surfaceparm sky

surfaceparm noimpact

surfaceparm nomarks

q3map_nolightmap

skyParms textures/twoofakind/env/golthancity 512 -

}

 

Can anyone see any differences? Except that I use TABs not spaces?

[wedge2211]

The tabs are killed by the message board.

 

Hmm. I copied my code from another sky shader. What's the "notc" line in mine do?

[Leslie Judge]

Probably disables Texture Compression for the shader.

[ydnar]

It's q3map_skylight <brightness> <iterations>

 

NOT bounces.

 

q3map_skylight 75 5 would produce over 50 sky lights. A value of 3 or 4 is better (and significantly faster). The former producing about 11 sky lights. Use higher values for smoother final compiles if you want, but we generally use 3 or 4.

 

If you use q3map_skylight instead of q3map_surfacelight, then you don't need q3map_lightsubdivide.

 

Example from one of my sky shaders:

 

q3map_skylight 75 3

q3map_sun 1 1 1 80 35 45

 

y

[Leslie Judge]

Thanx, ydnar. I don't know where I read bounces.