Gb
#79 posted by Tronyn on 2013/10/17 01:49:51
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).
#80 posted by Spike on 2013/10/17 02:18:44
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 .map format can be different, the extra fields can be ignored I believe. This doesn't affect the output, but is a tweak you might need for the map parser if you don't already support that.
#81 posted by Tyrann on 2013/10/17 02:32:58
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.
High Marksurfaces
#82 posted by Rick on 2014/01/06 07:46:29
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?
#83 posted by Tyrann on 2014/01/10 00:02:02
Looking at the full output of both qbsp compilers might give me some clues.
Here You Go
#84 posted by Rick on 2014/01/10 03:24:53
---- 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
#85 posted by Tyrann on 2014/01/10 04:04:07
The difference in texinfo counts looks suspicious to me, I might start looking there.
It's Probably Not That Important
#86 posted by Rick on 2014/01/10 21:00:36
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.
#87 posted by sock on 2014/01/10 21:23:20
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.
Yeah, But
#88 posted by Rick on 2014/01/10 21:47:10
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.
Yup
#89 posted by mfx on 2014/01/10 22:00:25
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:)
My �4.50
#90 posted by ijed on 2014/01/11 01:44:14
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.
It's Actually Pretty Much Done
#91 posted by Rick on 2014/01/11 02:32:12
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...
Func_detail
#92 posted by digs on 2014/02/17 12:53:34
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?
Yes
#93 posted by ijed on 2014/02/17 13:41:39
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.
Uh
#94 posted by ijed on 2014/02/17 13:43:00
And when the vis tool detects detail brushwork it doesn't include it in the vis calculation.
Uh
#95 posted by ijed on 2014/02/17 13:43:00
And when the vis tool detects detail brushwork it doesn't include it in the vis calculation.
#96 posted by digs on 2014/02/17 14:04:51
Thanks
Nice!
#97 posted by Breezeep_ on 2014/02/17 16:39:35
BTW
#98 posted by mechtech on 2014/02/17 23:23:22
A new version is out!
Func_detail
#99 posted by quaketree on 2014/02/20 15:38:35
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.
#100 posted by digs on 2014/02/23 18:40:20
light with _color property not lit. Why?
Digs
#101 posted by mfx on 2014/02/23 19:28:11
try color without the underscore.
#102 posted by digs on 2014/02/24 04:11:55
No, it turned out a different format from 0 to 255. I used to use from 0 to 1
#103 posted by digs on 2014/02/24 08:10:10
light format "_color" "255 255 255" worked, but not compatible with NetRadiant. Light entity looks like white light.
|