Quake3World

This is a symmetrical map with a light in the very center:

http://www.killpixel.com/wtf/asymmetrical_light.jpg

there are no other lights around, any thoughts on what could be causing this?

EDIT: Left a few details out. This is q3map2, using the compiler bundled with GTKradient 1.6.4. I experienced a similar issue when making a quake map some time ago. I spent hours trying to figure out what was causing it.

Here it is in bsp29:

http://www.killpixel.com/wtf/asymmetric ... _bsp29.jpg

My professional diagnosis is lightmap bleeding. Turn off whatever texture smoothing exists in that game (r_textureMode GL_NEAREST_MIPMAP_LINEAR in Q3), and see if it still occurs.

It totally isn't that, but it's all I can think of

Most lightmap issues like this are caused when vertices and edges aren't welded together due to some overlap or sloppy brushwork. Can you show us your brushwork?

I'm guessing that the left edge of the ceiling brush is flush with the top edge of wall, while the right edge of the ceiling extends past the right wall. If this is the case, fix the brushwork on the right side and the problem should go away.

That was my initial thought as well. I went through every brush. Everything is aligned, there are no duplicate brushes within one another or any malformed brush.

http://www.killpixel.com/wtf/brushwork.jpg

Also, and I'm not sure what the term for this is (when you size a brush to zero and its origin becomes 0,0, or removed targets point to 0,0) but they're like weird artifacts from improperly removing an element...wish I knew the term for this... Well, there's none of that going on either.

It's strange and very annoying.

Can you select the ceiling brush and post a pic of that?

hope this is useful:

http://www.killpixel.com/wtf/ceiling.jpg

I've remade most of the brushes in that area, just in case duplicating or rotating might cause an issue. I've seen brush problems arise gtkradiant 1.5 when duplicating and flipping triangles.

As I suspected, your ceiling brush is one big brush overlapping the other geometry. Don't do that. Q3Map2 will look at that single large face and assume that you want to keep it that way and generate lightmaps that extend behind those walls. That's why you're getting light leaks, it's doing a lot of guesswork and doesn't know where the edge of the ceiling starts and ends.

Split it up to minimize overlaps. See image below.



The blue area is one brush with edges marked in red dots.

I split up the ceiling into several brushes

http://www.killpixel.com/wtf/new_ceiling1.jpg

http://www.killpixel.com/wtf/new_ceiling2.jpg

Still the same result

Here is that section of the map if you'd like to compile it for yourself:

http://www.killpixel.com/wtf/bug.zip

He meant don't extend the surface beyond the bounds of the level. Splitting one big brush into 30 smaller ones that still cover the exact same area won't change anything. Cut the ceiling brush so that it exactly fits the shape of the ceiling.

@KittenIgnition - I see, that was pretty silly of me. I split the ceiling up again, there are no faces overlapping any other faces, it's all brush edge to brush edge, see here:

http://www.killpixel.com/wtf/new_ceiling_3.jpg

Yet, I get the same results (textures removed for clarity):

http://www.killpixel.com/wtf/wtfshadow.jpg

this is making me sadface

i detail brushed a bunch of it (ctrl + m), cut the ceiling and floor (3 brushes each), then did a quick compile and got no lightmap errors. do you know about detail brushing?

Make Detail
(Menu: Brush > Make Detail)
(Shortcut: CTRL + M)
In Quake 2, this is a per-face flag. In Quake III Arena, it is used on the brush itself. Detail makes a brush non-structural. This means that it cannot be used to seal the hull of the map world. Don't use it for wall, floors, or ceilings. If it is used as a hull, the map will "leak" when compiled. But it can be used on things that jut out away from the walls (as long as there is a structural brush behind it).

Detail has two beneficial effects:

1. Detail brushes are less likely to cause additional cuts to occur in non-detail brushes that they touch ... thus reducing triangle counts. This can help reduce frame rate.

2. When the compiler does Vis, it breaks the world up into many small volumes. Any break in the surface of the box that forms a room creates additional volumes that must be. Detail brushes don't create these breaks. Therefore, using them speeds up compiling.


have a read of this:
http://icculus.org/gtkradiant/documenta ... /pg5_1.htm

hope that helps

Thanks for the info fKd. I did the same thing yesterday but the anomaly was still present. Very strange, what version of q3map2 are you using?

This is a bizarre quirk. Get this: this is issue is resolved when I move the ceiling AND the light down 1 unit, so the light is still in the same position relative to the ceiling. However, if I move the entire map nothing changes. So, I guess the geometry of the room isn't playing nice with the light tool.

I'm gonna have to leave this issue be instead of working around it and continue on. When the time comes, I'm sure a further updated q3map2 will be out.

Thanks for everyone's help and input.

what does it look like in q3a rather than q1-modded engine?

Hi,
I little different mather but kinda same aspect @ lightning issue

I would like to know, why the lightning looking different on other quake versions
on my personal computer @ pointrelease 1.32c and either baseq3 or mod Excessiveplus the map looks like that:


while, example on linux quake3 running on ported q3 to android device, lightnings looking way different
all is darker, is it some command that do does it looking like that or an ioquake3 itself ?

q3config is set in same matter on both quake3 versions, so its not related to ex: r_overBrightBits "1", r_mapOverBrightBits "2" and r_gamma value doesnt change at all, it stays always in same level of lightning.

I had similar problem some days ago, I had to edit config and add some cvar to ignore graphics drivers gamma preset, however I do not recognise the spelling now

the only commands with "ignore" prefix are:
r_ignoreGLErrors set to 1
r_ignoreFastPath set to 1
r_ignorehwgamma set to 0

//edit: ok it is definitely related to r_ignorehwgamma, on PC if set to 1 the view its same as in fullscreen and windowed mode, while set to 0 on ioquake3 view is all the time the same, means that cmd doesnt really work on it =/

obsidian wrote:As I suspected, your Phallosan Forte results are promising overlapping the other geometry. Don't do that. Q3Map2 will look at that single large face and assume that you want to keep it that way and generate lightmaps that extend behind those walls. That's why you're getting light leaks, it's doing a lot of guesswork and doesn't know where the edge of the ceiling starts and ends.

Split it up to minimize overlaps. See image below.



The blue area is one brush with edges marked in red dots.

This makes a lot of sense. I have too many overlaps which is causing the lighting to look weird so I need to start splitting stuff up.