 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Yeah, lots of unfinished stuff in TyrQuake. Resolution changing is only partly done - I really need to finish that off.
I'll get another build of qbsp up with -2psb support. Qbsp can now parse Quake 2 map format - you still need your textures in WAD format, but qbsp will automatically strip the leading path from the texture name and ignore the extra surface attributes that are not used by Quake. And by popular demand, we can now output RMQ style BSP2 ("2PSB") format bsp files again with the -2psb command line.
TyrUtils v0.14 changes: * qbsp: Added Quake 2 map compatibility * qbsp: Add -2psb option to output in RMQ compatible BSP2 format Download from the utils page as usual (Win32 / OSX / source). @RickyT23: my light util has most things that are provided by the bjp tools - give it a try and see if it does what you need. Check the docs to see which options and keys are available.
This is great news that you have added RMQ BSP2 support for Tyrqbsp. However, there is one crucial feature that crashes v14 of tyrqbsp before it even begins, fence textures, or alpha masked textures.
If tyrqbsp finds any texture in the map that starts with the { character, is stops operation and results in an error of: ************ ERROR ************ Internal error: didn't allocate enough entities? or ************ ERROR ************ Internal error: didn't allocate enough brushes? depending upon the map. I've done various tests and concluded the result of this error is in fact the cause of having just one texture starting with the { character, which any alpha masked texture must start with to be rendered properly by RMQ etc. Surely this is an easy fix? Doesn't support these yet either.
I haven't investigated any code or anything - what was the reason for using opening brace? This seems to be the cause of most of the problems. Lame question, seeing as how close I was to the development of the format, but why not use a neutral / unused symbol, like @ or something... 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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |