Are There Any Tools For Removing Models From Maps?
WolfWings
NS_Nancy Resurrectionist Join Date: 2002-11-02 Member: 4416Members
NS_Nancy Resurrectionist Join Date: 2002-11-02 Member: 4416Members
<div class="IPBDescription">Not ripent, different models here...</div> Specifically, is there a tool I can use to remove specific brush-based models from a map? I.E. The "*8" type of model. I'm asking, as if I can it would reduce the file-size of a map I'm tinkering with noticably, and I'm a perfectionist. :-)
Basically, I'm compiling a map with an interesting twist in the compile-chain. After the OptPlns step, I export the entities using ripent, automagically strip out some now-useless ones using a PERL script, then re-import the new entity-list using ripent again. This lets me remove things like info_texlights which NS complains about being an invalid entity, trim out unneeded zhlt_* strings, since they don't affect the actual running game any, etc.
They also allow me to have entities in the map only during the compile stage for lighting, and remove them entirely in-game to reduce the entity-count.
Thing is... I'd like to reduce my file-size further by removing now-unused brush models. As an example, some that are in the original .map file purely for switchable texture-lighting are no longer used, so if I could delete the entry entirely, I can re-sort the map to guarantee those brush-models are the last ones, so removing them won't affect the index-numbers of the remaining brush-models.
So do I get to break out a C compiler and start working on something like this myself, or has such a tool already been made? =^.^= Or is this something more advanced and determined than most folks have even considered for map optimization?
Basically, I'm compiling a map with an interesting twist in the compile-chain. After the OptPlns step, I export the entities using ripent, automagically strip out some now-useless ones using a PERL script, then re-import the new entity-list using ripent again. This lets me remove things like info_texlights which NS complains about being an invalid entity, trim out unneeded zhlt_* strings, since they don't affect the actual running game any, etc.
They also allow me to have entities in the map only during the compile stage for lighting, and remove them entirely in-game to reduce the entity-count.
Thing is... I'd like to reduce my file-size further by removing now-unused brush models. As an example, some that are in the original .map file purely for switchable texture-lighting are no longer used, so if I could delete the entry entirely, I can re-sort the map to guarantee those brush-models are the last ones, so removing them won't affect the index-numbers of the remaining brush-models.
So do I get to break out a C compiler and start working on something like this myself, or has such a tool already been made? =^.^= Or is this something more advanced and determined than most folks have even considered for map optimization?
Comments
I haven't heard of anything for this purpose, but you could do it the hard way and just make one entity, ripent, copy, change origin, etc.
I'm trying to think of which modeled ents you might be deleting...
Basically, I'm compiling a map with an interesting twist in the compile-chain. After the OptPlns step, I export the entities using ripent, automagically strip out some now-useless ones using a PERL script, then re-import the new entity-list using ripent again. This lets me remove things like info_texlights which NS complains about being an invalid entity, trim out unneeded zhlt_* strings, since they don't affect the actual running game any, etc.
They also allow me to have entities in the map only during the compile stage for lighting, and remove them entirely in-game to reduce the entity-count.
Thing is... I'd like to reduce my file-size further by removing now-unused brush models. As an example, some that are in the original .map file purely for switchable texture-lighting are no longer used, so if I could delete the entry entirely, I can re-sort the map to guarantee those brush-models are the last ones, so removing them won't affect the index-numbers of the remaining brush-models.
So do I get to break out a C compiler and start working on something like this myself, or has such a tool already been made? =^.^= Or is this something more advanced and determined than most folks have even considered for map optimization? <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's not available in a public tool yet -- shouldn't be too hard for you to strip out the hulls, but you'll need to reclusively garbage collect the excess faces, segments, planes, points, etc. that aren't used by anything else if you want to get the job done right. If you really want the smallest possible map, you'll want to strip out excess texinfos and the like as well.
I actually have several func_illusionary sections that lie outside of the worldspawn (visible through NULL walls and extending the perceived level extents without interaction with the commander, who can't see them) that I want to light in one map and then use in another, so I'm working towards swapping <i>brush</i> model entities in and out of maps. This is yet another item that I'll be supporting at a scripting level once the new stuff is done.
Since I'm storing geometry using a reference counted, object based model internally, stripping out a brush entity will automatically decrement the model's reference count and clean it up if appropriate. It's nice when you realize what a little planning and organization can get you for free <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. I want to hit theoretical minimums for stored data when the new tools crank out a BSP--the new data format will expedite that process.
I've been very busy with real life distractions for the last week; expect some visible progress on the website and tools (including a fix for zhlt_noclip) soon.
EDIT: added italicized <i>brush</i> above for clarification.
Will work MUCH better once I can put a limit on how 'weak' switchable lighting can get before being discarded, so I can get rid of the 'too many lightstyles' problem more readilly.
And thanks for the info, Cagey. I'll chill and wait for your tools it looks like, especially for the zhlt_noclip bugfix, since that bit me earlier. =^.^= Easier than spending my time to implement what your new tools will have, likely by the time 'my' tools were finished and bug-tested for completeness.
Being able to swap brushes between levels could be useful in another way, as well. Possibly fix clipping problems by making seperate versions of a map for some classes, like a special 'Onos' version of the level using Oni-hull clipping, etc, etc.
Now if only Flayra could add support for a brush-based entity that's never drawn, but always clipped against for skulk wall-climb but not for attacks and gunfire. Then all our problems would be over. :-)
[I first found out about brush model reuse through a tutorial at the Valve ERC using it for stair cases, but the author him-self didn't know how the engine would handle that or if even drawing speed can be improved. But I guess as it is not a 'supported' feature there will be no speed gain, because nobody optimized the code for it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ]
[I first found out about brush model reuse through a tutorial at the Valve ERC using it for stair cases, but the author him-self didn't know how the engine would handle that or if even drawing speed can be improved. But I guess as it is not a 'supported' feature there will be no speed gain, because nobody optimized the code for it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ] <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
As you noted, the fact that shooting the model at one location causes bullet holes at others implies that the model is loaded once and referenced at the same memory location in both spots.
By reusing a single model for those roof ornaments, your friend would be saving all of the resources required to build that model both in the BSP and at runtime. In fact, the entity count is the one spot that he wouldn't see a savings, since you need to place an entity for each copy of the model. Even if the model is used in multiple locations, the plane information the engine uses would be conserved--the planes are always shifted so they are centered on model origin when CSG reads in the map information; when you place a model twice using ripents, the only thing you're changing between is the brush model's origin relative to the world axes.
I'm not sure what the speed implications of the shared model are--it depends on how model information is cached in the engine.