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.
Tyrann You Own! 
If anyone wants, I quickly added func_detail to my .ent file I use in Radiant 1.5 
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 
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. 
I'm don't know much about Radiant, but it should be possible. Hopefully someone else here can answer that one. 
Hehe, ouch, yeah that kinda sucks. But I'd definitely be interested to take a look at your implementation when you're done. 
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. 
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. 
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) 
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 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. 
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). 
Oh, I never realised QF had that. I'll definitely take a look. Bill writes nice clean code! :) 
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...
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)
Here you can see that that the PVS does not consider the func_detail brushes, as the floating crate cube is still rendered.
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. 
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. 
will need to play with this on the weekend! 
Is there a way to put in some kind of occlusion brush in the same way that water used to be used before watervis? 
Floating Point Texture X/Y Offset, Too 
To keep Scampie's texturelocked trims aligned. 
Is great. Thanks Tyrann. 
This is great news (I do still compile Quake 1 maps occasionally). I will add a link to your tools to my tutorials once they support the full monty.

Actively maintained tools are basically the lifeline for any kind of modding. Thumbs up. 
Mac OS X Binaries 
I'll look into providing binaries for Mac OS X, would you like to host them on your site? 
Mac OS X 
Thanks SleepwalkR - I was meaning to do that anyway so I've just done a quick build on my ML machine and thrown that up on the utils page. Does that look ok?

Any tips/advice for providing OS X binaries appreciated. I'll hopefully be doing the same for TyrQuake with the next release. 
Awesome Stuff! 
Will definitely give these a whirl next time I compile a map.

Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :) 
"After it took 36 days for my map to vis on a fairly decent 8-core machine I knew it was past time that we had something like this for Quake."

How long does your map take to vis now? Have you detailified it yet? 
Maybe it's just fantasy, but I'm hoping there is also going to be a map release from you this year... :)

I thought the same. Might go replay moonlight. By coincidence was looking at OUM the other day as well. 
Have Not Detailified It Yet... 
...but working on it. 14k+ brushes! :) 
Wish List 
* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast.

* Phong Shading on grouped brushwork. This would be awesome for terrains where the lighting is consistent across surface edges. It is difficult at the moment to create terrain wall sections without obvious light seams.

* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses. 
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.

That's an engine issue I believe. 
If we even got the first 2 things on Socks wishlist that would be incredible. Is that even possible though? 
Ai Clip 
This is a C/Qc issue caused by the hull navigation.

You can solve it with an entity called a func_nodraw from the extras mod:

Coding one from scratch should be trivial since you just set the model to empty on runtime, I think.

All it does is make a solid brush that you can't see. It's not ideal because you can't shoot through it - but that's the limitation of Quake.

Minlight for entities would be awesome. Q2 has this and it makes life a little bit easier every time you add a door to a map. 
<quote>* Brush models (func_ entities) can have a minlight value so that there is no solid black surfaces. It is easy for a secret door to have a solid black surface on the opening edge, which is difficult to get rid of. No one wants to minlight a whole level but certain entity types could benefit from a minlight boast. </quote>
Ooh, nice idea! That would be mega useful. 
Fucking tags. 
* AI clip brushes, a surface that is invisible like clip but can block AI/Players. At the moment all floor gaps need func_wall entities so that AI can walk across the gaps properly. For some reason clip brushes are not in the clip hull that the AI movement code uses.

To be more specific about what the map compiler does which causes problems - the clip brushes get added to hull-1 (player size) and hull-2 (shambler size), but not the visible hull or hull-0 (point sized). I'm pretty sure that the visible hull and clipping hull-0 are stored separately in the BSP (but please correct me if I'm wrong).

If that's the case, then it should be possible to create clip brush variants where the brushes are considered in different stages. So for example super-clip brushes would be skipped at the visible stage, but included in hull-0 to hull-2, so grenades bounce off them and monsters can navigate them. It certainly ought to be possible to create sub-clip brushes which only affect hull-2, to prevent large monsters getting into parts of the map but allowing players in. 
It's "mangled Tags Monday" 
Get in 
Entity minlight - Easy. Will add that.

The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses. 
Phong Or Some Kind Of Smoothing 
It should be doable, but the information about which brushes are grouped are lost after the BSP has been produced, so can't use that as a basis.

A tweakable command line parameter (or worldspawn key) to set the maximum angle between two surfaces to consider for phong shading/smoothing should work and I believe there are Q2/Q3 tools that did this (though I forget the name now). Could also restrict it to faces with the same texture as well if that seems like a useful thing to do. 
recommend you call it "_minlight" since the engine automatically ignores keys that start with an underscore (this is so you can add new fields for the compilers that don't have to be in the progs.dat definitions list.) Otherwise players will get spammed with "minlight is not a field" messages. 
Phong Shading 
Hmmm...some way of specifying it to only use phong shading on faces that use certain textures might be a good idea...

Whilst we're all in crazy wishlist mode - what about an option for brush entities to cast shadows (on the world and other brush entities) 
@Tyrann, doing phong shading on surfaces with the same texture would be awesome. Another option is to use a keyword in the texture name. Maybe you can specify the keyword as a parameter.

Example command line : "-phong terrain" Textures containing the word "terrain" have phong shading applied to their edges.

Having the _minlight key on any entity would be awesome, I can think of plenty of situations where that would be handy. 
Phong Shading Texture... 
Or have it identify with certain texture names? Like how fluids begin with an * or animated textures begin with a + ? 
If we have phong shading and minlights we could emulate Quake 3's shading on curves really accurately? This would be amazing! 
aguirre's tools have the anglesense parameter, maybe that is related? 
I already use anglesense, but unfortunately it is applied to everything which makes it difficult to fine tune. 
Faking Clips 
The AI clip thing, don't think it's possible. The thing is that Hull0 *is* the visible hull. There is no separate clipping hull for point size entities, they use the same bsp tree that the renderer uses.

Ah, was worried you'd say that. Still, if we can have brushes that are both skip AND detail, we can fake it. Imagine we're just trying to create 1 solid transparent window in a visible square frame. On the front of the frame we make a square based pyramid, so that the four vertices of the base meet the vertices of the frame, and the point of the pyramid points backwards.

This brush doesn't clip away any of the inside of the frame, because it only touches the edges of the other surfaces. Make it skip and you've got an invisible hull-0 face. You can already do this much with the existing skip tool.

Naturally the next thing would be to make another brush on the back of the frame, so the window clips correctly from both sides. The problem to date is that sealing the area on both sides causes it to be clipped away. Even if one side is left open, VIS believes the skip brushes are opaque and starts culling the inside of the frame when looked at from the front. I think that making these brushes details as well as skip ought to fix both problems at once - but I should probably put my money where my mouth is and try it! 
Nice Idea! 
Preach: yeah, I think that might just work! :) 
you can specify it per light entity, not only globally 
Is it me or Wine or does this vis totally kick wvis' ass?

I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes! 
Let's do some benchmarking in any case, I always wanted to do that. 
Damn link abbre.....

That link above invites you to run some VIS on gmsp3v2.bsp and has a table where you then can add your numbers. 
[quote]I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes! [/quote]
Srsly? Damn, that's great! I wonder what he did to his version ... whatever it is, somebody pour more in. :) 
Jesus FUCK with this non-standard tags...

I just vis'd EvilExhumed.bsp in 70 seconds with this vis, but with wvis in wine it took 12 minutes!
Srsly? Damn, that's great! I wonder what he did to his version ... whatever it is, somebody pour more in. :) 
I added qfvis and bjp to the wiki page.

Could someone make a bat file that runs it all without the need for interaction? The only parameter the user has to supply is the number of threads for qfvis, the other tools pick them themselves. 
Is this some additional thing on top of normal vis? If not you could run it with necros compiling tool without having to mess around with batch files? 
If some Quake 1 tool gets phong shading, Q1 mapping would suddenly look more attractive again.

