How do I stop light from leaking between brushes?


(PSIonic) #1

Hi all.

I’ve got a problem which I bet a lot of you have had at some stage!
I’ve got a building with a tower embedded in it at one end and the inside is completely hollow. For some reason light is leaking from the inside of the building around some of the corners.

Here is a screen to illustrate:

What is causing this to happen and how can I fix it?


(Loffy) #2

Maybe the walls are too thin? Try making the walls thicker. Other than that I have no idea what to do.
Loffy


(damocles) #3

If you can’t affoprd to make the connecting wall thicker to stop the light then the only other alternative there is to divide up the larger wall so that the edges of the new sections of the wall meet where the edges of the smaller brush connect to it.

If you remember that all lighting starts at the edges of the brushes and is then stretched across the surface of the walls, you’ll get an idea as to why the light is leaking through. Simply making two divisions where the thin wlal meets the big wall will stop the leak.


(PSIonic) #4

Ok I think I understand what you are both trying to say

Here is my interpretation:

Is that horozontal brush edge shown in red colour causing the light to leak through? If it is then could you recommend an alternative brush arrangement to get the same visual effect? The top left square brush is actually supposed to be a wooden support thing and I would prefer if it remained that shape because all 4 of its vertical sides become visible further down my structure.


(damocles) #5

Ok, to better explain…

Look at this extremely rough mock up of your situation…

You see the basiuc structure there and where the light leaks.

Now look at this with the main blocks selected. You can see how there is one huge face covering the area where the smaller brushes connect…

And here’s how to stop the light leaking…

You see how the new splits in the main brush run parallel (vertically) to the edges of the smaller brush? Because they share the same edges, you don’t get light leaking.


(Loffy) #6

Hi!
You have three objects here:
http://www.ssigvartsen.pwp.blueyonder.co.uk/WolfET/lightLeakProblem2.gif
Let’s name them 1 (top left), 2 (top right) and 3 (the biggest one, bottom).
My question has to do with 3. Is object 3 made by one brush (is it solid)? Or is object 3 a room, with walls?
If it is a room, then you can make the right wall thicker. Maybe that will stop the light from slipping through?
// L.

EDIT: Damocles reply (at 14:33) came while I was typing my silly suggestions above. Ignore my post. D’s ideas seems clear. I will try that trick myself.


(Hewster) #7

or, make the wall a func_group & give it a higher _lightmapscale
see this post (see Ydnars solution 3/4 way down page)
http://www.splashdamage.com/forums/viewtopic.php?t=604&highlight=leaking

Hewster


(joop sloop) #8

You should never have overlapping textures in the first place anyway so if you built that wall so you didn’t have overlapping textures your problem should be over…

never let a brush overlap other textures!


(damocles) #9

So you’re saying every wall you ever built has no overdraw whatsoever? Must take you bloody weeks just to make a single house framework. A wall with twi windows and doorway would be a pain in the ass to make without some overlapping.

There is such as thing as being too meticulous in your work.


(JIM_BOB7813) #10

What’s overdraw?

I’ve read about it is some tutorials, but never found out what it is. :lookaround:


(PSIonic) #11

yeah I’ve never heard that term before neither. Do you mean when you don’t use edge manipulation to make the end faces of 2 brushes that meet at 90 degree angle so that they touch at 45 degree angle?

Like:


|
|
| ____
| |

Instead of:


| |_______
| |
| |


(damocles) #12

Basically yeah. Overdraw is where one face of a brush has a portion of it that diesn’t get seen because another brush lays over it. It’s best to try and minimise this as much as possible. Partially for lighting issues and partially because older graphics cards that have to use 16-bit depth buffers may get strange artifacts along certain edges.


(G0-Gerbil) #13

Remember though that 2 intersecting brushes won’t cause overdraw if one of the faces is caulked.

One example of this is the outside corner edge of say a building.
Normal technique is to mitre both edges, but that’s actually not necessary as long as you caulk properly.


(damocles) #14

Think again. Caulk simply means that the face in question doesn’t get drawn. This doesn’t mean that there is no wall portion that is not obscured. It makes no difference to overdraw if you caulk the end of the wall section or not, it’s whether or not there is a portion of one wall that is obscured by another wall.

Example. Here’s a wall with overdraw. No amount of caulking will fix the area where the top wall is covered partially by the bottom wall…

Here are two examples on how to solve the problem:

If the wall will only ever be seen from inside the room you could do this:

