Shadow Blending problem

(Disgruntled Goat) #1

Hey guys,

I am having a little trouble with terrain blending below models which are creating shade. This causes the brush seam to show, not so purty. Here is exhibit A:

Here is the shader I am using for the blending in this section:

textures/common/isignydirt
{
qer_editorimage textures/pop_ground/dirtalpha.tga
q3map_shadeangle 179
q3map_nonplanar
q3map_forcemeta
surfaceparm grasssteps
{
map textures/pop_ground/dirtalpha.tga
rgbGen identity
}
{
map textures/temperate_sd/grass_dense1.tga
blendfunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
rgbGen identity
alphaGen vertex
}
{
map $lightmap
blendFunc GL_DST_COLOR GL_ZERO
rgbGen identity
tcGen lightmap
}
}

Any ideas? I am wondering if the _shadeangle is the problem. Thanks a lot,

(Mr_Tickles) #2

Hmmm, the shadeangle is good, as is the nonplanar as far as i’m aware. Try in Radiant selecting the road brushes which have the shadow cast on them and add in these keys/values :

Key: lightmapscale Value: 5

not sure if that will work, I can’t check if the lightmapscale has an underscore or not as i’m not at home and haven’t played with it for a while, so it could be

Key _lightmapscale Value: 5

I think it does have the underscore, but not sure. Try different values for it, not just 5 as i’m unsure how large/small you need it. I think having a low value e.g. 0.03 would result in sharper shadows and higher like 5 (or more) would give less sharp shadows.

I say again, i’m not sure if this will work though, sorry :S

(WolfWings) #3

You might try adding q3map_lightmapMergable to the shader as well.

(Codja X) #4

It’s definitely with the underscore, so it would be: _lightmapscale

(kat) #5

I’ve just had a similar probalem, try using q3map_lightmapSampleOffset 8 that fixed it for me.

(Disgruntled Goat) #6

Hey guys,

Thanks for the ideas. The lightmapmergable key helped some of the instances of shadow misalignment in the map while others are still being cranky and hanging around. I tried the q3map_lightmapSampleOffset 8 to no avail. What exactly is it changing if I mess around with the value some (I am assuming in multiples of 2). Thanks again…

(kat) #7 
 q3map_lightmapSampleOffset distance 

Takes a single parameter, defaulting to 1.0, which specifies how many units off a surface should Q3Map2 sample lighting from. Use larger values (2.0-8.0) if you're getting ugly splotches on lightmapped terrain.

my understanding of this is that it tells q3map2 to sample pixels ‘outside’ the default brush area it normally looked at, so any given surface is expanded slightly, in terms of how q3map2 looks at it, by ‘X’ units. It’s a bit like telling q3map2 to look at the neighbouring pixels and use (include) those to calculate the averages for the lightmap.

taken from the shader manual
http://shaderlab.com/q3map2/shader_manual/ch3.html#lightmapsampleoffset

(WolfWings) #8

Not quite. q3map_lightmapSampleOffset only says how far ABOVE the surface to sample the light for the surface. I.E. If you have a wierd ‘seam’ showing where two brushes meet, increase that setting to move the sampling point ‘above’ the seam, and the lighting will fix itself.

In this case, it’s a matter of lightmap boundaries are being lit differently. I’d recommend making sure you’re only getting one lightmap for the entire terrain, if possible. If need-be, set the q3map_lightmapSize for the terrain shader to 1024x1024, assuming you’re mapping for Enemy Territory or something else with built-in support for external lightmaps. Alternatively, increase your q3map_lightmapSampleSize.

(Codja X) #9

can you use the q3map_lightmapSampleOffset property as a key on a func group like _lightmapscale?

E.g. when binding some brushes to a func_group, can you add a _lightmapSampleOffset key it?

(Disgruntled Goat) #10

Thanks for all the help guys, a combination of _lightmapsampleoffset and _lightmapMergable took care of the problem. Cheers! :clap:

(ratty redemption) #11

cool and what value did you use in the end for _lightmapsampleoffset?

(Disgruntled Goat) #12

For the _lightmapsampleoffset value, I initially had it at 8 but with no effect. I jacked it up to 32 and it came out perfect, no seam lines. I probably would have been able to get away with a smaller value but you know, if it ain’t broke… hehe

Just for comparison, here is the after picture of the same chunk of real estate:

(ratty redemption) #13

cool, and I just wasnt sure how far off a surface it could sample... I cant remember if I asked ydnar this in the past, but at least we know 32 units works :slight_smile:

if there is no limit, then I guess past a certain sample distance the resulting lightmap would start to look wrong, with shadows or lights appearing that we wouldn`t expect, ie they should ‘belong’ to surfaces on the opposite end of the sample distance?

(ydnar) #14

BTW, if you’re using -filter in the compile phase, then don’t.

The -filter switch blurs across surface lightmaps, but can’t handle seams/joints between surfaces. It destroys the nice alphashadows from the plants, too.

Also, don’t use _lightmapscale > 1.0 if you’re trying to get better shadows, that will only exacerbate the problem by increasing the sample size, thus reducing the apparent resolution of the lightmaps.

(ratty redemption) #15

@ydnar, I use -filter, are you saying don`t use _lightmapsampleoffset with it?

(WolfWings) #16

No, ydnar is saying the same thing he’s been saying for months now.

Don’t use -filter.

Period. Full stop. End transmission. It causes seams in the lightmaps to be visible, because it can’t blend across lightmap-mapping boundaries, so the borders between lightmaps end up incorrect in many cases when -filter is used.

(ratty redemption) #17

k, I understand that, but the alternative, -samples seems too blocky to me, even with a value of 3, does it even go any higher?

(WolfWings) #18

-samples only increases the number of samples used to determine each point on the lightmap. Basically it’s like rendering a higher-resolution lightmap, then scaling it down. It doesn’t increase the final of the lightmap, only the ‘resolution’ of the source image, a lot like building a command map from a 1024x1024 base tracemap. -filter can ‘hide’ blocky areas, like sharp shadow points, because it lowers the contrast between them, making the blocky edge less noticable, but still very much there. But, because of how it ‘breaks’ on the boundaries between lightmaps, it’s use is HEAVILLY depreciated.

q3map_lightmapFilterRadius might be more appropriate to add to the light-emitting shader that’s causing the “blocky” shadow. If it’s a point or spot light, set the _deviance and _samples keys, the former being the number of game units to vary the position of the light between each sample taken. If it’s a skylight, go here.

Honestly, I’d rather ydnar make q3map2 generate an error if -filter is used, explaining to use the q3map_lightmapFilterRadius/_deviance+_samples solutions on the SOURCE of the jagged shadows, instead of trying to ‘fix’ the jagged shadows with a blur filter.

(ratty redemption) #19

@WolfWings, that makes a lot of sense to me now, and I do like the deviance, samples on q3map_sunext, so I will try to use this approach with other light sources :slight_smile: