multiple shadows from unknown light source

(wily duck) #1

I’m trying to figure out how it’s possible that this has occured:

That shadow doesn’t appear to be ray-traced, because it’s blobular and jagged. There’s a shadow like this all around the building including underneath the correct shadow (I verfied this by moving the sun).

Here’s my shader for the skybox:


textures/superman/duck_supermansky
{
	qer_editorimage textures/superman/daysky_ft.tga
	surfaceparm noimpact
	surfaceparm nomarks
	surfaceparm nolightmap
	surfaceparm sky
	q3map_sun .95 .85 .9 125 300 82
	q3map_globaltexture
	q3map_lightsubdivide 512
	skyparms env/wilyduck/daysky - -
}

It doesn’t make any sense. I renamed the shader a couple times to make sure there were no conflictions.

Compiling with -light -fast.

What’s happening? Am I doing something wrong?

(obsidian) #2

Are you sure you don’t have any other light sources - point/spot/surface lights?

I don’t think you need q3map_globalTexture.

These may/may not solve your problem but at least your shadows will look better and possibly a faster compile:
-Get rid of q3map_lightSubdivide and use q3map_skyLight instead (with values ~ 300 6).
-You may also want to use q3map_sunExt 0.95 0.85 0.9 125 300 82 3 16 instead of q3map_sun
-For more info, see these links:
Q3Map2 Shader Manual Appendix I
Shader Lighting Experiment

(wily duck) #3

Interesting new switches… The lighting in the map has changed dramatically, but the funky shadows are still there (although much harder to see). Thanks for the shader manual link, surprisingly, I have gone looking for something like that and never found it. Any other ideas on the wierd shadow?

(ydnar) #4

Do the shadows still appear if you change the sun angle by 90 degrees or more?

Like obsidian suggested, you should replace the sun with sunExt and use q3map_skyLight for good global illumination of your outdoor areas. That, and nuke any ambient light in the map. You might want to try this sky as a template:

http://shaderlab.com/q3map2/samples/shaderlab_1337.zip

y

(wily duck) #5

Ok, I moved the sun -100 degrees, and reduced the verticle angle from 82 to 60, and no more weird shadows. Here’s what I tried in order from first adding q3map_sunext

q3map_sunExt 0.95 0.85 0.9 200 300 82 3 16
q3map_skylight 150 3

light shadows, well lit areas, long compile

q3map_sunExt 0.95 0.85 0.9 200 300 82 1 4
q3map_skylight 50 2

darker shadows

q3map_sunExt 0.95 0.85 0.9 200 300 82 1 4

// q3map_skylight 50 2
fast compile

q3map_sunExt 0.95 0.85 0.9 200 200 60 1 4

// q3map_skylight 50 2
rotated sun -100 degrees, functioning shadows with no mystery shadows, i.e. it works (except that the sun is in the wrong spot now)

I don’t understand…

(ydnar) #6

You still want to compile with q3map_skyLight.

What version of Q3Map2 are you using?

(wily duck) #7

ah sorry for not including that… 2.5.14

for test/debug, I’d rather keep q3map_skylight out, as it takes 19 minutes to compile ( q3map_skylight 150 3 ), rather than 2 minutes without. I ran out of time last night when writing a response… here’s a screenshot of the working shader:

Moving all around the central building shows no sign of the wierd shadow problem.

Thanks again
-wily duck

(ydnar) #8

19 minutes? Uh.

What CPU and OS are you running, and what -light options are you using?

y

(wily duck) #9

running winxp, amd2000, 1 gig pc2100

with just “-light fast”, -light takes 2 minutes tops (it’s a big map as you see)

btw one off-topic question quick, in your q3 map ishii, what anime is that? neat map.

(ydnar) #10

It’s a video for Ken Ishii’s track “Extra.”

(wily duck) #11

Here’s the most recent pic, with shader and compile info:

q3map_sunExt 0.95 0.85 0.9 200 40 78 .5 2
q3map_skylight 100 3

compiled with:
bsp_Q3Map2: (single) -light -fast -super 2 -filter -bounce 8

took 2 hours to compile, but whatever. The point is that there’s that one shadow that’s crossing over the overpass which doesn’t belong to anything. Since I’ve changed the sun angles slightly, the other shadows have disappeared. I’m trying to keep about this sun angle for the map’s purposes… any more ideas?

Does worldspawn key _blocksize have anything to do with it? Or is that strictly -vis? It’s set to 2048 for now.

ydnar I know you’ve been primarily helping out, and I do appreciate it. Thanks again.

(wily duck) #12

Here’s something I’ve seen in the -light stage for a while, never thought about it though…

WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 0.7909 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 0.5000 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 1.0818 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 1.3727 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 1.9545 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 1.3727 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 0.5000 >
3
WARNING: Lightmap texture coords out of range: S 126.1727 > 126 || T 1.2273 >
3

The actual printout is about 3-4 times longer. Could this have any relation to the problem?

-duck

(ydnar) #13

Degenerate patch meshes. Check to see if you’ve capped any patches.

Also, you can speed up the compile significantly if you use -samples 2 instead of -super 2. The quality is the same, except -samples uses smart antialiasing, only on shadow edges. Also, don’t use -filter, as that blurs shadows.

I assume you’re using -patchshadows?

y