If however the wall can be seen from both inside and outside, or only outside then you should mitre like this:

This will prevent overdraw and light leaking.


(Ricm!!!) #15

i have the same problem, i know it isnt the best way to repair it, but i use another texture instead of caulk to make the light dont pass the walls

sorry for my english :drink:


(PSIonic) #16

Ricm!!!, can you explain how you use another texture to stop the light a little more. Sounds interesting.

I have managed to nearly fix the problem spot I talked about earlier using Damocles’ method. I tried applying the same technique to another part of the map with the same problem, but it didn’t fix it. Here is a screen of what I did to the section in an attempt to stop the light leak:

The green entity box is the light source which is causing the light leak along the red area. The light leak is strongest in the redest areas on the screen and are actually ON the wall to the left of the red (not on the floor)

Damocles, isn’t this configuration supposed to fix the leak? Both the brushes whose faces are visible from the outside (top right section of the image) meet at the corner and have a common edge vertically like you talked about. I really can’t see how a light source in this position would cause such a light leak in any case, it must be related to light bouncing somehow.

Two more related questions too…

  1. Does the caulk texture block light?
  2. Does making a func_group and setting the lightmap resolution like ydnar suggested in that other topic increase the size of the .bsp file or does it simply take longer to run q3map2 -light on the map?

(G0-Gerbil) #17

It’s quite clear from your explanation you didn’t understand what I was saying. It’s not worth elaborating on so we’ll leave it at that :slight_smile:


(damocles) #18

You’re right, I misread the word intersecting. Although I apologise for misinterpreting your post - where the hell did it come from? We were talking about light leaking and overdraw, no-one mention intersecting brushes - which you should really avoid doing if possible. And intersecting brushes don’t create overdraw, they create zebra-ing - a nasty problem that no maop should ever suffer from - there really is no excuse dammit! back of the class and face the corner!! :smiley:

PSIonic:

Is that the only light source in the area? Are you forgetting about skylights? That light simply cannot be causing a light leak there because the face that has the leak is facing away from the light source.

And in the corner at the join you have a small mess of multiple brushes - is this for a texturing reason (eg the small brush is a wooden post or other peice of decoration)? If not, then you have misunderstood mitering. Mitering does not hjave to exist at 45 degree angles. It can exist at any angle just as long as you make sure the two ends of the walls are pressed against each other.

  1. Does the caulk texture block light?
  2. Does making a func_group and setting the lightmap resolution like ydnar suggested in that other topic increase the size of the .bsp file or does it simply take longer to run q3map2 -light on the map?

1 - no. If you need that feature, search the q3map forum, someone once posted a shader that nakes an invisible shadow brush (useful for entities and the like)

2 - yes and yes. Bigger and longer. No harmful injections. No visits to the doctor. No payments down! :slight_smile:

The main reason I didn’t suggest a lightmapscale group immediately is twofold - first for large walls like that a small lightscale resolution does make a lot more BSP size and compile time when you don’t need to. Second, if you have only one or two lightmapscale altered groups, then it becomes easy to spot them in game because the shadows are much finer compared to the rest of the level, and people may wonder why the whole level doesn’t have high detail shadows. Lightmapscale is a great trick if you use it well, but it’s one of those things where you should try it and see if it suits the problem first. Also, you have to be careful to make sure all the same alignment walls are in the group so one wall doesn’t suddenly go from fine to coarse shadows (very ugly effect).

Also, you may want to try simply grouping the two sections into seperate groups (one group for each wall) - apparently - although I have never tried this myself - q3map will look at groups differently during lighting and sometimes you can get rid of light leaks simply by using groups without any lightmapscale keys.


(PSIonic) #19

I managed to fix the second trouble area and guess what… it solution wasn’t to manipulate the walls I showed in my last screen. Instead it was a detail brush at the top of the wall which caused the problem.

Here a side view:

In the screen it’s the blue brush which caused the light leaking problem on the right hand side of the wall brush (tall one). I solved the leak by making the detail brush into a structural brush. The right hand surface of the blue (previously detail) brush where it touches the sloping brush is actually textured with the caulk texture.

I guess the mix of the fact that detail brushes don’t cause tris splits + the fact that caulk automatically caulks any surface it touches, caused the light leak.

Still it is odd how the light does a U-turn like you mentioned earlier, but removing the light did remove the leak when I had it. It must have something to do with the -bounce 8 switch I’m using to compile

Now I am going to return to the initial trouble spot and attempt to remove the minor light leak that remains! :disgust: