Ok Light Leaks and Missing faces hand in hand

#1 TGErad interior lighting is this still a good thing to try and use and is there one for TSE and TGE and were can I get it?

#2 And when you make the geometry smaller and the light smaller I get green outlines of where the faces are cut up at..

#3 Do any one know if there is a plan to up the restriction of light map size so it isn't 256 X 256

#4 Are you sure you need to change light_geometry_scale to fix light leaks? it may just be a problem with how you constructed your interior.

#5 Yes.. that is the only way the map2dif gets read of them.. unless you build a power of 2 geometry building (not very robust)

tdn.garagegames.com/wiki/DIF/dif_lighting

#6 It behaves like this:

____ <- external platform
| ___
| |! <- inside wall

The ! is where the light would leak in for me. The external platform is like a big slab and the inside wall is maybe 1 or 2 units away from it's edge. What would happen is the light map would be generated for the brush that is the slab and when the light_geometry_scale is set too high the light map does not have enough pixels to accomodate the brush and the light will "bleed" under the wall.

When I bumped the light_geometry_scale down (and left the other geometry value alone) the light leaks started to go away. The reason this happened is there were more pixels for the light map and the lighted side of the brush stayed outside my edge and the unlighted portion stayed inside. I used a scale of 4.0 if you were wondering.

I would guess another way to reduce this issue is to not use huge brushes. This will help in the specific case I outlined but may not help when you have a brush wall meeting another brush wall at a 90 degree junction. This could still allow a light bleed into the interior where it shouldn't be.

I guess the short of it is - try using smaller brushes (longer brushes could be broken up into multiple smaller ones) and try gradually setting your light_geometry_scale lower and lower until it goes away.

#7 That is fine but then I will get missing faces. My building is not square.

thanks for the reply.

#8 Some solutions here: www.garagegames.com/mg/forums/result.thread.php?qt=23378

#9 I have read it many times over.. not going to get in a do this do that discussion again. I still stand by that map2dif needs to be redone and done right (no I am not a programmer and don't know how hard it is to make something like this) it should not make life harder to make levels and it does more damage than it should.. I could spend days just getting one room to zone out right you shouldn't have to do little tweaks to get it to work, and large map files almost become impossible to build and fix.. bla bla bla old record. I am just an artist that would like life to be simpler and should be and I think many people would agree with me on this. If people knew how hard it would be to do a proper interiors in torque they may skip and move on to the next engine.

Thanks for the help.

#10 I don't see the map2difplus changing any time soon. I've been complaining about it ever since the 1.5 wouldn't compile on the Mac. Of course, the standard answer is - wait for constructor - it will be fixed in there. So get out your wallets... the bug will be fixed by spending more money.

Until then... you can try making some simple buildings to reproduce your issue. It might help to simplify it to understand what's really happening to those faces (my apology for not addressing this at the beginning!) I'm sorry - I don't have a good answer for you but it's the same method I used in solving my ridiculous light leak problem.

#11 Thanks.. for the help Joe wasn't trying to bitch at any one just frustrating that you have to do the little things to files that end up taking longer than they should to build just so they work right.

#12 As far as I can tell the geometry scale is only used to change the interior's size before bringing it into the engine. You shouldn't change the geometry scale to eliminate light leaks. I know that large brushes throw > 256x256 errors in map2dif when using lower lighting scales, but the solution is to break those brushes into smaller pieces.


Here's a quick explanation of whats happening and how the scales relate:

Light leaks occur when the lighting scale is too high relative to the thickness of the brushes used (ie: thin brushes do not cover the gap between light map lexels (lexel == light map pixel)) then during rendering (because of texture filtering) lighting from adjacent lexels leaks out from under surfaces. This is common to all light mapping. Thicker brushes (relative to the lighting scale) reduce or eliminate light leaks by spanning the entire area between two or multiple lexels.


