vertex lighting bug?

(fraco) #1

hi,

following screenie taken from a dumb test map with vertex lighting on the wall:

there’s only one light in this scene and 4 brushes. Obviously, the lighting is weird.
I checked intensively for bad brushes, and I am finally convinced there are none (rebuilt every brush several times).

So I don’t really know what is happenning here. I’m guessing some wrong with vertex lighting. The weird lighting disappears when i replace the vertex lighting with a lightmap in the shader.

The simple test map can be found at: http://home.planetinternet.be/~froidcoe/vertexlight_err.zip. The zip includes the map and the shader for the vertex lit wall.

map was run in sof2. Compiled with q3map2 2.5.4:
(lighting stage) options -v -game sof2 -light -fast -filter -super 2
(ran from GTK)

regards

fraco

(onu) #2

Could you move the light somewhere else nearby and check it then?

(fraco) #3

I have been moving the ligth all over. Same results… Moving the brushes changes things.

fraco

(onu) #4

And this is a default SoF shader? Not custom?

(fraco) #5

it’s a stock raven shader. no messin around with it…

if you look at the way the wall gets split up in tris, things start making sense:

all those shadows run along the vertices and they all have an edge point right behind the little blocks. Which makes the vertex overly dark i believe. It still is weird lighting.

Problem comes from the fact that i split that wall brush exactly between the two little brushes in front. That triggers the compiler to cut the brush in more vertices than really necessary (fixing the t-junctions i read somewhere on these very forums)

fraco

(onu) #6

Well this makes the problem much more clear.

If you’re dealing with a small map set the “-notjunc” switch in q3map2, compile, and check it out then.

If that works then you may have to go edit the shader to include the “q3map_notjunc” declaration, and use that new shader in place of the stock one.

ydnar reccomends against using the notjunc switches and declarations, and for good reason. However, there are times when mapping where the standard practice just plain doesn’t work. In those cases one must choose to either redesign, or take an unorthodox approach to solving the problem.

Anyways, if the notjunc stuff doesn’t work by itself, try making a couple func_groups in there and setting them to detail (anything that doesn’t prevent a leak, anyways).