UE3 - UDK Ligght bleeding under wall

Light bleeding under wall

I'm trying to figure out why there is light emitting on the floor under the smaller wall? ..the wall with the red light behind it?
I'm just using a standard point light.
www.pyramid-of-wisdom.com/light_leek.jpg

www.pyramid-of-wisdom.com/light_leek2.jpg

Notice also that I have the walls snapped to the grid at the floor line:
www.pyramid-of-wisdom.com/light_leek_grid.jpg

The wall that has the light bleeding under it is perfectly seated to the floor and against the left room wall (with no gaps).
I've tried converting the BSB brush to a mesh.. (converted mesh not shown in the image) it didn't fixed the issue. Is there a property I need to set in the brush, or the light actor itself?

EDIT:

I found that if I make the wall really thick, it fixes the issue. I made it a 4 foot thick wall.
What if you're building a house with thinner walls, how do you set a thickness to block static light out?

EDIT2:

I was able to get closer to the results I needed by increasing the light mass resolution on the left wall texture and floor. ..and also building in production mode which took forever.
There's still some light getting though, but it's much better. I still don't understand why this happened. This wall was built in the UDK as a BSP brush and then I converted it to a mesh.
www.pyramid-of-wisdom.com/light_leek_better.jpg


I'm lost on what else to try.

Hi Wail of Suicide

yes, and it has a lightmass volume around the room. Lightmass is working well. It's bouncing as it should just enough to keep the back walls lit low.

But I think what's happening is, ...as someone at UDK explained. I need to make smaller floor plains for each room. As it is now, I have one large floor block ..much larger than the room. And it only has one face. So as a result I have to crank up the lightmass resolution on the texture of that block which is bad and makes for long building time. The light maps are not able to fill the large block at a low resolution.

On the other hand, if you needed a large floor, I suppose you could add more segments to the existing floor block, but I haven't tested it yet.
I've always understood lightmass to be based on grid units, not on the size of the face, or brush size. Thats another question.

Hi Wail of Suicide
Maybe I can get yours, or someone else theory on something.
I understand that lightmap pixels are drawn on the planar surfaces based on the resolution of your lightmap setting and also the size of your planar surfaces. Larger usually means you need a higher resolution. However, with the old days of vertex lighting, I remember how important it was to add more polygon faces to brushes to get proper lighting, especially on long brushes. Do you know if that theory applies to light mapping? Or does light mapping render according to the grid units ignoring the number of polygons on the surface?

Although light mapping is great for smaller rooms, it seems like it limits how large of a room you can make. Like if you wanted to make a stadium, that would be a problem. Although, if you had a super fast computer I suppose you could crank up the lightmap res on a planar surface floor to something like 1 lightmap pixel per every 2, ...or even 1 units.

Wail of Suicide said:

As for how the engine deals with lightmaps on large BSP surfaces ... Honestly I am not sure if lightmaps are done as fixed-size textures applied to a BSP surface or if the engine maintains a lightmap-pixel to unreal-unit ratio.

Click to expand...

Hiya Wail of Suicide
Check out post #13, Obihe does a great job explaining my last question. Me and him have been at this for some time.
I had mentioned to him that, "I noticed. On BSP brushes, a "smaller lightmap resolution number" results in a higher resolution and longer build times. However, it seems to be the opposite on meshes. So that's what he is talking about in the first sentience of his response in post #13, but then he explains what you and I were talking about here.

http://forums.epicgames.com/threads...-wall-onto-the-floor-Updated-screenshot/page2

.
.
.