News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.5
It's been a long time, but finally I have something worth releasing, so here is version 0.5 of my map utils package:

* light and vis both now multithreaded on Unix and Windows platforms
* vis now writes a state file every 5 minutes so it can resume if needed
* qbsp and vis now support a form of detail brushes, similar to Quake 2. See qbsp.txt for further details.
* added a small optimisation to vis for a minor speedup (usually only 1-2%)
* build system re-written and lots of cleanups all over the code

Please test, break and report bugs as needed :)

* Announcement
* Utils Home Page
* Download: Windows, Mac OS X, source

My website has also had an update - let me know if I broke anything and hopefully the comments function also works.
First | Previous | Next | Last
Tyrann You Own! 
If anyone wants, I quickly added func_detail to my .ent file I use in Radiant 1.5

https://dl.dropbox.com/u/103186490/entities.ent 
Oh My God Oh My God Oh My God 
Proper detail brushes!!!

Tyrann, you are the awesome. 
Quick Question 
does the qbsp support all the increased map limits and increased floating point precision that's featured in bengt jardrup's txqbsp and treeqbsp? 
I Wonder 
Haven�t used your utils before, is this standalone or something you integrate into Radiant? Im at work now so can�t check it out 
Yes 
This qbsp uses double precision floating point and should be able to cope with all the usual increased limits. If not and you have a map that breaks it, let me know and I'll fix it. :)

It doesn't do bsp2 yet, but it's probably not that hard to add. Will look at this soon(ish).

Thanks Scampie for the Radiant example - I'll add the func_detail snippet to the qbsp.txt file. 
Nice Work ! ( And Fml ) 
I swear there must have been detail-brush implementation inspiration rays from outer space at play here, since i was working on the exact same thing on a modified TxQBSP / WVis combination.

But you're the real tool programmer, so i'll probably just clean the code up a little and put it up as a package somewhere, maybe some parts of the "implementation" could be of interest. 
CarlJ 
I'm don't know much about Radiant, but it should be possible. Hopefully someone else here can answer that one. 
Rebb 
Hehe, ouch, yeah that kinda sucks. But I'd definitely be interested to take a look at your implementation when you're done. 
Rebb 
I would love to try those tools based on TxQBSP, I use lot of the extra features of the Tx toolset (-gate 1.0 -soft -softdist 8 -extra4 -anglesense 0.65) and unfortunately they seem to be missing in the Tyrann tools. 
Sock 
Those seem to be light-related parameters, the detailbrush stuff doesn't need any light-tool changes as far as i'm aware.

So you should be fine using TyrUtil's BSP and VIS and Tx Light. 
 
That would be awesome if I can mix and match the compiler tools. I assumed it would not work, I will have to do some tests. 
Nice 
Tyrann, how does your implementation differ from the one in the Quest tools (and rebb's)? Do detail brushes split the polygons of normal world brushes they touch?

Make sure the vis state doesn't save unfinished (open) portals like the unfixed version of Wvis did! 
 
So in WC I can "tie to entity" on a brush and enter "detail" in the dialog box and it correctly bsp/vis properly with your tools? Also like Negke says, will this split faces of standard brushes? (I assume not) 
Tyrann 
Do you want the bsp2 compilers source? 
 
Yeah, what are the tech details on the detail brushes? Do they cast shadows, do they cut into the world, do detail brushes cut other detail brushes, etc? Sounds neat! 
 
The http://quakeforge.net/ tools also include detail brush support so for everyone playing around with them now, it would be great if you could test that as well. 
I Thought 
there was a reason no-one ever used the quakeforge stuff. damned if i can remember it though 
Face Splitting 
Do detail brushes split the polygons of normal world brushes they touch?

If they didn't split though, would that even produce a valid Quake bsp? Admittedly I'm not a guru, but I was under the impression that the best we could do in Quake would be something that drastically speeds up vis, but you'd still have to chop all the faces up. Maybe the splitting planes from the non-detail brushes could always get priority, which might reduce the number of polys split.

But ignore me, I don't really know. 
What Detail Brushes Do 
Kinn is pretty spot on actually. Detail brushes still split the world, but they don't cause extra portals to be generated the way normal brushes would. Less portals makes vis much happier - vis gets exponentially slower with the number of portals.

The planes from detail brushes are the last ones selected for splitting planes, so that all the leafs in a detail cluster have the same parent node. Not sure if that really means you get less poly splits, but it seems reasonable that it would help. 
Sock 
Yeah, you can use any light util - the only thing that changes is the .prt file, so the vis tool needs to understand that. But I will look at adding those options to my light util anyway (-gate, -soft, -softdist, -extra4, -anglesense). 
Spirit 
Oh, I never realised QF had that. I'll definitely take a look. Bill writes nice clean code! :) 
Tyrann 
Heh, cool I figured that's how it would work :}

If you're thinking about updating light to use the features in bengt's tool, don't forget "delay 5"! 
 
Tyrann: Could you add to your Qbsp support for floating point rotations of textures (so for instance, rotating a texture 22.5 degrees doesn't get rounded to 22 degrees)? Frib (or I guess a friend of his) added it to Bengt's modification of TreeQbsp, but it'd be nice to have with your func_details!


Some test shots, showing exactly what Tyrann just explained...

http://i.imgur.com/NHpU9eH.jpg
Here, the red textured brushes are func_detail brushes, and we can see that they still cut into the hull of the world. (the crate in the middle of the screen is a floating cube, world geometry)

http://i.imgur.com/LpQbmQU.jpg
Here you can see that that the PVS does not consider the func_detail brushes, as the floating crate cube is still rendered.

http://i.imgur.com/ajkNDg0.jpg
Here is that same view, except the red textured brushes are normal geometry, to prove that the crate would normally not be rendered in this location.

These detail brushes are good for speeding up your Vis time by simplifying the PVS. They are NOT for reducing r_speeds. 
Ah 
I see. I was thinking that you'd somehow managed to create a semi-solid feature that is in Unreal Engine. 
Floating Point Texture Rotation 
Sure, will add that. Should be relatively trivial. Hint and skip are also on the todo list. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.