Different shadows on brushes and patches?

(Krischan) #1

Hi, I have a big problem with the lighting on my map and hope that somebody can explain me what is wrong here. Take a look at these Screenshots:







(compiled with vis, light, fast, filter, samples, bounce 8, patchshadows). The lights are nonlinear with 250 value.

It seems to be that the patches I used are lighted/shadowed competely different than my brushes and I don’t know why. The screenshots above are locations, where a brush meets a patch. I noticed that in my Radiant if i turn off OpenGL Lighting I can see a gamma difference between the patches and the brushes, take a look at this:

On the left hand there is a patch group, right beside a brush group and upper left again a patch group. The brush group is more lit than the patch group, why? The textures are used on patches and brushes, too. Even changing them or changing to a different sky shader it makes no difference. The Map is 12288x12288 with a gridsize of 256 256 512 (didn’t touch this, came from easygen).

I tried every single compile option from radiant, updated q3map2 to 2.5.16 but nothing helped. The only “workaround” that seem to work is to turn all brushes into patches, ex. a square cylinder, but this makes no sense to me :frowning:

What did I do wrong?

(kamikazee) #2

IIRC, patches are vertex lit whilst brushes are lightmapped. Q3map2 then generates correct information for the brushes, but the patches smear out the lighting all over them.
I’d sugest to change the patches so that they’re not in areas where you need shadows. Like in the 3rd abd 5th picture, dont make the patches any longer then you need to make them close the curve. I’d even use a brush as floor, and caulk the walls behind the curved wall.
Especially in the last picture, why do you need a patch group there? I’d say it’s a perfeclty flat surface

Other note about the last picture: Radiant has a special method of lighting and is only a preview. Best is to look at the results in ET.

(Detoeni) #3

patches are vertex lit …

no they ant, unless your shader is vertex based

Krischan: the compile options your using in light clash “filter, samples”. samples needs a value of 2 and loss the filter bit, you should compile with bsp first with “meta”.

(Krischan) #4

Thanks for the quick replies.

@kamikazee: I can’t change the patches without redesigning my whole bridge. I really need a patch there b/c the bridge raises a little bit to the middle (and it raised curved, not linear) so that you can’t see somebody standing at the other end, btw the bridge is a replica of a real bridge and I want it realistic :slight_smile: Here is a better shot from radiant to show the problem:

Here you can clearly see what is a patch and what is a brush. Sure the rendering in ET is better than in Radiant but why does it show the patches lit different? I think this is a key to solve my problem.

@Detoeni: normally I first use a single -meta compile to check the geometry and to find brush leaks or so. If everything is ok I do a -vis and a -light -faster to get a feeling for the lights. If it looks fine I compile it completely. I didn’t change the Radiant settings and always use for the full compile stage the “bsp_Q3Map2: (final) BSP -meta, -vis, -light -fast -filter -samples 2 -bounce 8”, just added the -patchshadows b/c they didn’t cast a shadow which looks weird.

For the textures I use this shader syntax, but even if I use standard ET textures it makes no difference at all:

textures/test/stone
{
qer_editorimage textures/test/stone.jpg
q3map_normalimage textures/test/stone_bump.jpg

{
map $lightmap
rgbGen identity
}

{
map textures/test/stone.jpg
blendFunc GL_DST_COLOR GL_ZERO
rgbgen identity
}

}

The bump is a normal image of the texture made with the nvtools NormalMapFilter. If it helps I can send you a PK3 with the current project. I am totally stuck and stopped all work until I know what I am doing wrong here. :banghead:

Edit: The middle part of the bridge will be a constructible so i needed to divide the bridge into several parts.

(Detoeni) #5

Filter blurs lightmaps, samples sharpens. who ever added both of them options to rad needs a kick up the …
Anyhow, trying to added bump mapping to stutch is not going to work, adding bump mapping with out understanding how and where it works is more hassel than its worth, lose it from the brickwork. Don’t worry about how it looks in rad.

There are number of diffirent ways to set up the compiler, see here: http://www.wolfensteinx.com/surface/forums/showthread.php?s=&threadid=1301

(Shaderman) #6

You’ll get better results for bump mapping when using TGA instead of JPG images.

Btw are you building the same bridge I did a while ago? :eek:

(Krischan) #7

@Detoeni: ok I am using the Q3map2 Toolz now, this frontend makes more sense than the radiant-built in ever did :clap: it is still calculating the lightmap :wink:

@Shaderman: well this looks quite similar. I am reconstructing the old city of Frankfurt/Main, Germany in 1945. This is the “Alte Brücke” (old bridge) - additional there is a second bridge looking even more realistic, the “Eiserner Steg” (iron bridge). Still no houses and ruins, I am stuck now at the infrastructure stage now (streets, bridges).

Take a look:



The texturing of this bridge was very complicated, I did the texture by myself and it looks fine now. To get it more realistic I thought I should use bumpmapping but as Detoeni already said I still don’t understand the shaders completely. In final stage the map will contain a moving tank, a mortar battery, tank barriers, three different churches including the cathedral, the townhall and a heavy bombed old city like it was back in 1945. Much work ahead but right now I am fighting with these ridiculous problems :angry:

(Shaderman) #8

Same here, but in Heidelberg/Germany :slight_smile:

The pics of the other bridge look good (screenshots are too dark though) but I wonder if you don’t have fps trouble in a large map like this.

(Krischan) #9

Oh yes, Heidelberg has a “Alte Brücke” too :slight_smile: No I don’t think that I’ll get FPS problems, the map isn’t that large, I compared the sizes, it is about 1/3 smaller than Fueldump (outdoor, too) and I use fogclip at 4000 Units so the FPS are nearly constant at 100FPS here on my Notebook (Pentium M 1.7GHZ with Ati X600). I tried it once on my Desktop (3.2GHz, Radeon 9800) and reached 250FPS+. So there is much room for more brushwork :slight_smile: And the map isn’t tuned for FPS right now. By now, I only used 3000 Brushes and many of them are used by terrain.

But I still don’t get it why the lighting goes so bad. It looks like the lightgrid “stops” suddenly at some locations. Any more ideas to solve this problem?

(obsidian) #10

Don’t pay any attention to the Radiant lighting, it’s not at all a representation of ingame lighting.

Make sure you add caulk behind light blocking patches. Helps seal off light leaks and other patch artifacts.

Try compiling with -meta and maybe -patchmeta.

Just a guess, but it may have something to do with smoothing.

(Krischan) #11

OK, I don’t care anymore about the Radiant lighting, I think it is a feature to see what is a patch and what a brush :beer: Yesterday I noticed that hanging the lights closer to the surface, to brighten up the patch/brush neighbours, the strange shadows disappear, but the area is very lit then. Oh and rendering with “-super 2” without patchshadows looks better. It seems to be a problem with the half-shadows (the outer radius of the light), the core light radius close to the surface works. I will rearrange my lights to see if it solves the problem, not quite a solution but a workaround I could live with :moo: