Compiler Modification
Erias
Join Date: 2003-08-17 Member: 19878Members
Join Date: 2003-08-17 Member: 19878Members
<div class="IPBDescription">This may very likely be possible & easy.</div> In my maps and others I've seen, a lot of detailed brushes are tied to entities simply to prevent them from splitting faces and screwing up geometry. However, NS being as complex as it is, there is of course an entity limit. Every entity counts, and all these "blank" entities are in this case technically not necessary and generate a lot of useless lag and net traffic when the map is run on a server. I propose this:
- A new brush entity is added, or existing one(s) modified (for example, a flag is added) that makes the compiler treat the brushes like an entity (it won't split up faces, etc) but then the entity the brush is tied to is removed and the faces are moved to the worldspawn.
- In addition, an option could be added so the brush does not generate clipping hulls, or the hulls are discarded, to prevent these details from "snagging" the player or making the clipnodes needlessly complex.
- By default, HLRAD would also treat this brush entity as opaque, although by the time the map data is sent to HLRAD the faces may already be in the worldspawn and treated as such anyways.
- There will of course be no modifications needed to the mod to support this, as the entity is removed completely before the map is run in HL.
- A compromise here is of course that the brush cannot be manipulated as an entity (including rendermodes, etc) although that's the whole point here... to remove entites that are technically not being used.
- Depending on where the faces are "untied" in the compiler code, this "quasi-entity" may be able to block vis and seal leaks!
- Faces will not be removed from the brush on coplanar faces or in the void, so there is a small limit to this function's efficiency.
So, there is my proposal. This modification would, imo, allow considerably more powerful, detailed mapping for NS and help cut down on the load caused by extraneous map entities. It would not, as far as I know, be terribly difficult to implement, either.
I might email this idea to XP-Cagey, who is pretty much the only guy whose doing this sort of thing right now. I'm also a coder myself, and I would be interested in trying my hand at hacking up the magical HL compiler, but I'm not sure how hard it would be to get my hands on the mystical source code...
Well, that's all I have to say. Tell me what you think of this idea!
<span style='color:orange'>Those who are not aware of the general idea of how HL maps and the map compiler work, please refrain from posting in this thread (no offense meant, but I want this post to be taken seriously and not get clogged up with irrelevant stuff.)</span>
- A new brush entity is added, or existing one(s) modified (for example, a flag is added) that makes the compiler treat the brushes like an entity (it won't split up faces, etc) but then the entity the brush is tied to is removed and the faces are moved to the worldspawn.
- In addition, an option could be added so the brush does not generate clipping hulls, or the hulls are discarded, to prevent these details from "snagging" the player or making the clipnodes needlessly complex.
- By default, HLRAD would also treat this brush entity as opaque, although by the time the map data is sent to HLRAD the faces may already be in the worldspawn and treated as such anyways.
- There will of course be no modifications needed to the mod to support this, as the entity is removed completely before the map is run in HL.
- A compromise here is of course that the brush cannot be manipulated as an entity (including rendermodes, etc) although that's the whole point here... to remove entites that are technically not being used.
- Depending on where the faces are "untied" in the compiler code, this "quasi-entity" may be able to block vis and seal leaks!
- Faces will not be removed from the brush on coplanar faces or in the void, so there is a small limit to this function's efficiency.
So, there is my proposal. This modification would, imo, allow considerably more powerful, detailed mapping for NS and help cut down on the load caused by extraneous map entities. It would not, as far as I know, be terribly difficult to implement, either.
I might email this idea to XP-Cagey, who is pretty much the only guy whose doing this sort of thing right now. I'm also a coder myself, and I would be interested in trying my hand at hacking up the magical HL compiler, but I'm not sure how hard it would be to get my hands on the mystical source code...
Well, that's all I have to say. Tell me what you think of this idea!
<span style='color:orange'>Those who are not aware of the general idea of how HL maps and the map compiler work, please refrain from posting in this thread (no offense meant, but I want this post to be taken seriously and not get clogged up with irrelevant stuff.)</span>
Comments
Anyways, I can assure you this idea has nothing to do with the actual HL engine, all it requires is a change to the compiler (and the .fgd)
Max
...and if you want to try it yourself you can download the source code to Zoner's Half-Life tools (zhlt) and modify that.
Max
For some reason I had a feeling it wouldn't be downloadable, seeing as how the valve company owns it and all.
*downloads source code*
But I forget that valve is awesome. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
[edit] Lookin' at the source... sweet diddly, this is fun stuff. Not as hella complicated as I thought it would be, either.
It would be cool if you could implement that into the compile process.!!
"Detail brushes" is, I think, an idea left over from the Quake version of the engine. However, from what I've seen, detail brushes are considered replaced by func_wall entities. But, of course, func_wall is stupid because it's a runtime entity and lags stuff up in large maps.
It is my understanding (as divined from the source code) that brushes with different contents don't split up each other's geometry. This means this is a viable solution!
However, all builds of the compile tools have this function disabled.
So, I will try building ZHLT with support for detail brushes, and see what's what! If the content-type "DETAIL" is not supported this might cause problems, but I suspect this might work, and then everyone's happy.
I'll have to look into this futher, and maybe fire off an e-mail to XP-Cagey, who knows what he's doing. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
As Cagey is starting work on "from scratch" versions of the tools, this functionality may be of interest for him.
Not to go off topic, but another way to skin this cat (reducing server strangling entities), would be to make a brush entity (such as info_detail or something) that the server ignores entirely. Purely client side enitities. This would require changes internal to NS, but the net performance would be great. As I have no idea how the halflife engine works with entities (yet) this idea may not be plausible, though I can't see why entities that have NO effect on other sides of the connection should cause a network to lag. *cough*func_wall*cough* <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
- In addition, an option could be added so the brush does not generate clipping hulls, or the hulls are discarded, to prevent these details from "snagging" the player or making the clipnodes needlessly complex.
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
If you're using the latest compile tools you can do this part already. A func_illusion will not generate clipnodes, which saves on clipnode count during compiles.
As for the rest, Cagey will have to have a peek to see if this is workable.
and IMO this new entity should be called a func_worldbrush <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
- A new brush entity is added, or existing one(s) modified (for example, a flag is added) that makes the compiler treat the brushes like an entity (it won't split up faces, etc) but then the entity the brush is tied to is removed and the faces are moved to the worldspawn.
- In addition, an option could be added so the brush does not generate clipping hulls, or the hulls are discarded, to prevent these details from "snagging" the player or making the clipnodes needlessly complex.
- By default, HLRAD would also treat this brush entity as opaque, although by the time the map data is sent to HLRAD the faces may already be in the worldspawn and treated as such anyways.
- There will of course be no modifications needed to the mod to support this, as the entity is removed completely before the map is run in HL.
- A compromise here is of course that the brush cannot be manipulated as an entity (including rendermodes, etc) although that's the whole point here... to remove entites that are technically not being used.
- Depending on where the faces are "untied" in the compiler code, this "quasi-entity" may be able to block vis and seal leaks!
- Faces will not be removed from the brush on coplanar faces or in the void, so there is a small limit to this function's efficiency.
So, there is my proposal. This modification would, imo, allow considerably more powerful, detailed mapping for NS and help cut down on the load caused by extraneous map entities. It would not, as far as I know, be terribly difficult to implement, either.
I might email this idea to XP-Cagey, who is pretty much the only guy whose doing this sort of thing right now. I'm also a coder myself, and I would be interested in trying my hand at hacking up the magical HL compiler, but I'm not sure how hard it would be to get my hands on the mystical source code...
Well, that's all I have to say. Tell me what you think of this idea!
<span style='color:orange'>Those who are not aware of the general idea of how HL maps and the map compiler work, please refrain from posting in this thread (no offense meant, but I want this post to be taken seriously and not get clogged up with irrelevant stuff.)</span> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
You've described detail brushes with an optional clipping extension <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Traditional implementations of detail brushes (Q2, Q3 engines) actually store the brush information separately from the primary worldspawn and draw them on an as-needed basis -- they are essentially immutable one-hull entities without clip information or AI. This sort of solution won't work in Half-Life without the addition of specialized rendering code to handle drawing the brushes once they've been created and stored.
The current method for storing individual faces in a Half-Life BSP is to place them into the node structure describing the wall that the face lies along -- because of this, every time a face is added along a new plane, the tree splits along the face's plane in order to preserve the information about that face. When you insert your proposed detail brush faces back into the worldspawn, you must either violate the implied data requirements of the format or split the worldspawn anyway.
I've considered two approaches toward reducing r_speeds that may or may not blow up the Half-Life renderer. First, I haven't tested what happens when you give the compiler the wrong node for a face. I'm pretty sure that this will totally screw up the software renderer, since the position of a face in a BSP is supposed to be a fast, natural indication of drawing order for the painter's algorithm when you treewalk the BSP. I think that you'd probably end up with faces popping up in the wrong order. If the hardware renderers use a z-buffer to sort its faces they won't have this problem unless some faces are partially transparent--in which case the engine needs to presort them by distance manually and will probably fail just like the painter's algorithm due to bad tree information.
The second approach I've considered is reconnecting contiguous, coplanar faces across multiple nodes -- that is, reversing any face splits that still result in convex faces when merged. This could also cause problems with the percieved ordering of the faces, but in this case each face would at least lie in the correct plane.
The detail brush idea would work if a mod used Half-Life's TriAPI to add drawing support for a new structure appended to Half-Life's BSP format. The Half-Life BSP uses a header to point to the index of each expected data section; it's possible to sandwitch extra information between the indexed areas and have the map run normally. If a mod wanted to develop detail brush technology in their renderer, that would be the way to go--I could then support actual detail brushes in the tools that mimic that function in other engines.
- A new brush entity is added, or existing one(s) modified (for example, a flag is added) that makes the compiler treat the brushes like an entity (it won't split up faces, etc) but then the entity the brush is tied to is removed and the faces are moved to the worldspawn.
- In addition, an option could be added so the brush does not generate clipping hulls, or the hulls are discarded, to prevent these details from "snagging" the player or making the clipnodes needlessly complex.
- By default, HLRAD would also treat this brush entity as opaque, although by the time the map data is sent to HLRAD the faces may already be in the worldspawn and treated as such anyways.
- There will of course be no modifications needed to the mod to support this, as the entity is removed completely before the map is run in HL.
- A compromise here is of course that the brush cannot be manipulated as an entity (including rendermodes, etc) although that's the whole point here... to remove entites that are technically not being used.
- Depending on where the faces are "untied" in the compiler code, this "quasi-entity" may be able to block vis and seal leaks!
- Faces will not be removed from the brush on coplanar faces or in the void, so there is a small limit to this function's efficiency.
So, there is my proposal. This modification would, imo, allow considerably more powerful, detailed mapping for NS and help cut down on the load caused by extraneous map entities. It would not, as far as I know, be terribly difficult to implement, either.
I might email this idea to XP-Cagey, who is pretty much the only guy whose doing this sort of thing right now. I'm also a coder myself, and I would be interested in trying my hand at hacking up the magical HL compiler, but I'm not sure how hard it would be to get my hands on the mystical source code...
Well, that's all I have to say. Tell me what you think of this idea!
<span style='color:orange'>Those who are not aware of the general idea of how HL maps and the map compiler work, please refrain from posting in this thread (no offense meant, but I want this post to be taken seriously and not get clogged up with irrelevant stuff.)</span> <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
You've described detail brushes with an optional clipping extension <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Traditional implementations of detail brushes (Q2, Q3 engines) actually store the brush information separately from the primary worldspawn and draw them on an as-needed basis -- they are essentially immutable one-hull entities without clip information or AI. This sort of solution won't work in Half-Life without the addition of specialized rendering code to handle drawing the brushes once they've been created and stored.
The current method for storing individual faces in a Half-Life BSP is to place them into the node structure describing the wall that the face lies along -- because of this, every time a face is added along a new plane, the tree splits along the face's plane in order to preserve the information about that face. When you insert your proposed detail brush faces back into the worldspawn, you must either violate the implied data requirements of the format or split the worldspawn anyway.
I've considered two approaches toward reducing r_speeds that may or may not blow up the Half-Life renderer. First, I haven't tested what happens when you give the compiler the wrong node for a face. I'm pretty sure that this will totally screw up the software renderer, since the position of a face in a BSP is supposed to be a fast, natural indication of drawing order for the painter's algorithm when you treewalk the BSP. I think that you'd probably end up with faces popping up in the wrong order. If the hardware renderers use a z-buffer to sort its faces they won't have this problem unless some faces are partially transparent--in which case the engine needs to presort them by distance manually and will probably fail just like the painter's algorithm due to bad tree information.
The second approach I've considered is reconnecting contiguous, coplanar faces across multiple nodes -- that is, reversing any face splits that still result in convex faces when merged. This could also cause problems with the percieved ordering of the faces, but in this case each face would at least lie in the correct plane.
The detail brush idea would work if a mod used Half-Life's TriAPI to add drawing support for a new structure appended to Half-Life's BSP format. The Half-Life BSP uses a header to point to the index of each expected data section; it's possible to sandwitch extra information between the indexed areas and have the map run normally. If a mod wanted to develop detail brush technology in their renderer, that would be the way to go--I could then support actual detail brushes in the tools that mimic that function in other engines. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
As always Cagey talks above me, so in Lamen's(sp?) terms., is it possible or not?
~ DarkATi
~ DarkATi<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I have two experiments to do, but I don't think either one will work.
It's still possible if you change mod code.
P.S. -- the phrase is "layman's terms". If I recall correctly, a layperson is a member of the catholic church who isn't a member of the priesthood, so "layman's terms" would mean describing something in a way that the anybody could understand (originally the entire Church instead of just the Catholic priesthood, but the phrase now means everybody instead of a specific group with its own jargon, like lawyers, doctors, or BSP programmers <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->).
EDIT: LAY ? ?adj. of ordinary people; not of the clergy or a profession. About 1303 ?lai? secular; later ?lay? unlearned, uneducated (before 1338); ? ?layman? n. (probably about 1415)?? From the ?Barnhart Concise Dictionary of Etymology? by Robert K. Barnhart (HarperCollins Publishers, New York, 1995). Page 424.
In laypersons terms, BSP breaks up polygons as part of the process of compiling the map - it does this to satisfy the rules of the BSP structure. You can't avoid spliting faces if you want to put a poly into the bsp structure without breaking rules.
The idea of bsp is that every poly splits the map into two halves. Then if you are on one side of that poly, you have to draw the stuff on other side of the poly first, then the stuff on your side. This has the magical effect of drawing things from furthest away from you to closest. For a laugh, type r_draworder 1 sometime (I think you can in HL, you sure can in quake).
-Parallax
Which is why you walk the tree in the opposite direction for a modern engine that uses hardware z-buffering.
There is another option I conceived to implement this feature, but it is a total dirty n00bie hack:
Any faces on a "detail" brush that are coplanar with another face are moved away from the coplanar face in a perpendicular direction, by a very small increment (like a fraction of a unit) thus creating a minute break between this special brush and anything it touches. The brush is moved to world and the entity is baleeted.
This is basically the same as separating the geometry in the editor by moving it away by 1 unit from the brush you don't want split up, and then texturing that side with NULL... mweh.
Of course, there is yet another option: Since 3.0 is taking it's sweet time, we could just ask Flayra about making it so some entities can be run solely on the client and ignored by the server... then we can func_wall to our heart's content. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Anyways, thanks a bunch, XP-Cagey. You are a god of the digital realm. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
~ DarkATi<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I have two experiments to do, but I don't think either one will work.
It's still possible if you change mod code.
P.S. -- the phrase is "layman's terms". If I recall correctly, a layperson is a member of the catholic church who isn't a member of the priesthood, so "layman's terms" would mean describing something in a way that the anybody could understand (originally the entire Church instead of just the Catholic priesthood, but the phrase now means everybody instead of a specific group with its own jargon, like lawyers, doctors, or BSP programmers <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->).
EDIT: LAY ? ?adj. of ordinary people; not of the clergy or a profession. About 1303 ?lai? secular; later ?lay? unlearned, uneducated (before 1338); ? ?layman? n. (probably about 1415)?? From the ?Barnhart Concise Dictionary of Etymology? by Robert K. Barnhart (HarperCollins Publishers, New York, 1995). Page 424. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Thanks! You learn something new every day! (Or you should.) I didn't know all that mess about Catholics and so forth.
<!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
~ DarkATi