Spy, thanks! I guess that is a "i5 760", correct?

qfvis seems to get stuck (or it is ultra slow) for some reason, I'll tell taniwha.

I noticed that vis leafs difference too, different methods? 

"i5 760"

'c_chains' also look different to me 

could look really cool in Quake. I know valve added AO to the light compiler for CS:GO maps so maybe that would be somewhere to start looking? I have no idea :P 

That is interesting. I'm not aware of anything in my vis that should give a different result. It could just be a floating point precision thing, but I suspect it's more than that. I'll look into it at some stage, but it will be pretty tedious. 

I can't imagine that it's worth your time. :) Your VIS works, so be it... 

Maybe a moderator could update the post above, rather than a new annoucement?

Quite a few new features here, thought people might rather have some of this stuff now while playing around with Trenchbroom (func_group in particular):

TyrUtils v0.6 changes:

qbsp: respect floating point texture rotation and shift in map files
qbsp: support for Valve's 220 map format used in later Worldcraft/Hammer
qbsp: support func_group entities used by Radiant and similar editors
qbsp: surfaces with the skip texture are now removed from the compiled bsp
qbsp: hint brush support similar to Quake 2 for hand-tweaking the PVS
qbsp: fixed a problem where leak files were not written for hull0 or hull1
light: fixed a race condition in multithreaded coloured light processing
light: fixed bug preventing use of all 4 light styles in a common case
light: implemented attenutation formulae "delay" 4+5, ala Bengt's tools
light: removed old bsp30 support
light: lit files now automatically generated when coloured lights detected
light: implemented 4x4 oversampling with -extra4 command line
light: implemented the -gate option to help speed processing (default 0.001)
light: implemented the "_softangle" key for spotlights
light: implemented minlighting for brush models

Announcement
Download: Windows, Mac OS X, source. 

and thanks for supporting the Mac! 

I'll test out the new things today :) 

how do hint brushes work? do you literally just texture a brush in a texture named 'hint'? or are they func_hint? didn't see anything in the readme 

Yeah, just a texture named hint. I'll add something to the docs for that.

I need to double check, but as I understand it, skip means something different in Q2/Q3 (just a face that gets removed completely) and "caulk" is what we have been using as skip.

Should I make "caulk" to replace skip, make "skip" like the Q2/Q3 skip and add a command line option "-oldskip" so it can be backwards compatible? Hrm... 

That I finish this map... I have no idea how to optimise for Quake 1. I've just been throwing brushes all over with now consideration for how to make it run quick. (it's starting to slow down DirectQ, not fitzquake though).. 

I need to double check, but as I understand it, skip means something different in Q2/Q3 (just a face that gets removed completely) and "caulk" is what we have been using as skip.

So, currently "skip" in your tools is a face that gets removed once the bsp has been compiled. Skip in the Q2/Q3 sense would remove the face at an earlier stage - at what stage can this be done in quake bsp without breaking the compilation process and what would the uses of it be? 

That's me question too. Ideally, it would be best not to change the names of the commands this late. 

hmm... that is weird yeah, because q1 skip is 'solid nodraw' like caulk and skip in the q2/q3 sense was 'nonsolid nodraw' to be used with hint brushes.

a fine mess this has caused! 

Unless I'm mistaken then wasn't the only use of q2/q3 skip to flag all the non-hint faces of hint brushes?

If that is true, then it strikes me as redundant because I would have thought the better thing to do in that case would be to just detect if the brush has any hint face on it, flagging it as a "hint brush", and then just ignoring that brush for the purposes of building the bsp (except when using the hint face to create the splitting planes). In that case, the non-hint faces aren't used anyway, and therefore don't need explicitly flagging as skip.

Is there another usage of q2/q3 skip that i'm missing? 

Tyrann, you have earned 1000 of my finest golden manbabies for that recent update.

Still can't believe after all these years we've suddenly got a new suite of awesome, actively developing compile tools. 

what I think makes q2/q3 skip mostly redundant is that I believe 'trigger' does basically the same thing: nodraw, nonsolid, doesn't cut bsp faces. if hint and trigger play nicely in q1 (I haven't tested) I suggest we just do that. 

trigger don't do shit in q1. 

Ok, I don't think I'll mess with the skip convention now (all my fault!)

I might just make caulk also work the same and then add hintskip to be used as the non-hint faces of hint brushes. 

In my WIP map, it's pretty good for my moving platforms/doors... are you still working on phong shading?
Also, is the switch for func_group just -group? Is it supposed to work for brushes? 

No special switches needed for func_group - the brushes are automatically compiled into the worldspawn model.

I don't suppose there's any call for a "-nogroup" option? I couldn't think of a good reason. 

IIRC, a couple years back I found a weird tool-related phenomenon. I studied maps in engines that support locking the PVS to see how effective the culling was (some of my RMQ maps were pretty heavy and I was looking to optimize the vis blocking).

I remember comparing maps compiled from several different tools, and a few of them definitely had more effective culling than others.

Can't remember the exact differences (tools tested were at least hmap2, Tryutils and AguirRe's tools), but it's worth doing a test like that. You might be surprised.

Not sure how much use hint is in Q1bsp tbh - don't q1 tools generate more portals/better culling than eg q3map2 anyway? It seemed that way when I recently tested q1bsp vs q3bsp of my converted maps in an engine that supports both. The performance of the q1bsp versions was a lot better, while I had to manually insert hint portals into the q3bsp versions to make them run equally fast. 

I thought I was doing something wrong again (and I was, but it was a whole different kind of wrong!), not much of my hair left to pull out now! 

Is there any other way of setting light attenuation/fade than using wait and delay? I'd much rather use these two things for wait/delay than to set the radius etc for the lights.

For example, I have a button on my map that when activated moves a lift downwards (that has lights on it), by timing it correctly I could simulate the light source moving downwards and then going back upwards. However because the settings are tied to wait/delay it doesn't work properly... Does this make sense? 

I made a video showing what I mean... If you changed the name of the delay/wait to something else I could actually use delay/wait to make the light reappear when the platform returns, thus simulating a kind of real-time light effect. -

http://www.youtube.com/watch?v=MdvsJmjJw74