 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Tyrann, if you get bored, might be an idea to generate some hexen2 variants (primarily for bsp2 support) too.
I don't personally make maps, but I'm sure someone would appreciate it... eventually... (hexen2 burns through clipnodes much faster). like Spike said, if it became possible to use BSP2 with Hexen 2, then I could finish this hexen 2 map
http://spawnhost.wordpress.com/2013/04/18/hexen-2-map/ Had to shelf it in frustration months ago because of bsp limit. Not sure that any H2 engines support a BSP2 format yet? Might not be too much work to hack it into uHexenII - haven't looked at that project in a long time. Anyone got some pointers to info on the H2 bsp format(s)?
wow
the stuff on your blog always looks awesome. I really like the look of that Hexen 2 map, especially the wooden stuff. Also seeing more shots of your e1m2-based map is great (I like the idea of adding an outside/location to the original map). FTE theoretically does. Both bsp2 and 2psb variants, as well as the h2 tweeks. I don't see any reason why it would fail to work properly, but this particular usage is untested hence my usage of the word 'theoretically'.
The hope is that the other engines will eventually gain support once there are actually maps that use it (that they can test against), as its not too hard to add support to an engine (I really ought to provide a more usable diff in that markv zip). Basically, max_map_hulls is 8 instead of 4, with 6 hulls used instead of 3. Here's the hull size list you'd need to generate: 0 0 0, 0 0 0 (render hull, exactly the same as quake) -16 -16 -24, 16 16 32 (player hull, exactly the same as quake) -24 -24 -20, 24 24 20 (no longer the shambler hull) -16 -16 -12, 16 16 16 -8 -8 -8, 8 8 8 -48 -48 -50, 48 48 50 unused unused The That's a lot of hulls! There's the answer as to where all the clipnodes go ;)
No promises, but I'll play around with it and see what I can do. Tried v0.14 tonight out of curiosity. At first I thought -forcegoodtree just wasn't working:
txqbsp_xt -forcegoodtree 31815 marksurfaces tyrqbsp -forcegoodtree 33242 marksurfaces Then I ran them both without -forcegoodtree: txqbsp_xt 33205 marksurfaces tyrqbsp 34644 marksurfaces There is an almost identical decrease in marksurfaces (1402 vs 1390) between the two versions, but in both cases the marksurfaces with Tyrutils v.14 is almost 5% higher. Any idea as to why? ---- qbsp / TyrUtils v0.14 ----
Input file: wishtest.map Output file: wishtest.bsp ---- LoadMapFile ---- 33522 faces 5670 brushes 1981 entities 200 unique texnames 2624 texinfo Opened WAD: C:QuakeID1Wish13.wad Processing hull 0... ---- Brush_LoadEntity ---- 5190 brushes ---- CSGFaces ---- 30614 brushfaces 25596 csgfaces 21931 mergedfaces ---- SolidBSP ---- 16691 split nodes 7609 solid leafs 8639 empty leafs 444 water leafs 43368 leaffaces 35821 nodefaces ---- Portalize ---- 9083 vis leafs 9083 vis clusters 29991 vis portals ---- FillOutside ---- 2796 outleafs ---- MergeAll ---- 17258 mergefaces ---- SolidBSP ---- 11831 split nodes 6183 solid leafs 5264 empty leafs 385 water leafs 30076 leaffaces 23920 nodefaces ---- Portalize ---- 5649 vis leafs 5649 vis clusters 17062 vis portals ---- Tjunc ---- 24194 world edges 82878 edge points 18203 edges added by tjunctions 0 faces added by tjunctions ---- MakeFaceEdges ---- ---- GrowRegions ---- Processing hull 1... Processing hull 2... ---- WriteBSPFile ---- 11250 planes 225000 33723 vertexes 404676 13866 nodes 332784 2624 texinfo 104960 26876 faces 537520 31194 clipnodes 249552 7404 leafs 207312 33340 marksurfaces 66680 122760 surfedges 491040 62456 edges 249824 207 textures 2256512 lightdata 0 visdata 0 entdata 237337 36.769 seconds elapsed Peak memory usage: 122568632 (116.9M) TxQBSP 1.13 ( XT build 260513 ) -- Modified by Bengt Jardrup -- Further mods by Baker, mh, rebb -- Original Detail/Hint code by Alexander Malmberg <alexander@malmberg.org> Inputfile: wishtest.map Outputfile: wishtest.bsp ------ LoadMapFile ------ Title: "Wish 13" 33522 faces 5670 brushes (0 detail) 1981 entities 199 miptex 2581 texinfo Added 8 texture frames Building hulls sequentially... Processing hull 0... ------ Brush_LoadEntity ------ 5190 brushes read ------ CSGFaces ------ 30614 brushfaces 24947 csgfaces 21726 mergedfaces ------ SolidBSP ------ 17511 split nodes 8060 solid leafs 8976 empty leafs 476 water leafs 43873 leaffaces 37058 nodefaces ------ FillOutside ------ 2939 outleafs ------ MergeAll ------ 17058 mergefaces ------ SolidBSP ------ 11628 split nodes 6158 solid leafs 5096 empty leafs 375 water leafs 29088 leaffaces 23295 nodefaces ----- Portalize Detail ---- 5471 vis leafs 16536 vis portals 5471 real leafs ------ Tjunc ------ 23802 world edges 80823 edge points 17496 edges added by tjunctions 0 faces added by tjunctions ------ MakeFaceEdges ------ ------ GrowRegions ------ Processing hull 1... ------ MergeAll ------ 15451 mergefaces Processing hull 2... ------ MergeAll ------ 12962 mergefaces ------ FinishBSPFile ------ WriteBSPFile: wishtest.bsp 11245 planes 224900 32578 vertexes 390936 13677 nodes 328248 2581 texinfo 103240 26122 faces 522440 24351 clipnodes 194808 7228 leafs 202384 32163 marksurfaces 64326 119052 surfedges 476208 61322 edges 245288 207 textures 2256512 lightdata 0 visdata 0 entdata 237337 Skipped 0 surfaces Elapsed time : 1:20.32 Peak memory used : 42.9 MB Marksurfaces being 5% higher seems like a lot and it's odd that there's much difference at all, but I think I'm probably the only one here that even cares how high they are. I'll be fine with txqbsp_xt for this map.
Rick, the increase of marksurfaces can often fluctuate because of the map file. Some editors reverse the saving order of brushes, entities and groups each time they save. Marksurfaces is extremely sensitive to the order in the map file.
I used 0.14 for my latest map zendar and I could not get goodtree or onlyents to work properly. Whenever I tried to compile with the goodtree option I would get endless leaks through solid brushes throughout the map. These tools are not 100% reliable just yet. That's the same exact map file, just two different qbsp exes, no editor touched it or re-saved it between compiles. That's why I found it strange.
Netradiant seems to be pretty good about not screwing up things from one save to another. Usually, just changing brushes doesn't affect the marksurfaces too much. Only when adding or deleting brushes do I see large differences. Brush order in the actual map file seems to have big influence on msf count.
Cutting out parts of the geometry and pasting them back in after saving the file, can effect in some reduction of the numbers, if this is done "room by room". Problems occur when maps are not made totally out of connnected boxes or "rooms", zendar or my latest map comes to mind. Forcegoodtree did not work for me too:) Why restrict yourself to 1996 limitations?
I get it, but from the screens you've been posting Rick I suspect you're procrastinating over your level too much. I'm all in favour of making YOUR level, but, hopefully without being a cunt, I think you've gone into tweaking overdrive. If you love it, let it go. And then learn from it. Has been since probably November. I was just trying the new utils. All I've really done in the last few months is lighting and monster placement and a couple of new textures. Marksurfaces are fine now with txqbsp_xt, a little lower than they were in November actually.
I long ago came to the conclusion that I was never going to be completely happy with it, even if I worked on it for another two years (which isn't gonna happen). I was hoping to release it sometime in December, but ran into a minor issue and was delayed by the Holidays. I've actually been ignoring it for the last week or so. There's one more thing I want to try, but after that... I can't understand how func_detail work. Change someting if I will transform some brushes into func_detail?
Do it reduce time for vis process? Basically func detail brushwork is ignored by everything apart from the vis tool. So almost everything which isn't sealing the void or subdividing your level should probably be detail brushes - unless it's a func of course.
1. The BSP compiler ignores func_detail brushes when calculating the BSP tree for the VIS compiler to use, then it removes the entity information from the brush(es) making just another solid brush.
2. The LIGHT compiler sees it as a solid, end of story. 3. The VIS compiler doesn't see it because the BSP compiler never included it in the BSP tree calculations that vis uses to do its thing. Try using the skip texture on it just to see something "Special" (or rather not see it). You will get an invisible brush that will cast a shadow.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |