Game Development Community

TGE + Constructor Light Weirdness

by Jay Barnson · in Torque Game Engine · 06/16/2009 (8:54 pm) · 8 replies

I'm getting parts of walls that appear to be lit as if by the exterior sunlight. But they are weird portions - even interior walls completely enclosed by zones that are entirely portaled and otherwise only lit by interior lights. This isn't like light "leaks" between walls and ceilings / floors - this is a square part of a brush being lit completely differently from the rest of the brush.

Some images to show what I mean:

Part of an interior wall (still flagged as structure, but all contained within a single zone):
rampantgames.com/frayedknights/images/weirdlight1.jpg
A far wall (exterior) and a piece of the floor where the stairway (flagged as detail brushes) connect:
rampantgames.com/frayedknights/images/weirdlight2.jpg
Probably the most stark offender - part of the floor (the area below it is also part of the same zone - this is the top floor of a big tower):
rampantgames.com/frayedknights/images/weirdlight3.jpg
Any ideas what could be causing it, and what I should do to fix it? I am using the latest (I think) version of Constructor - 1.051 - to export the maps.

The areas pictured (except, I think, the far wall in the middle picture) may have detail brushes penetrating them - the molding in the top picture, and the tips of the stairways which I didn't clip in the middle and bottom pictures. I'm not sure if that's a universal case - I've got these problems in a lot of spots in a fairly large interior.

About the author

Jay has been a mainstream and indie game developer for a... uh, long time. His professional start came in 1994 developing titles for the then-unknown and upcoming Sony Playstation. He runs Rampant Games and blogs at Tales of the Rampant Coyote.


#1
06/17/2009 (6:18 am)
Yes, I know exactly what is causing it. There are some bugs in the BSP generation that have to do with coplanar faces with inverted planes and zoning that I was never been able to fix - this would blow up the exporter. I ended up checking the faces for invalid zones at export time, and assigning them to the outside zone as a hack to keep the app from generating a protection fault.
The work around, unfortunately, is to make sure that the faces that are causing the problem are offset or marked as detail brushes. Note that this won't work for the floor, but it might be that it is the bottom of the column or stairs that are causing the issue.
#2
06/17/2009 (7:35 am)
Ouch.

So what I'm hearing is that any other brush that is up flush with the "offending" brush - sharing the same plane with an opposite-facing face - could cause this problem?

Detail brushes don't get counted when it comes to calculating zone partitions, do they?

#3
06/17/2009 (9:43 am)
Perhaps try selecting the brush who is returning bad light and build multiple smaller brushes in that ones place. Such as that last example pic, build two or more brush in that area.
This technique have worked very well for me.
#4
06/17/2009 (10:49 am)
@Jay - Yes, this can cause the problem. I wish I had a better answer for it, but I just didn't have the time to track it down. The worst part is that the faces don't actually have to be touching - just sharing the same plane. After I think about it, it's not the stairs or the column causing it (they're obviously detail brushes becuase they didn't split the face). Most likely it is a wall or something else.

Detail brushes don't count, because they aren't part of the tree, nor are they used when generating zones.

Caylo's solution can help. Also going through and making sure every non-zone defining brush is defined as detail can help. Sometimes it's helpful to clean it up by exporting to a map, and reimporting.
#5
06/17/2009 (11:17 am)
Jaimi's explanation actually explained a few things to me :D

And yes Caylo's suggestion is viable and one I've come up with myself.
#6
06/17/2009 (9:09 pm)
Thanks TONS for the suggestions and explanation.

It's a pain, but it's good to see some alternative work-arounds.
#7
07/16/2009 (1:30 pm)
Ugh. After trying multiple work-arounds without much success (I've got a couple of BIG interior environments), the ultimate solution was just to set the sunlight ambient close to the interior ambient to hide the problem.

It's kind of a booger. But having tried to export everything back out to .map and using MAP2DIF_PLUS to cause even MORE bugs & issues, I'm not sure of a better solution.

I haven't tried this yet (I'm thinking out loud away from my game development computer), but if I dynamically changed the sunlight ambient via triggers on either side of a doorway portal, the lighting artifacts that we're seeing here should change as well, without requiring a relight calculation pass, shouldn't it?
#8
05/04/2010 (7:19 pm)
Got a new solution we're using - for anybody still following this thread.

Split the offending brush lengthwise - so that you have an "outer" and "inner" brush (probably two very thin brushes stuck together).

Tag the "inner" brush as a detail brush.

In practice, this hasn't caused any new light leaks (yet), nor has it caused the problem to migrate to new brushes. So - while it's a kludge, it works, and seems like it may be a final solution.

At least until / unless the underlying issue with the exporter ever gets resolved.