Of Leaks and Leaves...
by Eric Forhan · in Torque Game Engine · 04/28/2002 (8:39 am) · 9 replies
I know that leaks in the BSP tree are bad juju--and I've read enough to know that for games like half-life even a small leak can cause major problems. It also causes light to shine through the cracks. WC compilers stop compiling at the first sign of leakage--but Morian/map2dif compiles anyway.
Do leaks and empty leaves affect T2 performance significantly?
How does one fix empty leaves? and,
What is the correct way to make a portal?! I make it a brush entity portal w/ ambient light not passing thru. Still, it causes an "empty brush" error and light seems to still come through. Perhaps I must use a certain texture, like "null"?
Thanks in advance.
Eric
Do leaks and empty leaves affect T2 performance significantly?
How does one fix empty leaves? and,
What is the correct way to make a portal?! I make it a brush entity portal w/ ambient light not passing thru. Still, it causes an "empty brush" error and light seems to still come through. Perhaps I must use a certain texture, like "null"?
Thanks in advance.
Eric
About the author
#2
Are you sure? When I do that, any objects in the interior do not get lit at all.
An example - use the default building you include in QuArK4Torque, switch to 3rd-person, and run inside. The player will darken, apart from the metal on the armor.
Then widen the portal so that it is thicker than the opening, export again, and it will work correctly.
04/28/2002 (11:54 am)
Quote:
make sure it (...) is narrower than the surrounding brushes
Are you sure? When I do that, any objects in the interior do not get lit at all.
An example - use the default building you include in QuArK4Torque, switch to 3rd-person, and run inside. The player will darken, apart from the metal on the armor.
Then widen the portal so that it is thicker than the opening, export again, and it will work correctly.
#3
holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/editing/img/portals01.jpg
That should work!
04/28/2002 (2:01 pm)
Here's a cool image Desmond posted a while ago for setting up portals correctly...holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/editing/img/portals01.jpg
That should work!
#4
05/01/2002 (9:54 am)
Thanks Stefan, I guess I should have just pointed to that :) As the image shows, the portal brush has to be bigger than the opening; but I make mine narrower from inside to outide than the brushes that surround the opening. Also, set the argument to allow ambient light to pass through the portal. That may be your real problem.
#5
Desmond, allow ambient light through? I thought this was the whole reason for portals--or does it have to do with the whole BSP thing, above? To limit leaks while compiling?
Also, I've read your tut on detail brushes. I guess I don't quite understand their purpose--that sometimes they may lower polygon counts and sometimes not. Can you expand, please? :)
Thanks in advance,
Eric
05/01/2002 (10:01 am)
Finally, something positive about Interiors! ;) LOL. Nice to know that leaks don't affect speeds like they do on other game engines.Desmond, allow ambient light through? I thought this was the whole reason for portals--or does it have to do with the whole BSP thing, above? To limit leaks while compiling?
Also, I've read your tut on detail brushes. I guess I don't quite understand their purpose--that sometimes they may lower polygon counts and sometimes not. Can you expand, please? :)
Thanks in advance,
Eric
#6
Anyway, this engine isn't built on one bsp like Half-Life or Quake. There can be many in one level, and they all are independent of one another.
A "leak" in Torque is just a window :p
05/01/2002 (10:18 am)
Heh, that's not positive!Anyway, this engine isn't built on one bsp like Half-Life or Quake. There can be many in one level, and they all are independent of one another.
A "leak" in Torque is just a window :p
#7
Detail brushes are best used when you don't want one brush to cause a surface breakup of another brush it touches. But all the surfaces of the detail brush are rendered. So you have to decide whether you're reducing the surface count by making a detail brush or not. In my sample map for example, if the columns are not details, they will cause the floor and ceiling to be broken up into several new surfaces each but the tops and bottoms of the columns would not be rendered if they touch the ceiling and floor. By making the columns details, the ceiling and floor are still one (inside) surface each but you've added the top and bottom surfaces of the columns. In addition to the surface count issue (always trying to reduce poly count :), there is the light-bleed issue: breaking a surface can lead to lightmap defects which are visually unappealing. Adding detail brushes can eliminate this problem at the expense of possibly adding more surfaces. I'm hoping that GG's TODO for radiosity might address some of these issues.
Let me know if this helps or you need more info.
05/01/2002 (10:22 am)
Don't think of leaks in Torque in the same way as leaks when building ID style maps where you get the HOM (hall-of-mirrors) effects when improperly mapped. In Torque, the worst that can happen is you don't get a proper zone. Zones are designed to improve rendering speeds but if not properly constructed, your world won't crash and you won't get HOM--just slower fps perhaps. To be properly constructed, a zone has to be contained by structural brushes and portal brushes. Detail brushes or cracks (spaces between brushes) will cause zone leaks and the zone won't be created during the compile process. Also, in the up-coming newsletter will be explanations for interiorRenderModes that let you see the zones (if they are properly constructed).Detail brushes are best used when you don't want one brush to cause a surface breakup of another brush it touches. But all the surfaces of the detail brush are rendered. So you have to decide whether you're reducing the surface count by making a detail brush or not. In my sample map for example, if the columns are not details, they will cause the floor and ceiling to be broken up into several new surfaces each but the tops and bottoms of the columns would not be rendered if they touch the ceiling and floor. By making the columns details, the ceiling and floor are still one (inside) surface each but you've added the top and bottom surfaces of the columns. In addition to the surface count issue (always trying to reduce poly count :), there is the light-bleed issue: breaking a surface can lead to lightmap defects which are visually unappealing. Adding detail brushes can eliminate this problem at the expense of possibly adding more surfaces. I'm hoping that GG's TODO for radiosity might address some of these issues.
Let me know if this helps or you need more info.
#8
I'm still not sure what the need for portal brushes is--unless it's to help keep zones in control.
/EDIT: I missed that in Desmond's reply, above.:) Duh!
I just started trying the detail brush. I'm not sure I'm using it correctly. I'm working on a steel-beam-construction bridge in which the beams come together like this:
The bars don't touch, and I've used a detail brush to cover the space/ends(it is slightly larger than the hole and encompasses the bars) but still come up with 100+- too many polygons @ compile time (WC reports 420 faces uncompiled but reports 550+ compiled).
Do I appear to be using the wrong? And is it possible to over-use detail or construction brushes?
05/01/2002 (11:18 am)
This helps quite a bit, actually.:) Thank you.I'm still not sure what the need for portal brushes is--unless it's to help keep zones in control.
/EDIT: I missed that in Desmond's reply, above.:) Duh!
I just started trying the detail brush. I'm not sure I'm using it correctly. I'm working on a steel-beam-construction bridge in which the beams come together like this:
_ _ /|\
The bars don't touch, and I've used a detail brush to cover the space/ends(it is slightly larger than the hole and encompasses the bars) but still come up with 100+- too many polygons @ compile time (WC reports 420 faces uncompiled but reports 550+ compiled).
Do I appear to be using the wrong? And is it possible to over-use detail or construction brushes?
#9
I built the beach house in Water World as an example of using zones. Switch to wireframe mode (it has been too long for me to remember how so look it up) and walk around the house. You will see that the furniture inside the room appears and disappears depending on whether their zone is visible. Somtimes it will be visible when you think it shouldn't be. Another handy thing to remember is that in addition to wireframe mode, the TGE has the ability to render the interiors in shades that represent the zones (the outside is white, the inside different colors). This is a very useful tool in determining if your zones are set up properly.
As far as lighting goes, there is a ton of room for improvement in the TGE. Light leaks are quite common and the ambient ligthing interactions inside the interiors can be downright odd. The only solution I can offer for now is to keep your structures as simple as possible and to avoid carving as much as you can (it introduces errors faster). Hopefully some intrepid programmer can tackle this in the near future.
05/01/2002 (11:21 am)
As Desmond mentioned, the main purpose of the portal brushes is to define zones which help in doing visibility tests by the engine (that's a mouthful =). For example, say you build a complex building with several interior rooms that should never be visible when you are outside the building. Well, if you didn't have any zones defined then when you switch to wireframe mode you will see that all of the geometry inside those interior rooms is getting rendered! You can use the portal brushes to "zone" off these interior rooms. Then, when the engine is tryng to determine what parts of the building it needs to render it can do simple tests to see if any of that zone is visible. If it is then it will render all the contents of that zone. If not, then it can skip over rendering everything inside the zone. Now, like Desmond also mentioned, if you don't set up the portal brushes correctly or if you have an invisible crack or gap in the zone's external geometry (that which defines the outside of the zone), the zone won't be created and you will be back to rendering everything again. Not a bad thing but it can add to slowdowns.I built the beach house in Water World as an example of using zones. Switch to wireframe mode (it has been too long for me to remember how so look it up) and walk around the house. You will see that the furniture inside the room appears and disappears depending on whether their zone is visible. Somtimes it will be visible when you think it shouldn't be. Another handy thing to remember is that in addition to wireframe mode, the TGE has the ability to render the interiors in shades that represent the zones (the outside is white, the inside different colors). This is a very useful tool in determining if your zones are set up properly.
As far as lighting goes, there is a ton of room for improvement in the TGE. Light leaks are quite common and the ambient ligthing interactions inside the interiors can be downright odd. The only solution I can offer for now is to keep your structures as simple as possible and to avoid carving as much as you can (it introduces errors faster). Hopefully some intrepid programmer can tackle this in the near future.
Torque Owner Desmond Fletcher
fletcher
As to leaks, Torque is a completely different system from the Quake style of mapping--there are no leaks. Build the dif, place it in the world: it's that simple. If you're brush vertex coordinates are not integer, then you can get cracks which essentially break the zone and cause unsightly visual leaks and brushes out of place, but these are not the same as leaks in Half-Life.