You're right on the second part there, Erias. However, faces which the player will never see and which face away from the player will never be drawn anyway (unless they are facing you and still being drawn, eg, from around the corner).
Right, from around the corner or from a vis leaf that can see it or whatever. I have come to realize that HL's VIS engine is as dumb as a doornail, so I help it out as best I can. A good whack of properly used NULL textures can be just as effective as a HINT brush.
Well just to split hairs (as I seem to be in that kind of mood <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> )
It's not the Half-Life VIS engine that you're helping, but rather the compile tools that precalculate the VIS for Half-Life, which don't calculate optimal VIS data without a little assistance (not that I blame them - it's not a trivial task).
Although, the system as a whole, including the in-game rendering engine, is also dumb. But it was made in like, 1992, so we can't really blame it. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
If you put a big bend in that vent the engine will hopefully not think you can see all the way through from one side to another, this will prevent rooms connected by only the vent from being visible from one another.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Although, the system as a whole, including the in-game rendering engine, is also dumb.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
So that's why quake 1-3 uses a BSP based engine as well as HL2 and all those games who uses the quake 3 engine <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->...
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Map editing for the Source engine will be very familiar to those who did mapping for Half-Life. We've always tried to extend rather than reinvent whenever possible. The main challenge will be digesting all the new tools and capabilities to get the most out of them.
The rough structure of the map is still BSP-based, built from brushes, but the details are fleshed out with more props (models) that are built in XSI, Maya, or Max.
World bounds are +/- 16384 units in all directions (Half-Life's world bounds were +/- 4096). Mods can choose their own unit scale for the world. For example, 1 unit could be made to be equal to 1 foot, or to 1/10 of an inch. Physics will be adjusted accordingly, but collisions are only guaranteed to be accurate to 1/32nd of a unit.
We have found that a large part of the cost of creating a Half-Life 2 quality level is in the art production process. Building all the props and textures required for the level of visual quality people saw at E3 consumes a lot of man-hours. As for building a Half-Life 1 quality map in the Source engine, the new tools and entity I/O makes it go much faster than it did on Half-Life 1<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I couldn't find the quote but world brushes still get split up where they touch each other because of the way BSPs work.
On the vent problem, how does vertical coordinates work with vis leafs? I know the vis info changes depending on the height of your viewpoint, but I wonder if a horizontal HINT brush would work as expected, to prevent the size of the leafs the vent can see from ensconcing the whole damn room. Another possibility is to split the leaves <i>inside</i> the vent, as opposed to HINTing at the entrance, so only a small leaf near the entrance of the vent can see the room.
As for the HL engine being dumb... well, I was referring to HL's iteration of the Quake/BSP engine, not the engine in general. And anyways, I was being a little bit facetious. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
<!--QuoteBegin--Erias+Aug 27 2003, 06:00 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Erias @ Aug 27 2003, 06:00 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> On the vent problem, how does vertical coordinates work with vis leafs? I know the vis info changes depending on the height of your viewpoint, but I wonder if a horizontal HINT brush would work as expected, to prevent the size of the leafs the vent can see from ensconcing the whole damn room. Another possibility is to split the leaves <i>inside</i> the vent, as opposed to HINTing at the entrance, so only a small leaf near the entrance of the vent can see the room.
As for the HL engine being dumb... well, I was referring to HL's iteration of the Quake/BSP engine, not the engine in general. And anyways, I was being a little bit facetious. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> VIS uses a "stabbing algorithm" explained in the article series I linked in the first page -- the orientation of portals used for VIS checking doesn't matter, so horizontal hint brushes do work as expected.
Splitting the leaves inside the vent is a better solution than a HINT at the opening; since visibility is calculated for any possible position in the entire leaf that the player is currently standing in instead of the player's actual position, anything visible from one end of the vent will be visible from the other unless the vent is divided into multiple sections.
Why do it that way? Because it's super fast at runtime and does a decent job of averaging out the amount that the the engine draws under most circumstances. Google "stabbing algorithm" or read the articles linked from the first page of the topic for more information.
Comments
It's not the Half-Life VIS engine that you're helping, but rather the compile tools that precalculate the VIS for Half-Life, which don't calculate optimal VIS data without a little assistance (not that I blame them - it's not a trivial task).
Although, the system as a whole, including the in-game rendering engine, is also dumb. But it was made in like, 1992, so we can't really blame it. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Although, the system as a whole, including the in-game rendering engine, is also dumb.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
So that's why quake 1-3 uses a BSP based engine as well as HL2 and all those games who uses the quake 3 engine <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->...
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Map editing for the Source engine will be very familiar to those who did mapping for Half-Life. We've always tried to extend rather than reinvent whenever possible. The main challenge will be digesting all the new tools and capabilities to get the most out of them.
The rough structure of the map is still BSP-based, built from brushes, but the details are fleshed out with more props (models) that are built in XSI, Maya, or Max.
World bounds are +/- 16384 units in all directions (Half-Life's world bounds were +/- 4096). Mods can choose their own unit scale for the world. For example, 1 unit could be made to be equal to 1 foot, or to 1/10 of an inch. Physics will be adjusted accordingly, but collisions are only guaranteed to be accurate to 1/32nd of a unit.
We have found that a large part of the cost of creating a Half-Life 2 quality level is in the art production process. Building all the props and textures required for the level of visual quality people saw at E3 consumes a lot of man-hours. As for building a Half-Life 1 quality map in the Source engine, the new tools and entity I/O makes it go much faster than it did on Half-Life 1<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I couldn't find the quote but world brushes still get split up where they touch each other because of the way BSPs work.
As for the HL engine being dumb... well, I was referring to HL's iteration of the Quake/BSP engine, not the engine in general. And anyways, I was being a little bit facetious. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
As for the HL engine being dumb... well, I was referring to HL's iteration of the Quake/BSP engine, not the engine in general. And anyways, I was being a little bit facetious. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
VIS uses a "stabbing algorithm" explained in the article series I linked in the first page -- the orientation of portals used for VIS checking doesn't matter, so horizontal hint brushes do work as expected.
Splitting the leaves inside the vent is a better solution than a HINT at the opening; since visibility is calculated for any possible position in the entire leaf that the player is currently standing in instead of the player's actual position, anything visible from one end of the vent will be visible from the other unless the vent is divided into multiple sections.
Why do it that way? Because it's super fast at runtime and does a decent job of averaging out the amount that the the engine draws under most circumstances. Google "stabbing algorithm" or read the articles linked from the first page of the topic for more information.