Disorted Shadows

(Infernis) #1

I’ve been messing around with some of Q3map2 it’s new features to create some cool stuff. I’m using a skybox I downloaded from the Internet but it looked really plain so I decided to update it a bit.

The original shader was:

textures/harlequin_sky/jf-nebula_sky
{
qer_editorimage textures/harlequin_sky/nebula_qer1.tga
surfaceparm sky
surfaceparm noimpact
surfaceparm nolightmap
surfaceparm nomarks
q3map_surfacelight 50
q3map_sun 1 .98 .9 100 0 90
skyparms textures/harlequin_sky/env/nebular - -
}

The new shader is:

textures/inf_sky_nebula/nebula_qer1
{
qer_editorimage textures/inf_sky_nebula/nebula_qer1.tga
surfaceparm sky
surfaceparm noimpact
surfaceparm nolightmap
surfaceparm nomarks
q3map_sunExt 1 1 1 200 0 20 2 12
q3map_skyLight 100 8
skyparms textures/inf_sky_nebula/env/nebular - -
}

Now I’ve made a little test map to see how the shadows would look like ingame. They look good on the ground floor, but when a shadow hits another object it looks disorted in some places while the rest looks good. Here’s a little example shot.

My questions:

What causes that ?
How do I fix it ?

Also, while making the example shot I noticed that I had some warnings in the console. I have no idea what it means though. Any thoughts would be appreciated. Here’s the log:

WARNING: reused image textures/inf_sky_nebula/env/nebular_rt.tga with mixed
glWrapClampMode parm
WARNING: reused image textures/inf_sky_nebula/env/nebular_bk.tga with mixed
glWrapClampMode parm
WARNING: reused image textures/inf_sky_nebula/env/nebular_lf.tga with mixed
glWrapClampMode parm
WARNING: reused image textures/inf_sky_nebula/env/nebular_ft.tga with mixed
glWrapClampMode parm
WARNING: reused image textures/inf_sky_nebula/env/nebular_up.tga with mixed
glWrapClampMode parm
WARNING: reused image textures/inf_sky_nebula/env/nebular_dn.tga with mixed
glWrapClampMode parm

Thanks

(Fracman) #2

try -skyfix parameter for q3map2 compile

(Infernis) #3

That doesn’t work. There are no apparent changes which I heared more people complain about. I was looking for a thread which explained what was wrong, but I can’t find it ATM.

(Fracman) #4

the -skyfix is only for this glwrap problem i guess
about the steps in the shadow problem, search for “strange shadow” or “shadow steps”

(ratty redemption) #5

hi infernis,

regarding the blocky shadows, you could try changing the last 2 values of the q3map_sunext to 3 and 16, which is the deviance and samples values I use in et and ja mapping.

and the last value of q3map_skylight is iterations, which I use between 3 and 6 depending on the quality vs speed I need when compiling, same goes with the other two values, the lower they are the faster q3map2 compiles.

the gl errors shouldnt affect the lighting, iirc its just the engine complaining of shaders using different types of texture clamping, when sharing the same images.

but I don`t think the results would look any different in game, then if you used identical looking images with different file names in the shaders, although that might remove that console error.

ratty disclaimer: I`m a tad rusty with q3 engine shaders so those last 2 paragraphs could be completely wrong :wink:

(Infernis) #6

Fracman: I did an extensive search and read a lot of topics but I didn’t find a single one mentioning the same problem. Enough stuff about shadows, only not in this context.

Ratty: I tried you’re suggestions but it didn’t create any apparent changes ingame.

I’m kinda stuck at this point, perhaps I could post the skybox in it’s current state here ? That is, if someone is willing to take a look at it ?

Thanks for the suggestions so far.

(Fracman) #7

Try this one in the sky shader:

q3map_lightmapFilterRadius 0 8

If it still doesn’t work, pls post a zip with your current skybox + shader + textures

(megaman) #8

uhm, this looks just like a low lightmap resolution does…

(obsidian) #9

Lightmaps are just textures generated by Q3Map2 so they may become noticeably pixilated when projected in non-axial angles, since luxels are square and shadows are not. There are several methods to help compensate for this:

A parallel light source like a sun (red arrow) casts a shadow (grey) behind a square box (black). Since the direction of light is axial, it lines up with the lightmap luxels. Looks fine, but boring.

To make things interesting, we usually shift our lightsources to a different angle. Looks more interesting, but causes lightmap jaggies.

One way of fixing this is to decrease the luxel size using q3map_lightmapSampleSize. Problem is that this increases the lightmap resolution and therefore also the amount of lightmap data, resulting in decreased performance.

Another method is using q3map_sunExt and q3map_skylight on sky shaders. The skylight iterations value creates a finer array of light samples around the sky hemisphere. Typically, I use iteration values of 3 to 6. The sunExt deviance value sets the angle of “jittering” which softens the edges of shadow and simulates radiosity created by penumbra effects. The number of samples increase the number of jitters - setting this to higher numbers (~16) yields softer shadows.

q3map_lightmapFilterRadius creates a gaussian blur filter across the lightmap, resulting in softer shadows at the expense of precision (resulting in blurry shadows). Its primary purpose was to prevent the “stadium” lighting effect caused as a by-product of low skylight iteration values. If you use higher skylight iteration values, you may not need this at all. lightmapFilterRadius is order dependent so it affects the directive directly below it on the shader. So if you’re using this, your directives should be listed in the following order:

  • q3map_sunExt
  • q3map_lightmapFilterRadius
  • q3map_skylight

Read this:

Shader Manual: Appendix I - Light Emitting Shaders
http://www.shaderlab.com/q3map2/shader_manual/apI.html

Shader Lighting Experiment
http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20040311-6-027331.html

(Infernis) #10

Great stuff guys, I’ll get right to it when I get back from work. I’ll be sure to post the results here.

Thanks a lot !!!

(Infernis) #11

Forgot to wrap this one up. Your suggestions are really usefull and I learned a lot. It’s resolved, but I found out later that I wasn’t using the latest Q3map2 build. So that’s what caused the problems in the first placed.

For anyone reading this, the combination of these shaderlines fixed everything for me:

  • q3map_sunExt
  • q3map_lightmapFilterRadius
  • q3map_skylight
(obsidian) #12

As mentioned above, q3map_lightmapFilterRadius may not be necessary, depending on your settings. For final compiles, I tend to omit it in favour for higher iteration and sample values for maximum quality. Personally, I only use lightmap filtering for test compiles with lower iteration values in favour for faster compile times or when I still get the stadium lighting effect.

BTW, I also noticed that the “other” parameter of lightmap filtering doesn’t work when it is added to the shader of surfacelights. It seems to only work for sun light-emitting shaders and lightmapped shaders flagged with the “self” value. Possibly a bug, or limitation?