... dirtmapping... ok, I'm dreaming. Nevermind. 

didn't necros make some interesting progress on ambient occlusion a while back? 

tyrvis
---- TyrVis v1.0 ----
running with 4 threads
BSP is version 29
4040 leafs
10656 portals
Calculating Base Vis:
0....1....2....3....4....5....6....7....8....9....
Calculating Full Vis:
0....1....2....3....4....5....6....7....8....9....
average leafs visible: 181
c_noclip: 0
c_chains: 158170515
visdatasize:282459 compressed from 2040200
Writing BSP version 29
144.0 seconds elapsed
=================================

---- WVis 2.31 ----
Modified by Bengt Jardrup
Multithreading enabled by Willem

File: gmsp3v2.bsp
4040 portalleafs
10656 numportals
testlevel = 4
Using 4 threads.
average leafs visible: 176
max leafs visible: 518 near (384 2240 -768)
c_chains: 113742805
visdatasize: 270 kb compressed from 1992 kb

Elapsed time : 4:00
==========================================
qfvis

i gave up after 15minutes
--------------------------------

specs - i-760 -4gb ram -win7 x86 

average leafs visible: 181
average leafs visible: 176

That's interesting. I wonder what the difference is... 

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.