There are two ways to increase the thickness of brushes relative to the lighting scale; increase the thickness of brushes that are causing light leaks, and/or decrease the lighting scale (which makes the world distance between lexels smaller). Usually a combination of the two works best; decrease the light scale a bit and tweak the last few offending brushes.


If you run into "> 256x256" errors in map2dif then split large brushes into smaller pieces - do not decrease the geometry scale. Because light leaking is eliminated by increasing the geometry size relative to the lighting scale, reducing the geometry scale, which reduces the geometry size, only puts things back to where they were, reintroducing the problem. Even worse reducing the geometry scale eliminates brush precision causing small faces and brushes to be removed (just like when creating too small geometry with the default geometry scale).


Joe - Constructor uses code similar to map2dif(+), the issues with missing faces (at least in this case) are due to the geometry scale.

#13 I knew that i was going to get in another discussion and didn't want to but.. I am just saying that if they know were the problem is like you explained than why can't it get fixed it would just make for a better engine / tools. I am building at scale building and I don't have the luxury of making brushes larger or smaller I have a CAD drawing and I am making it as close to the measurements as I can and that is why I say that map2dif is broken for you can't build correctly with it. Thanks again for your explanation but it just don't help me in completing my building in a short amount of time like it should instead I am doing half @$$ tweaks there and there to get things to work right and as a production aspect that isn't good and turns great tools into just another tool so why would any one want to pay for Constructor if you are still going to have the same problems as before with map2dif.. it is map2dif that is going to make Constructor suck and that sucks for it is going to be a great tool..

#14 It's not that there are known issues with map2dif (at least regarding what I mentioned above) or the engine - light leaking is a function of light mapping, and occurs in all light mapping solutions in one form or another.

The 256x256 light map size limit is used to keep TGE running and performing well on all hardware including older video cards.

I've seen the interior you're trying to build (if it's the one you posted in the Constructor forums) and it's not well suited for use in a game engine. If you need to keep the brushes a certain thickness then you'll need to use solution #2, break up the large brushes into smaller pieces so you can use a smaller lighting scale. Keep in mind that based on the size of that interior using large light maps could consume a lot of texture memory.

#15 Btw: Constructor is not using map2dif, I said similar code (in respect to BSP) - it uses a totally custom lighting solution based on TLK/TLS.

#16 I am just going to say thanks..
Not going to get in to it again with some one else

I would like to make a suggestion for map2dif why don't you just make it cut up the brushes or faces or what ever it does when it reaches max of 256x256 this would help keep large files cleaner and easy to work with for the artist...


I would like to say Thanks again for the attempt to help my stubbornness..

#17 ...hmmm... sounds like a good idea there adam...
not saying its as easy as one, two, three ...but the idea in concept sounds good...
Games nowadays are looking for bigger, more fantastical architecture.. i myself have run into the 256x256 error.. i broke the brushes up manually.. but the job was merely a technical one and could have been automated...


Ps. I want my Constructor! ...Waa Waa WaaaH.. (Dates?)

#18 I've also found that having the walls reach from the top of the ceiling brush to the bottom of the floor brush, cutting the ceiling/floor to be within the confines of those walls, and cutting walls that extend into other rooms can often cut down on various lighting problems.

#19 Do I dare reignite this issue? Nothing new to report, but as I was reading, I had an idea of the "ideal" exporter. Then I kept reading and saw Adam's suggestion of automating the breaking-up process. Along with that excellent idea, how hard would it be to have the exporter also look at proportions, and say on long skinny brushes, use a 512x64, for example? You'd get better shadows, and at half the cost (in this case) in the way of texture memory as a 256x256... assuming that I did my math right.

And by the way, THANK YOU for all explainations about light leaking. But I do have one question ... is there a tried and true method of building the exterior walls, or is that all a bunch of hogwash?

#20 I've found this works for me: Have the walls extend to the top of the roof to the bottom of the floor and slice walls where other walls meet perpendicularly (like a T , to reduce bleeding from another room). Also you may need to carve up large brushes to get a better lighting results.