Higher resolution lightmaps? :-p 
... dirtmapping... ok, I'm dreaming. Nevermind. 
Ambient Occlusion!! 
didn't necros make some interesting progress on ambient occlusion a while back? 
---- TyrVis v1.0 ----
running with 4 threads
BSP is version 29
4040 leafs
10656 portals
Calculating Base Vis:
Calculating Full Vis:
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

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 
Average Leafs 
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... 
TyrUtils V0.6 
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

Download: Windows, Mac OS X, source
Good Stuff 
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... 
God Forbid 
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! 
Q2/q3 Skip 
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. 
Wait I'm Dumb 
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. 
Using Minlights! 
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 Should Have Asked Sooner... 
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! 
Simulated Real-time Lighting Effects 
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? 
Simulated Real-time Lighting Effects Part Deux 
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. - 
Do those keys even work that way on lights?

Another way to do it is to trigger via a trigger_relay and set the delay on that instead. 
I'm Using... 
trigger_multiple to trigger both the platform AND the lights.

I'm pretty much a newb when it comes to the more advanced triggers so I don't know if the delay/wait was used for attenuation for some technical reason, I thought it was kind of strange.

I'll try and figure out how to make the trigger_relay do what I need it to do. 
The use of the wait key started with Argh!lite many moons ago. At the time I don't think the community realised that any key starting with an underscore would be ignored by the engine, so we tried to grab existing keys that were unused for lights to avoid engine warnings. 
only works if I could allow the trigger_multiple to trigger multiple targets (ironically).
So it could trigger the platform & the trigger_relay, then the trigger relay resets the light (but NOT the platform as it has a different name)...

I just tested it and the trigger relay ends up infinitely resetting the platform/lights. 
Ok after a bit of web research it looks like I'm right in thinking that it wont work without multiple targets. Although RMQ seems to support this feature...

".target2, .target3� : Multiple targets

As in Quoth and Custents, you can trigger more than one target now with a single trigger. You can have up to six targets and two killtargets."

Bah, I was going to make a quoth version anyway at some point... I suppose I could make a "plain" version for standard quake for the time being. ;) 
RMQ (and Quoth and Custents) are mods which is why you get additional functionality.

Since this is your first Q1 map (?) I would caution you to stick to normal quake until you get comfortable with how entities and the engine interact.

Or jump right in... my first release was a mod. It sucked though, so not a great example. 
I'm a serial offender for not finishing maps... though I usually run out of steam/patience about now but TrenchBroom is continuing to be enjoyable.
My first actual level for Quake 1 was a trench-warfare style map I made in the 90's with an editor called Thred. It really sucked hard.

I'll make two versions, one for quake and one for the quoth mod. I thought of some really cool scripted ideas last night that I could set up with the relays. 
Please make the utils output a trailing newline! Borking the terminal is annoying. 
Might be the marksurfaces maybe?

$ wine bjp\ May\ 2006/Bspinfo.exe -prt cda.bsp
---- BspInfo 1.27 ---- Modified by Bengt Jardrup

10439 planes 208780
33815 vertexes 405780
13782 nodes 330768
12871 texinfo 514840
26848 faces 536960
27641 clipnodes 221128
7878 leafs 220584
35183 marksurfaces 70366
119544 surfedges 478176
63331 edges 253324
137 models 8768
138 textures 1667656
lightdata 835596
visdata 1380694
entdata 71148

WARNING: Marksurfaces 35183 exceed normal engine max 32767
5238 vis leafs
18510 vis portals

$ vis cda.bsp
---- vis / TyrUtils v0.6-5-gd6ef234 ----
running with 4 threads
BSP is version 29
5238 leafs
18510 portals
Calculating Base Vis:
Calculating Full Vis:
0..************ ERROR ************
CheckStack: leaf recursion 
base vis finished without problems of course, stupid func 
Could you support the -noambient, -noambientwater, -noambientslime, -noambientlava switches?

These remove the markers that get applied to visibility areas that cause quake to play the sky and water looping sounds. 
Lod Experiment 
I had done a small map using textures from Sock's website. Totally too much detail for vis.exe. Now with func_detail it works. vis in 135 seconds! Looks good, texture alignment stayed correct.

Gone are the days of poorly lit func_wall for details.

Tyrann Thank you

I'm sure your tools will cause more work for everyone with a WIP map. 
I haven't had to chance to really see func_detail in action yet, but your shot shows it off well (or rather doesn't show) since I can't tell what's detail and what's world. :) 
Spirit: Thanks, I'll try to reproduce the error tomorrow and fix.

necros: sure, will look into that.

mechtech: looks nice! 
Func_detail Test 
Textured normal

Shows what I used as func_detail

Vis on this room would be useless. func_detail lets the mapper choose to not vis areas that are not occluded. 
"It's very pretty, Bishop, but what are we looking for?" 
Hammer Wad Format 
Hi Tyrann! Thanks for putting the new version together with map 220 format support. I've tested the scheme I outlined for creating a solid, invisible window and it does work!

Unfortunately I have generated another feature request in the process...the Hammer editor works with a different wad format at the same time as map 220 - basically so it can have full colour wad files. So when I go to compile my map, it can't use any of the wads. My cunning plan to use a batch file to swap the wads for Q1 format ones didn't work - Hammer locks those files while running. So I am reduced to begging for more features, sorry to say. 
@Preach: didn't seem too difficult; care to try out this snapshot and let me know if it's okay? (I don't have any such files handy) 
CheckStack: Leaf Recursion 
@Spirit: BJP tools have the same problem with this generated .PRT file, except the BJP defaults to "-level 4", where I default to "-level 1". I suspect it's just a bad bsp->prt conversion job.

I wonder if you were specifying "-level 4" earlier when benchmarking, because that could explain those differences too.

I should probably default to -level 4 too. Any objections? 
Aren't level 1 to 3 mostly broken? 
i could swear it said level 4 when I ran it without arguments. will check later. 
Vis Test Levels 
I think the -level thing may be numbered wrong.
-level 4 takes 95 seconds. -level 1 was nearing an hour before I quit. I checked the .prt file and found the prt2 header.

my original test was done on -level 4 so maybe func_detail isn't the fix I thought it was.

Maybe I did something wrong checking.... 
It's Unlikely Tyrann Would Mix Them Up 
On some occassions, level 1 can take longer than level 4 indeed. 
All Good Then Thanks 
Wad 3 (.hlwad) 
I'm having the same issue with Hammer 3.3. When I compile using your qbsp the editor spits out an error message saying that the wad is not a wad file and the level compiles with no textures at all. However when I use another BSP tool (TXqbsp) the problem goes away and all is right in the world again (only with none of the extra features like detail brushes (which is why I switched over to your's in the first place.

The link to the snapshot above is borked so I can't try it. 
What Happens If 
You use an actual .wad file version of the .hlwad file for compiling?

In other words you have quake.hlwad and quake.wad in the same DIR, where they both have the exact same textures inside. 
I do have both in there actually as a matter of course. That way if I wanted to change the .wad using TexMex I could change both at the same time. 
This is hacky - but if you load the .map file into a text editor, you could check that the path of the wad is set to blah...yourwad.wad wather than blah.....yourwad.hlwad.

I'm speculating here, but that might work?

It might not work either, IDK :P 
I Gave That A Shot... 
and hammer ends up changing it back to .hlwad in the .map file. Even when I don't save or export after I made the changes from .hlwad to .wad. 
Drive Or Text Editor 
Hammer adds the wad info without drive letter.
You could have the HL version on drive c: and the Q1 version on d: with the same path naming.

"wad" "\quake\qconverter\sockq.wad "

Or text editor Hammer uses sock.wad I just change the "wad" entry to sockq.wad.

Hacky yes 
I think the -level thing may be numbered wrong.
-level 4 takes 95 seconds. -level 1 was nearing an hour before I quit. I checked the .prt file and found the prt2 header.

my original test was done on -level 4 so maybe func_detail isn't the fix I thought it was.

Maybe I did something wrong checking....

No, that's what I meant about it being broken. You never ever want to run -level 1 to 3 because they take longer and are not as good as level 4. 
Hi tyrann! Tried to download from your link but it's 404. I also tried to second-guess what was wrong and go to:

That gave me a 403 error instead. Ready and willing to try it though! 
Poop, it really did not default to level 4 indeed. Yes, please change that!

spy, necros, DrLabman, please re-run and update the table. ;)

Still fast! 
Using .wad Vs .hlwad 
So it works fine from the command prompt and regular .wad files after I changed the .map file to remove the hl from hlwad (that was the only changes I made to the .map file using notepad). So as near as I can tell the issue is in being able to read hlwads (WAD3 I do believe). So worst case situation I guess I can make something in Hammer, and then turn what I can into detail brushes once it's close to being done.

I will still make a shit map though... so there is that. :P 
Fixed Snapshot Download 
Sorry about that, b0rked the original link and had a directory permissions problem on the actual upload as well. More coffee next time! :) 
wad3 working Thanks again 
I concur. And that detail-skip thing now works perfectly, for entity-free glass in maps. 
Preach- can you elaborate? Been out of the scene for a while- how would I use these tools to get entity-free glass? 
Glass Demo 
Here's a demo map:

The trick relies on a "detail" brush which is "skip" textured (which wasn't possible before tyrann's compiler). Skip prevents the brush from being rendered, and detail keeps it out of visibility calculations.

We start with a frame for our glass built out of regular brushes. A na�ve attempt would build a single rectangular detail brush to fill the frame and give it the skip texture. The problem is that the insides of the frame will still get clipped away by the detail-skip brush, so there's a visible gap in the level.

The fix is to build our detail-skip brush in such a shape that it doesn't clip anything away. In the example map each side of the window pane comes from a different brush. Each brush is a square-based pyramid, with the square face exactly filling the frame of the window, and with the apex of the pyramid sitting in the space inside the window (we don't care too much what happens in there because it's out of bounds).

You could pretty much do this already with just a func_wall covered in skip textures, the innovation is that you don't use an entity any more. In theory this also makes the trick mod-neutral, although in practice mods which don't support func_wall are vanishingly rare. 
DM/SP Only Walls... 
I can't figure out how to make walls only appear in SP or DM only. Any ideas? I've tried to change the check the DM spawnflag for invisible walls (as a clip brush entity) but it clips no matter what mode. 
Ah, I see what you mean, thanks for that. I thought you meant glass as in semi-transparent, not a see-through solid, like apsp2 which appears to just be relying on wateralpha and a gray textured liquid turned func_wall. 
Fixed the issue for myself as well. Thanks Tyrann! 
I suppose that you could also use the skip\detail trick to apply a shadow with no obvious source like the Quake symbol in e1m3 (I think?)instead of making a skybox and then tying func_illusionary to a sky brush to hide it. 
Not sure I understand the issue, but if its a func_wall then NotDM should work no problem.

The inverse is applying the easy/medium/hard flags.

Could be that the detail faces are added to the map regardless of any entity controls though. 
I set the spawnflag for the func_wall as 1792 but it refuses to compile. I'm trying to make it so that the level will work in both SP and MP like the original Quake Maps did. Here's what happens when I compile - 
It leaks. Just guessing, but I think this is the issue - func_walls don't block vis, so you can't have them between you and the void, only solid brushes can be your level structure. 
For some other reason the leak is causing the bsp not to be built. 
Can't Be So! 
and the reason I say this is that it gives the leak errors on successful compiles (the map isn't finished yet and there are areas open to the void).

I think there's another problem at work, I'm using spawnflag 1792. 
You can't have funcs consist only of clip brushes - there need to be visible brushes (i.e. brushes with visible textures, skip works too) to define the models' boundaries. Add a small brush in the bottom left corner and another one in the top right corner in order to determine the entity's length, height and width. Those brushes should to be outside the actual room (inside floors/walls) so they aren't visible. Of course you can also make a frame around the whole wall and have the clip brush inside. This will create a dynamic wall which blocks players and monsters, but not shots and visibility. 
well it's a shame then, I'll probably have to find another solution to the problem. I'm not sure exactly how this works because I have a platform which has clip brushes on it that works, but when I tried to block off the doorway in the same fashion it doesn't clip. 
he means you can have clip brushes in func_items, but only if you have textured brushes within the same entity. hence the clipped plat working (whereas a plat made entirely of clip wouldn't work) 
Clip Entities 
Hmm, I will have another look at that to see if it can be made to work. If all brushes are clip then there will be no brushes for the entity in hull 0. There's probably a way to make that work...

Are you sure you want a func wall that blocks movement but not bullets? That's what clip will do. 
the reason being is that one side the corridor will be blocked off by boxes to the level (for deathmatch) but on the other side will be the singleplayer entrance. It's not even a big deal, I thought I could make it dual-function but it's not like anyone really plays DM that much these days. 
Doesn't Matter 
I've made duplicate brushes for the doorframe and put the clip brush in the middle and it seems to work now. A weird solution to the problem but it works so I wont need to release the same map twice. 
I think it happens because the bounding box is based on the visual model when it is loaded by the engine, and the engine only checks collision within the bounding box. 
Sort of, but I think qbsp actually generates the bounding box. And the engine just accepts what qbsp generates.

I tried fixing this in the bmodel loader in fitzquake but it never seemed to work quite right and i moved on to other things. 
You can find my attempted fix in the fitzquake source as Mod_BoundsFromClipNode(), which is currently commented out because it didn't work. 
Yes, I think it's not possible to fix the bounds in the engine because the necessary information was thrown away at compile time. The fix in qbsp is actually pretty trivial. Fixed for TyrUtils version 0.7. 
Clip-only Entities 
@FifthElephant: Give this snapshot a try. 
Running light on a very small map as a test. -extra works fine but...

* Could not execute the command:
"C:\Program Files\Worldcraft\quaketools\tyrutils-0.6-35\bin\light.exe -extra4" "c:\quake\id1\maps\h1b"
* Windows gave the error message:
"The operation completed successfully."

I... I... I just don't know what to say (the operation completed successfully is an error? WTF is THAT all about? I think Windows is drunk again). The map then loaded just fine in Quakespasm minus light being run at all (fullbright). So then I tried -soft 2 and had the same result. Just to narrow it down I ran just light on the compiled .bsp using the command prompt bypassing WC 3,3's automatic compiling and it worked fine. I don't if that's something that you can fix or not but I thought I'd mention it. The extra features are very nice though.

Wc3.3 set up using the Quake Adapter. Your light v0.6.35 (the last snapshot that you put up). Note that -extra worked just fine using WC's compiling console. 
Ok, that's pretty odd. Can you paste that info into pastebin so it's not cut off on the board. Not sure if you somehow had quotes around the util and the command line parameters, which would cause problems. E.g.

"light.exe -extra4" "C:\...\blah.bsp"


"light.exe" -extra4 "C:\...\blah.bsp" 
Ok. I forgot about F_M's cutting off of long paths. To recreate it was:

In Worldcraft 3.3 what I did was to go to:
Tools > Options > Build Programs > RAD Executable and put in (spaces are added before each "\" for here):

C: \Program Files \Worldcraft \quaketools \tyrutils-0.6-35 \bin \light.exe

This is what WC normally generates in it's built in compiler when you set it up and it works just fine.

To that I added [space]-extra4

Then I went to File > Run and made sure that the extra option was turned off (normal was ticked instead) And it failed to generate a lightmap and gave the warning that I mentioned above:

* Windows gave the error message:
"The operation completed successfully."

In the WC window that normally appears during a compile.

The same thing happened with [space]soft[space]2

It worked fine when I used the command prompt. Just to be clear here's what I did in that case:

I made a separate folder named c:\Qtest and copied the map named h1b.bsp and your light.exe as well as the related .pts file just in case that was an issue (the map itself doesn't leak but better safe than sorry right?) and ran light in the command prompt using:

CD: C:\Qtest
light.exe -extra4 -soft 2 h1b.bsp

on it and it worked just fine.

The map itself is very small with only a few entities, none of them outside of the vanilla Quake standard except for one (multiple brush item) func_detail that works just fine (that's why I was playing around with it in the first place) and a light that has "no falloff" selected in its properties. 
I should add that [space] is just a space and not actually entered as [space]. 
Batch File 
I just got things working in the cmd window and made a batch file. I find it easier than using the hammer compile setup.

An interesting thing I found today. Works on win7 with multi core cpu.

c:\windows\system32\cmd.exe /C start /affinity 1 yourbatfile.bat
Uses processor 0
c:\windows\system32\cmd.exe /C start /affinity 2 hammer.exe
Uses processor 1

Could be used to build your map on one cpu and hammer on the other. You could compile and use hammer without making it too slow.

Just an idea 
that's cool, i usually just go into the task manager and remove a checkbox on one of the cores.

i should build something like this into the compiling gui. 
You could also right click the VIS process and set it to a lower priority. That way when you're using Hammer, it will fade into the background and when you're not it will get Windows full attention.

Or it should work that way, anyway. 
yeah, I do that too. :)
That's actually better because windows will manage the priority itself so when you aren't doing anything it's using closer to 100% instead of ignoring a core completely. 
I could make vis set it's worker threads priority to low by default.

@quaketree: the problem seems to be with Hammer launching the light utility, not the light utility itself. If I get time I'll try set up Hammer here myself to see what's going on. 
That's what I kinda figured, I only mentioned it here so that you could put that into your light readme as a known issue with Hammer and those extra -commands if you wanted to. 
Just go to "Below Normal". I think if you go to "Low" it starts to only get processing when there's NOTHING else to do, like OS or anything... 
Feature Request... 
I haven't had chance to look at the clip entity snapshot, sorry Tyrann (I solved it by messing around with brush shapes, ironically I might not even need it now since I have expanded my idea).

Anyway, is there any way of getting water to not be fullbright? Is it possible to get them to accept light and shadow? 
This Goes For... 
slime and lava too... maybe lava should always be fullbright, but then why not just use _minlight to achieve this? 
I believe (and someone correct me if I'm wrong) that they are handled by the engine and not the compiling tools as far as fullbrights are concerned. The only thing that gets done by compilers is to create a vis\bsp portal (not unlike a hint brush) unless you use -wateralpha (or whatever that command is in some qbsp programs) to make it transparent which simply removes the portal and in some cases takes away the fullbright. 
what quaketree said. engine is responsible for the 'lighting' of water (and sky). 
Tyrann: you are awesome.

just in case you didn't know. 
Cheers For The Info! 
Doesn't -transwater affect performance? 
It does insofar as it makes the water surface not block visibility, so everything beneath it is being rendered whereas it would've been visblocked if compiled with opaque water. Depends on how much additional detail there is underwater. 
Lighting Water, Lava, Etc. 
Hmmm, it may just work - it looks like the software engine might actually render the lightmaps if the light util generated them. Not sure about glquake. Surface subdivision might cause problems. I'll try an experiment. 
Yeah, it appears it can't be done with tools changes alone. Oh well. 
Cheers for looking into it! I still haven't checked out the latest snapshot... probably will do for the next map since everything is stable and I'm close to finishing... 
Too Bad. 
Tyrann, do you think that it's possible to make a *liquid do what a sky can do in regards to sunlight only upwards instead? Particularly ones that start off with *slime and *lava? At least then it would make some visual sense that they are fullbright. Obviously they would need .lit support and wouldn't be on by default. Maybe put it in the worldspawn. _mangle support might be nice if someone wants to do something funky in their maps. Just a thought. 
Lava Light 
Yeah, I've been thinking about making it possible to set a global lighting level to emit a glow from lava/slime/water surfaces - separate values for each type though. Wouldn't be directed via mangle, but using sample points along the liquid surface.

Shouldn't be too hard but would want to make sure of consistent light levels above and below the water and will need to see how much performace impact it has. 
No mangle is fine, I was just thinking that someone might find some uses for that somewhere down the line is all. Thanks for the answer. 
Maybe you could allow users to set up a file called surfacelights.txt or something that contains a list of textures that should emit light? Maybe it could be defined in a worldspawn key? In addition, having separate support for _lavalight etc. in the worldspawn would be cool. It gets a bit messy if you want to support multiple textures and use different colours, attenuation formula etc. Perhaps it could be set up in a text file? 
I had used Q1rad worked well, the effect was cool, then it broke when the map got large. Maybe light emitting textures could be done with a separate util then appended to the light map. Keep the light program on target without adding more complexity to it.

My ability to write code is limited to cut and paste so ignore me as needed. 
The version of the tools I'm using doesn't support -noambient to disable sounds applied automatically to skyboxes/water volumes etc... I've resorted to using the vis compiler that is coupled with quake adapter worldcraft. Is there a commandline option I am missing on your version? 
Yeah, had it on my todo list but had not gotten around to it yet. You can be my beta tester! 
Brush Entity Shadowing.. 
Not sure this is always desirable. Is there a way to turn off shadow casting for brush entities? It may seem like a weird request but I have a moving platform on top of a kind of cylinder and I don't want the mover to cast a shadow under it. BTW, I've made good usage of _minlight for brush entities, it's a nice addition :) 
the vis I'm using has options for -noambient, -noambientslime, -noambientlava etc etc. 
Brush model shadows should be off by default - they should only cast a shadow if you have added the "_shadow" key.

Those noambient options are what I just added to vis in the snapshot linked above. 
Ah Ok 
I did open the file and only look at the changelog, not the main text :P 
I've had a look at it. The -noambient switches work, but I get CutNodePortals_r: New portal was clipped away messages now that weren't there with TreeQBSP, also it's now saying I have a leak again even though I had fixed all my leaks in TreeQ. Could do with a -noents option so that I can use pointfile to find whatever is causing the problem (the pointfile particles are all outside the map again, grrr!) 
Try adding -particles 1000000 to the quake engine command line just in case you're running out of particles for the pointfile. 
It's not that, it happened with the previous version too. It just displays a line of particles completely outside the map.
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities. I'm probably going to stop farting around with different compilers for this map now otherwise I'm never going to get it finished :P
(I have like 3 other maps I have started and need to get done too) 
Ah, ok - I thought you meant it was not pointing at an entity at all. I'll look at adding that option. 
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities.

Having entities that are accessible to the void is the definition of a leak. So you should probably not have entities outside the map (brush entities are okay, point entities are the problem) 
The point is that I can't verify if it's a bsp leak *or* a void entity if I can't -noents, besides TreeQ and vis aren't signalling problems, just Tyr's latest version. It's all a bit weird to say the least.
Kind of having a problem with degenerating brushes for my terrain too, it's really odd. I'm losing interest in the map now, need to get it working as best as I can so I can move on. 
This Might Be A Result 
of using double precision floating point numbers in Tyrann's tools. It snaps vertices to integer coordinates if they are off by less than 0.0001, whereas TreeQ snaps them if they are off by less than 0.001. So if you have two vertices which are off by, say, 0.0005, they will be snapped to the same position by TreeQ, but not by Tyrann's tools. The result could be a microleak I think. 
You're Obsessed.. 
with microleaks! ;)

I'm using TreeQ atm and I'm still getting weirdness. It's probably due to me using cubes rather than triangles for this tri-soup business. Honestly I'm fairly clueless, but the map seems to be holding up ok... just hope people don't laugh too much at me when I release the .map file! 
If You Send Me The File 
and indicate which brushes (line numbers) cause problems Incan probably give you a hint on what is going on exactly. 
I know exactly where the weird brushes are in the current iteration of the map, but it's stable and vising properly (except if you noclip to the bottom there are tiny little rooms between the brushes).
Honestly it's just the way I've done the terrain. I'm not redoing the whole thing a third time as triangles now, it would probably drive me to murder. I thought of another possible way of doing the terrain just as I went to sleep last night but again I just want to get the map out as long as it vis's right now. 
I'm Not Asking You To Redo It 
But it would still be useful for me to see where what TB shows you differs from what QBSP will produce. 
you an email with the file with an explanation. 
On one map world brushes dont showing up (if they are compiled at all, not sure)- only funcs show up;
other compilers (txqbsp, hmap) compile same map fine.

Func_detail usage creates pretty much broken PVS.

Made in Netradiant. 
Brushes Disappearing 
confirmed: happens when you move brushes between ents involving func_group, moving back to world doesnt help - they still dont get compiled, but moving to other funcs makes them appear.

As said, other compiler do fine
and probably cause netradiant leaves empty brush ents in .map

"classname" "func_group"
// entity 230
@slapmap: Weird. Can you send me a .map which shows the problem? 
This is something in bjp tools that I always used. Your light says it is not supported, though the lighting doesn't seem very different.

Also, I had an error about a missing face if I used light after newskip, but not when I used bjp light. Does your bsp support skip now, because if it does, I guess I can probably just switch. I'll probably want it for detail brushes anyway :)

_selfshadow and _shadow are awesome though! Thanks! 
@slapmap: Thanks for the test maps. Should be fixed now - try the new snapshot

@than: Yeah, my qbsp supports skip but I only just looked at newskip now and realised that it has water/slime/lava skip as well. That shouldn't be too hard to add. Will look at what is going on with lighting newskip'd maps... 
@than: does this give the expected results?


It's not 100% identical to the bjp tools when it comes to treatment of "local minlights", but it should otherwise just make minlights additive. 
thanks for that. I'll try to test it as soon as I can. 
I tried -anglescale (and -anglesense) 0.01 and 0.99 and sunlit area looks identical. Shouldn't it be dimmer with higher value or faces hit at non 90deg? 
@slapmap: oops, missed setting the sunlight variable from the command line. This should fix it: 
-gate N 
does this actually work? I was experimenting the other day with setting it to really high amounts to see the effect... and even at "-gate 100", there is nothing apparent. My assumption would be that this would make the map very dark with harsh cutoffs. Am I confused on how this works? (I understand that it's intended to be used with very low settings)

Using the released 0.6 tools. 
should work - only affect 1/x, 1/x^2 lights though. Doesn't affect lights with the default linear falloff. 
Updated to affect linear lights as well in the next release (which I should do soon). 
Updated to affect linear lights as well in the next release (which I should do soon). 
Hmm, I still get no visible difference, even took screenshots - nothing. Sunlight is even no matter what value I use

I use "light -anglescale 0.xx"
to compile.

Again, thanks for quick updates 
I get a clear difference here - what keys are in your worldspawn entity?

-anglescale 0.5 (default)

-anglescale 0.0 
"light" "10"
"_sunlight" "110"
"_sun_mangle" "300 -65 0" 

Those keys look okay. Just check the light.exe output and make sure you're running version 0.6-53-gee2dc38. Otherwise, if you email the .map to me I'll try it here and see if I can tell what's going on. 
Transwater And Vis 
Would it be possible to have separate vis for water,slime and lava? This way you could have a controllable form of occlusion culling to help keep r_speeds low. 
Would Need Engine Support? 
r_wateralpha applies to all fluids, so you'd need to have some engine cvar that applies only to water in order to use that properly, otherwise you'd get HOM effects on the lava and slime that were blocking vis if their surface transparency was using the wateralpha setting :/ 
TyrUtils V0.7 
Nothing too earth shattering if you've already been using the snapshots, but if you're still on v0.5 or v0.6, there are some nice worthwhile changes:

* Unix man page documentation for the main tools (qbsp, light, vis)
* HTML and text documentation is generated from the man page sources
* qbsp: added support for using WAD3 texture wads used by Hammer
* qbsp: include clip brushes when calculating bmodel bounding box
* qbsp: enable creation of clip-only bmodels
* qbsp: recognise and remove *waterskip, *slimeskip and *lavaskip surfaces
* qbsp: added hintskip texture support
* qbsp: fixed some bugs parsing empty func_group/func_detail entities
* light: implemented self shadowing and full shadows for brush models
* light: implemented the "-soft" command line option
* light: implemented the "-addmin" command line option
* light: implemented the "_anglescale" (aka "_anglesense") key and cmdline
* light: remove support for negative color components (never worked properly)
* light: removed the "-nominlimit" option (now the default behaviour)
* light: removed the "-compress" option (a bad idea from long ago)
* light: make -gate command line affect linear falloff lights as well
* vis: changed the default testlevel to 4
* vis: added the '-noambient*' options to disable auto ambient sounds. 
Compile Errors 
So I decided to have a look at using your tools for making my deck remake into a singleplayer level (along with using the new version of trenchbroom) and all I get is constant errors about leaks that weren't present when I used TreeQ to compile the map.
I've tried to fix verts and such but to no success, the pointfile doesn't point to any leaks... 
To save Tyrann some time, can you send him the MAP file so he can debug it? :) 
Ok, I've forwarded the email that I sent to SleepwalkR as that contains the details. I've included the .map, the .log and the .pts file. Doesn't seem to point to anything with the confines of the map. Bear in mind that this fully compiles using TreeQ, I'm not sure why it doesn't compile with your new tools because I'm not so familiar with mapping for quake. 
Tried Hammer 
I loaded the .map included in the download in Hammer got 20 brushes that could not be loaded. the missing brushes cause leaks. Loads fine in Trenchbroom and compiles without leaks using Txqbsp.exe 
Did Hammer say anything about why those brushes could not be loaded? 
Brush Line # 
Hammer gives no usefull info

Any way to get the map line number from selected brush? I found the missing brushes but how to pass on the info. 
Changed the texture in trenchbroom and saved. As long a brush order was not changed on save. brush starting at line# 15116-15127 and 15128-15139 are two that will not load in Hammer 3.4 build 2363 
Thanks, looking at it now. 
Wow, this is an interesting one!

There are some odd plane definitions, just off the grid like this one:

( 55.9998779296875 103.99990844726562 -72 ) ( 80.00042724609375 128.00054931640625 -72 ) ( 55.9998779296875 103.99990844726562 -88 ) tech04_6 0 0 0 0.5 0.5

But the pointfile my qbsp is generating looks like complete garbage. Might take a while to work it out, but I think it's worth finding out exactly what is going on. 
I only ever bring problems to the table, I'm kind of a jerk like that. But at least you have a complete maniac messing around with all these tools, should make for fun times! 
TB should round the plane points if they're this close to integers. OTOH, the way the vertices are generated, small changes to plane points may yield big changes to vertex positions. 
Can't Bsp A Map That Compiles Fine With Other Tools :/ 
Getting this error:
---- GrowRegions ----
*** ERROR 43: Internal error: entity->iVertices > entity->cVertices

I'll mail you the map if that's ok? It's made in Worldcraft by the way. 
Light Not Working For Me 
---- light / TyrUtils v0.7 ----
running with 2 threads
BSP is version 29
using minlight value 40 from worldspawn.
Colored light entities detected: .lit output enabled.
************ ERROR ************

BSP built with version 0.7
Same map will light with mhlight.exe 
Error 43: Entity->iVertices > Entity->cVertices 
had this error too.
was skip texture on some surfaces of clipped or vertex edited brush entity. 
somewhere in the map, given the number of clipped or vetex edited brushes in it. I don't see why that would cause a problem though :/

Are you also using Worldcraft 1.6a? I didn't think anyone but me used it these days (I think most people use 3d accelerated 3.3) 
@than, @Stahlkralle, @mechtech

Thanks for the bug reports guys. Both issues should be fixed now - please try the new snapshot and let me know if that's fixed it. 
Thank You 
Map compiles fine now!!!
The func_detail thing is working great. Like getting a new CPU. vis is no longer the enemy. 
No Luck :( 
---- GrowRegions ----
35%---- light / TyrUtils v0.7 ----
extra 4x4 sampling enabled

GrowRegions breaks with no error at 35% and then light won't run because there is no bsp :/

Did you manage to get my map to compile? If so, maybe there is some problem with the current version. It's currently under all limits and is compiling fine with aguirre's qbsp though. 
@than: yes it compiled here, although without textures - I'll try to work out which wads I need, but feel free to just email them to me if that's easy enough. 
Causes HOM. Works like slime but does the HOM like a worldbrush with skip texture.

Using snapshot from post #235 
Oh, Wait 
I'm a dummy and messed up the test map. This time for sure, Rocky! 
@mechtech: that's expected unless you compiled with -transwater so that liquids don't block visibility. 
Tyrann my mistake. -transwater did it.
Using -transwater switch causes vis to crash. No errors reported by the program. I get the windows crash warning. Then it goes on to light. Map will run. I emailed the map and wad. 
Than, Mechtech 
Thanks guys - there does appear to be a problem with the skip support at the moment. As a workaround, I've added a "-noskip" option to the latest snapshot so you can use that and then run the extra "newskip" tool afterwards.

I'll try to get to the bottom of it this weekend and get a proper fix in there. 
I'll give that a whirl 
Skip Fixed, Vis Crash Fixed 
@than, @mechtech:

Please give this snapshot a try - both your maps are compiling for me now.

There are still some interesting HOMs in mechtech's map which I'd like to try and solve before I do a new release, but they don't seem to be related to skip at all. 
Compiles, no vis crash, HOM is odd. I removed func_detail and compiled with Txqbsp, newskip, WVis and mhlight just to make sure I hadn't screwed up the map. Compiled without error and no HOM. 
HOM Fixed 
As I thought, the HOM was my fault - qbsp bug.

This new snapshot should hopefully be bug free! I'll do a release if this one looks okay. Thanks again for testing! 
This new snapshot should hopefully be bug free!

You jinxed it! ;-) 
I compiled with the new snapshot. HOM is gone. I expanded the use of func_detail in the map. I haven't found any bugs yet, I'll keep trying to break things.

I do have an idea that might be useful for beta testing. Could a command line switch be setup to cause func_detail to use a specific texture. I could then run through a map and see better what can be optimized.

Is That A Q1SP Of Yours? 
If so:


That looks sweet as furk. 
That was an experiment I did with the texture set from Sock's website. Made some models with Gmax, hacked up a few I found on the internet to reduce poly count. At the time all it could ever be was one room. Vis time was prohibitive, so the map is unvised.

Then TyrUtils showed up. In the second shot you can see what I turned into func_detail. Vis treats it as just a box. Vis in under 2 minutes!!!

The unvised version with texures and sound is here
Use Fitz V it has hi rez skins. 
Broke something :)

Latest snapshot does not generate a correct pointfile. In Hammer pointfile shows up well outside the map grid. 
What Is Causing 
light / TyrUtils v0.6

0....1....2....3....4....5....6....7....8....9....************ ERROR ************
LightThread: no model has face 8213
Get The Latest 
Get the files on post #248

I got that error when using newskip.exe
Latest version does skip removal. 
No Model Has Face... 
The external skip tool will cause that. I should probably reduce that to a warning and skip to the next face. 
Looked into the detail re-texturing thing a bit this morning and it's a little tricky due to the order in which qbsp currently sets up the textures/texinfo/etc. But it's a cool idea and I'll keep it on the todo list for later.

Those screenshots look awesome by the way. 
TyrUtils V0.8 
No major new features, but some important bug fixes since 0.7:

* qbsp: fixed surface edge corruption when using skip surfaces
* qbsp: fixed portal generation for transparent water and detail nodes
* qbsp: added "-noskip" option for troubleshooting skip related problems
* light: reduce "no model has face ###" to a warning
* vis: fix portal stack corruption in ClipStackWinding
* bsputil: added a "--check" option (beta!) to check internal data consistency 
TyrUtils V0.8 
Forgot to add a download link! 
Tyrann You Rock 
dalay 4 -addmin = realism achieved, no need for radiocity!

I'm actually very happy now, for the first time I got truly good lighting out of q1 compilers. And better than from q-rad. No more dull flat outdoors! 
would be nice to see a picture of what kind of lighting you achieved with the delay 4 setting.

I always use addmin, but usually try and eliminate minlight for the final map, adding as much fake ambient as possible via fake bounce lights placed in the map. This is basically lights with low intensity and long falloff placed near highly lit surfaces to simulate light being reflected off the surface. I think it works quite nicely, but it's a bit of a hassle to set up, so some kind of automatic way to do it (or even real radiosity ;) ;) ;) ) would be a great help. 
Comparitive screenshots please! 
Fake GI 
Using many small local minlights spaced around the sky flat
same with -addmin: sexy

I wrote a detailed post /tutorial explaining with some more pics.
I thought delay 3 would be the same, but it works differently, can Tyrann explain why? 
Good Tutorial 
and the results are really nice too. 
Never occurred to me to try that. Thanks!

Also reminds me of the antilights feature... 
Nice Pics 
You can still see that you have used multiple light sources because there are some extra shadows, but overall it looks pretty good. Your blog has some nice map pics too - looking forward to seeing what you are working on!

Your geometry is interesting btw, did you work on some other game(s) before doing Q1 mapping? 
Its Pure Math 
thank you slapmap! 
TyrUtils V0.9 
Thought it was worth a new release just to fix this silly bug with point files being incorrect.

2013-04-24 TyrUtils v0.9

* qbsp: fixed bad pointfile generation

Download from
Delay 3/4 Difference 
Both delay 3 and delay 4 have no light falloff with distance, but delay 3 brightness is affected by the angle at which the light hits the surface whereas delay 4 has the same brightness at any angle of incidence. 
Quick Question Re Detail 
Does detail just mean they don't create new portals but can still block visibility? 
Detail brushes don't create portals and don't block visibility. 
Thanks For The Update 
HOM Again 
Ver .9 creates a HOM that is not present in ver .8

Do you want the map? 
Yes please, send it through. Not seeing any HOMs in the one you sent earlier. Cheers dude. 
Some Small Problems 
I think (not sure...) that using animating textures on detail brushes causes the compiler to miss out adding the texture to the bsp. I have just been doing some detail stuff on my map, and it seems to do the trick with regard to the compile times, but now I have a missing texture error on map load, which causes FQ to crash :(

Also, I started trying to play with hint and hintskip and am getting some warnings:
WARNING 09: Couldn't create brush face. I will mess around with that and see if I can fix it by recreating the hint brushes and send you the map if I can't. 
Map Sent 
seems it wasn't the hints, since I removed them anyway.

I also had a few glaring HOM bugs too. Will investigate further soon. Very tired right now so going to bed. 
it was the hint brushes. I will experiment with them later.

The HOM bugs are extremely severe - this is happening in a bare bones version of the map with only the world brushes (no detail), the player start and light on level 4 vis.

vis runs well fast though ;) 
than: Yes, there are secondary shadows which can be reduced using more (but smaller value) ambient lights.
I rather get inspiration from interesting concept art and architecture.

Tyrann: Ah, thats why delay 4 lights produce smoother and brighter result.
And what is delay 5 formula? It's very bleak, have to make light value 100+ to make it noticeable. Cant figure what its useful for. 
Isn't That 
If So 
Could it be used to create shadows in a minlight 1000 scene 0_o 
TyrUtils V0.10 
Sorry guys, there was a pretty glaring bug there with the vis util - let me know how you go with the hint brushes as well, since I've only made simple tests for those so far.

2013-04-25 TyrUtils v0.10

* Documentation added for bspinfo and bsputil
* Fix vis bug due to missing vertex copy in v0.9 portal clip changes

Download from
HOM Bug Gone! 
Thanks, Tyrann! 
HOM Dead 
Thank you for the fast update. 
Yeah, I had a small issue when looking at a func_wall through a skip brush that went away with this update. Thanks Tyrann. 
Map Leaks... 
in pretty much all versions. I've been using TreeQ because it doesn't seem to find invisible leaks, I've decided to try and move over to something with more features and I'm getting invisible leaks again. 
I moved to version 10 simply because the pointfile has been fixed, and it's pointing to something that doesn't have a hole in it. 
Managed To... 
get it to compile after chopping out a bunch of brushes... honestly though they don't look screwed up to me at all. They all look grid snapped and valid. 
Send me the map file with the invalid brushes please - I can't fix these problems without test cases! 
I'm doing it now buddy chillax!... :P 
Qbsp Crash... 
I have a version of my speedmap that hard-crashes the qbsp program in the latest build... (yeah it's that buggy as shit speedmap that I pretty much abandoned in a fit of rage) 
@Fifth: It might be a buggy map, but still interesting to see - I don't want qbsp to crash at all. Send it through if you don't mind. 
I had leaks and collision "holes" on my grid-aligned terrain as well, it often happens with complex non-axial geometry like terrain, because qbsp creates many usless splits everywhere from adjacent planes. Sometimes its just random and you can move geometry around and it becomes better (or worse).
Turn on r_showtris and marvel at the mess of q1bsp.

Is it even possible to make compilers stop splitting everything with everything and keep the original editor geometry, like q3map does, but still maintain q1bsp format compatibility? Why even brush_ents have splits inside an entity. Its already bad enough that splits are every 255 units just for compatibility with 90s software render. Ridiculously inefficient. 
To be honest in that speedmap I had messed around with a few settings in the hope that I wouldn't have to change my method of making terrain (which is somewhat similar to floor lofter method in UT)... it was pure laziness on my part.

Regards to the earlier invisible leaks it was some other bug in a different map (non-terrain).
I do want to make more interesting terrain but it looks like I'll have to make compromises if it's for Quake 1. Even making non-collision geometry and trying to make my own clipping using clip brushes seems to bring its own problems.
Even worse is that Q3 is probably a good game to make maps for in terms of stability and compatibility but it's a multiplayer game, who cares about that? It's good if you want to make a portfolio of work, but if you want to make a fun map to play then you'd get a bigger audience mapping for Doom 1 or 2. 
would it be possible to add in a mode where sunlight is replaced with an array of suns shining at different angles in a sphere? would be a nicer, more consistent (and easier) way of doing fake GI.

the sun array needs to be additive, but the values would need to add up to the final value specified as the sun level, so you'd probably need to make the individual suns in the array emit at maybe 1 or 2 brightness, which means you'd need floating point light values up until you right the results into the map file, at which point it would be safe to round them off. 
@necros: Sure it's possible, but not sure how good it would look for a whole lot more ray traces per surface point. Will put it on the TODO list as something to try out though. 
It Looks Like This 
Fake GI 
I had modded light.exe to do this a long time ago, and it does look good. You need a lot of suns for best results, though.

FYI, the mod was really easy -- BJP's "skyambient" already exists and uses a multiple sun method, but gives really flat results, and all you need to do is remove the clamping and make the suns much dimmer (and more numerous) and you'll get something that looks like GI. 
yeah, that's what i did for the above shots. i was hoping for some better integration from someone who knew what they were doing. :)

my version has a severe limitation because light levels are integer values but because of the number of suns, the actual light levels that those suns emit needs to be very low so you would need fractional values for all these low level suns. the end result would still be well over 1.0 so you'd just round the final result (after all the suns have been done, since they are done first) and then you would just light normally with the rest of the point lights. 
With a multithreaded light util the extra traces shouldn't matter. Light is never the bottleneck in map iteration anyway! Those tests look great, necros! 
ever apply clip textures to a func_detail... I just spent about 30 minutes tearing my hair out because of errors. 
Clip W/func_detail 
Use a Skip texture instead. That gives you an invisible (solid) brush that will cast shadows. 
Remember that projectiles collide with skip brushes but not clip brushes, in case that matters to you. But yeah, if it's not possible to create a clip detail (which isn't a very sensible combination when you think about it) a warning from the compiler might be best. 
Guiz Guiz.... 
I was being lazy when I was making the clip brush that's all... I have no idea what a clip detail brush would accomplish. :P 
A Skip Textured Detail Brush 
Can be used to make a shadow where there is no structure (perhaps as a hint to a secret area?) without having to mess with recessed areas behind a sky texture (as seen in e1m5 where there's a Quake symbol shadow leading to the Quad secret) and then using func_illusion to make a false sky. Seeing as the detail brushes will get merged into the bsp as brushes and not as an entity it helps to keep the entity count down as you don't need to have the func_illusion brush.

The tricky part would be putting it where it won't be noticed by the player because it will of course act like a wall in all respects (with the exception that it won't be drawn on the screen). So it would have to be high enough to not block the players movements and not block a monsters attack in normal circumstances. 
You can use a func_illusionary with _shadow set to 1 and skip texture to make invisible shadow casting brushes without collision. 
I Totally Did Not Know That 
How About... 
an invisible collision brush that doesn't cast a shadow? 
Clip Texture 
Didn't know that about func_illusionary either. 
-onlyents Bug? 
When you compile with onlyents, switable light styles seem to get broken. I remember this being a problem in older tools that aguirre fixed in his tools. Maybe you could check that one out, Tyrann? 
you need to run light -onlyents after running qbsp -onlyents. This is true for the original tools as well, Ii think. 
I don't remember there being a -onlyents option on the original light. That might be what aguirre added as a fix. I'll take a look. 
-onlyents on light is only supported in aguirre's tools afaik, though for all I know, it maybe have been supported in the original tools. I always used tyrlight before switching over to aguirre's tools though (except for the time I used the WC1.6 compile dialogue... yuck!) 
you might be right. I have been using aguirre's tools for a long time now, can't remember what the original tools did and didn't do. 
yes, that's correct about onlyents on light. it was added to address the problem where doing onlyents with qbsp would break switchable lights. 
Not Working For Me 
Opened WAD: \program files (x86)\worldcraft\textures\tech1.hlwad
*** WARNING 15: \program files (x86)\worldcraft\textures\tech1.hlwad isn't a wadfile
*** WARNING 01: No valid WAD filenames in worldmodel

And seriously???:
*** WARNING 06: No info_player_deathmatch entities in level

Seems okay. I love the resume feature.

I'm getting a TestLineOrSky: tstack overflow

Bengt's light 1.43 gives me everything fine. Here's my light info:
454 entities read, 333 are lights, 40209 faces, 500M casts

Unless I'm missing some compile parameter, then I'm going to be sticking with ol' Jardrups light. The vis is wonderful though, thanks Tyrann! 
Not sure about the invalid wad file - can you email me a zipped copy?

Tstack is trivial to increase, will do that for the next release. 
Oh wait - TestLineOrSky has been removed for a while - make sure you're using the latest versions - 
Does your light compiler support _sunlight2? If not is it possible to add that? 
Latest Version? 
The only version available on your website is 0.10. I have version 0.6 which is posted at the top of this forum. And sorry, I didn't realize that the wad name was cut off. They are .hlwad's since I'm using Worldcraft 3.3 with the quake patch. It's just the standard quake wads converted to hlwad...well with my own additions and modifications that is, scavenged from various places.

What version is the latest? and does it support hlwad setups? 
More Fun With Func_detail 
After applying func_detail to brushes in my map I noticed with r_showtris that areas behind were showing up. The detail brushes were allowing vis to see through the brushes that intersect the func_detail. I found func_detail cannot be used like func_wall where you block the back and your good. The solution I found was a small void gap between areas.

Qmaster: Version .10 supports hl wad files and format 220 valve maps. Use Utils hompage link above.

Tyrann: the download link points to old version .6 
is actually just a wad3 .wad. AFAIK you cannot load this into TB. So either convert them to normal .wad using TexMex or download the .wad from somewhere (I suggest quaddicted's ftp). 
Versions Confusion, So... 
Version 0.10 is greater than version 0.60? Is this 0.6 + (4 * 0.1) = 0.1 ?? Version maths, what can you do *shrug*. Anyways, thanks, will try.

@FifthElephant: Gotcha, thanks! 
Math Go Figure Logic No Way 
Qbsp Still Doesn't Want To Play Nice. 
Using version 10 now :)
....hlwads load good...
CSG... everything fine
6183 brushes
35535 brushfaces
yadda yadda
---- SolidBSP ----
1...37 38 39 40 41 42 43 44 45 46*********** ERROR ************
Mixed face contents in leafnode near (140.00 40.00 0.00)

no bsp made

This mix point (140, 40 ,0) is a corner where 4 brushes meet. The two walls tjunc. The floor tjuncs with the walls. And a lava brush tjuncs with everyone else. And then qbsp gives me this juncky error. I don't get it, compiles fine in txqbsp. I'll see if I can reproduce it with just those brushes in a dummy map. 
Light Works In Version 10 Btw 
I think that's not the junctions, just that you've got a sky brush touching a liquid brush.

Leave a gap between them, filled with regular brushwork if that'd cause a leak. 
Qbsp Worked! But Only For 4 Brushes (inside Another Hollowed One) 
Well qbsp finally worked. Wierd output though.
Seems I'm getting 352% for SolidBSP with every other % in between. After 100% they all run together.
57 mergedfaces
---- SolidBSP ----
1 2 3...... 94 96 98100101103105107108
110...347 349 350 352 200 split nodes
71 solid leafs

I'm still psyched up about having new compile tools! This is great. Multithreaded vis was way faster than my old one. Even between versions Tyrann has made improvements. Version .10 vis was about 8 minutes faster than .6 on a map with 6000+ brushes...surrounded by a cheater's cube!! :P

Tyrann's lighting was also much faster than my old bengt modified light, less than half as much time. Hurray for multithreading! 
Nearest sky brush is over 1000 units and several leafs away from that corner. But that's a good thought, you know I don't think I've ever tried bumping liquid up to sky before. huh.

Hrrmm... Still can't get tyr's qbsp to swallow this one map of mine. Granted, the map doesn encompass the ENTIRE grid in Worldcraft 3.3, but its only 16MB when far.

Tried another smaller map. It worked FINE. 
@quaketree - no _sunlight2 support right now, but I'll add it.

@mechtech - I think you are seeing this effect (and it's normal - just fill in the cavity to remove the overdraw).

@Qmaster - Yeah it's not obvious, but the '.' in the version string is a separator, not a decimal point. The old treeqbsp progress counter is a bit whacky and will be getting replaced. Happy to take a look at the compile problem if you send me a .map and any wads I'll need to compile it.

I might make a discussion thread for the utils because we're not really talking about version 0.5 anymore :) 
Here Tyrann... 
Tried it on another large map of mine.

I sent you an email with my .rmf and .map files and the log that qbsp spit out zipped up in 
@quaketree - no _sunlight2 support right now, but I'll add it.

Spiffy. I'm guessing that adding features that other popular compilers already support can only boost the use of yours. 
@Qmaster: cheers, will take a look over the weekend. 
What Would Be Really Cool Is... 
Qbsp support for displacement to brushes automatically with a command parameter of dispheight to set the thickness to automatically offset from a displacement surface's normal (negative normal that is) from hammer.

Oh and a command param to disable it such as
Looks like I've got the same mixed face contents in leaf error.

The map is unsealed though, so will fill in the gaps first.

Comes under the same specifications as QMaster's map - the sky is nowhere near the brushes in question, although there is liquid there. 
Ok, Got It 
The tools don't support non-rectangular liquid brushes. If used then they produce the 'mixed face contents in leaf node' error and don't build the bsp. 
That's pretty weird. Let me test that... 
Not just non-rectangular.

ijed: got a fairly simple test case which show the incorrect mixed face contents problem? 
Sure, I Can Make One 
Will send it sometime today. 
Looks like I won't have time today. I should be able to set up a few test maps easily enough Monday though. 
Oh That Makes Sense.. 
The small map I got to compile didn't have any liquid brushes.

The two larger maps I tried both gave errors on liquid brushes that were clipped at angles in the corners.

Wierd... I wonder what would have broken that support. 
Oh And Also 
Rectangular liquid brushes that get tjunc-ed such that they result in more than 4 sides (square/rect) volumes don't work either, although it seems kind of random from my few trials. Hard to make out what is going on when there is such complicated geometry clipping with this one large liquid brush.

I'd look into it but I'm busy this weekend. 
No problem, I've had very little time for this the last couple of weeks anyway. Will be away this weekend too, hopefully back to normal later next week. 
No Home PC 
For me.

Not sure if this has already been requested, but a few people have been experimenting with GI solutions recently, starting with slapmap.

I know you mentioned implementing _sunlight before, how about making adding a new field as well _suns / _suns2 which would add additional lights in a distributed pattern to create the GI effect?

I haven't experimented with it properly yet, but it'd be pretty cool to have it at base level in the tools. 
_sunlight is of course already there, but I will be adding _sunlight2/3 to emulate the bjp tools behaviour and I expect I'll add another mode where the light sources are more evenly spread. 
Do you still need the test maps? Not in the office today.... 
what does light.exe warning: no model has face xxxxx try to tell me?
seeing no drawbacks, just curious.
maybe Alpha func_walls? 
Light checks the face number against the surface start/end numbers in the bsp submodels to determine which model it belongs to. I think metlslime's newskip tool changes the start/end numbers of the models when removing skip surfaces but doesn't actually remove the faces from the bsp.

In that case it's harmless, but if you're not using newskip, I'd be curious to know how you got this error. 
using rebbs jury rigged tools, which support skip removal. 
Ok, I suppose I don't need to warn about that. It's just unused data that was left in the bsp file after skip removal. 
can i d/l the latest Version of your utils?
the ones On your site dont seems to reckon -addmin and -soft1 switches.
just got a new machine, trying to Set up from zero, but cant get my old cmdline to run. 
It seems that targeting a light at an info_notnull crashes the light util.

Can't be sure of this just yet though, need to experiment some more. 
Scratch That 
Whatever I've done it wasn't the spotlights - deleting has no effect on the crash. 
Fixed It, 
totally different cause.... 
It seems I've got the same crash as mentioned by Qmaster - tjunc, related to liquid volumes. 
@ijed: thanks for the test case, hoping to get back to some coding this weekend. 
The test is pretty messy though. I've been a worldcraft user for many years and there's a lot of things that it blinkers the user to that other editors don't.

So it's full of misaligned brushes and floating points. Other habits, like using the CZG Curve system blew up in my face and those sections I'll have to replace.

I usually have a new version per 24 hours, so can keep on throwing stuff at you once you're back into the swing of things. 
Tjunc Fix 
@ijed: Try this new snapshot. Fixes the tjunc crash for me. 

Will try it out tomorrow. 
BUG!!!!!! TyrUtils Qbsp.exe Version 0.10 
---- LoadMapFile ----
************ ERROR ************
line 5: Token too large

The text describing the location of my 5 different wad files takes 290 characters. I'm assuming that the limit is 256. Kinda limiting really. What if my name was like 40 characters? What if I had the wad files buried 6 or 7 folders deep for organization?

It would be nice if the limit was increased for the line starting with "wad". 
use relative paths. 
Same With 0.10-14 Snapshot 
@Qmaster: increased limit to 1024 
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.