I think Tyrann added that, but yeah it's awesome! 

I used "_shadow" key quite a bit... but there's one obvious spot where it caused an issue that I should've worked around: A func_illusionary with "_shadow" "1" on the floor casts blackness on the floor below it, so any dynamic entity on top of that func_illusionary will be unlit because it uses the lightmap of the solid floor (which is fully shadowed) as the brightness of the entity above it. This isn't a compiler problem, it works as intended, but can be unexpected that that is how it works. This is why there is a fully dark Ogre in the map.

I had to do that because of a clipping error, but I should've tried some other things to fix it, but it was getting really close to the deadline. 

That's similar to the old "black scrags against a bright sky" thing that many maps suffer from.

To fix that particular problem you had, sometimes you can put a func_wall floor underneath to catch the shadow, then put a real floor below that which is lit normally to provide the entity lighting. But it can be tricky to get the brightness balanced.

Yeah, that deadline was a pain :) 

been meaning the mention this... -fast is missing from light.exe... Could we have this back, since it can take 20-30 minutes to light stuff now with all those deviant lights and such... 

Any way to attach a lightstyle to a shadow from a bmodel? 

I think that might actually be possible. It would be a bit of work to code, possibly not too bad though. 

cool, it's just a nice-to-have. maybe you have some floor you want casting shadows, but later needs to break or something... 

There's a fix for mixed face contents I'd like to have that was added to git on 31/07, but the latest build is from 13/07 (according to readme).
Will there be a new build soon-ish or will I have to do it myself? (= pain) 

available from here: http://quakespasm.ericwa.com/job/tyrutils-ericw/ 

 

Yeah, those nightly builds should be fine to use.

In other news I found a serious bug in the surface lights code that was causing it to spam multiple copies (sometimes 10+) of each of the surface lights. This is unrelated to the bug where setting "_deviance" "0" on a surface light would also spam copies.. This explains why they were going crazy for some people during the map jam, and the extra long compile times with surface lights.

That should be fixed in the nightly builds. I'm working on some speedups for light right now and hope to have a new release soon. 

available on the website: http://ericwa.github.io/tyrutils-ericw/

Changes:
* qbsp: add "-maxNodeSize" option, from txqbsp-xt. Defaults to 1024. Makes large maps process much faster and should generate better bsp trees. If it causes a problem disable with "-maxNodeSize 0"
* qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt
* qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour.
* light: add "-surflight_subdivide" flag to control amount of surface lights created
* light, vis: use below normal process priority on Windows
* light: allow negative surface light offset
* light: average the lit file color components to generate the bsp lightmap value. TODO: use a perceptually weighted average.
* light: fix lighting of hipnotic rotating entities.
* light: fix crash in "Bad texture axes on face:"
* light: fix surface lights being mistakenly duplicated
* light: add "-onlyents"
* light: add "-dirtangle" setting to control dirtmapping cone angle, default 88 degrees.
 

But what about phone shading!!! 

Apple or Android? 

http://triptohell.info/moodles/junk/tyr-h2.patch
adds -hexen2 argument to qbsp to generate a h2(mp) bsp.
vis and light also accept hexen2 bsps.

doesn't do anything about palettes.
silently ignores hexen2's extra 'light' attribute of each plane, if specified. this is consistent with other hexen2 tools (iiuc).
doesn't do any special behaviour with watervis, so unlike hexen2 lava is watervised by default.
do NOT try loading a hexen2 bsp in a quake engine (other than ones that explicitly support it). doing so will likely result in crashes (and vice versa).

-hexen2 -bsp2 are accepted simultaneously. fteqw supports this, other hexen2 engines will need to be tweaked now that there's a tool that can actually generate them. this relaxes the clipnode limit that otherwise severely limits the sizes of hexen2 maps (to two fifths of a quake map, approx).

let me know if I broke anything... 

wow, thanks! this will be nice to have.
I will test this a bit and merge it in.

ExportClipNodes is confusing, I don't get what the "diff" variable is doing and why was it only modifying model->headnode[1], but it will probably be clear if I watch it in the debugger. 

yeah, that took me a while to figure out too...

its reordering the clipnode trees because they're calculated by hulls then models, but stored in the file as models then hulls, so the previously stored hulls need to be remapped to cope with the clipnodes added into the previous models (ie: clipcount has changed since the tree for the previous hull was generated).
the alternative would be to store the trees as-is and fix them up later.

I forgot to do anything about world.spawnflags&1 signifying mission pack+hulls. I'm not sure that there's much point in it not being set, but meh. 

Hexen 2 bsp2 support - cool, I might finish my big H2 map then. I considered using it elsewhere but it doesn't really match there either. It has been just collecting dust since it broke the format like a clumsy child breaks eggs. :-/

just like my ROEM maps have been collecting dust since I got vaguely pissed off with RMQ gameplay and Quake at large but was too bored, sick, busy to do much about it. Can't puzzle out the gameplay but also can't release them for vanilla quake (too big, too spacious etc)

anyway, hordes of fucking archer knights, at the ready? I'll have to try H2BSP2 some day.

uh, Hexen 2 jam in honour of this feature? Or am I hallucinating. I probably am. No one makes Hexen 2 maps anymore. If you want to Hexen 2 map, hit me up? 

Detail brushes that are (I imagine) accidentally used to seal the void are bad, right? Might it be worth putting in a -nodetail switch or something that lets you do a test compile that discards all the detail brushes, allowing you to find leaks that are purely in the (non-detail) world brushes? 

If you're using TB you can actually hide certain brushes.

Just go to the View tab on the right and deselect Detail Brushes. 

I use Netradiant, and never could get into TB unfortunately (although I like the sound of TB2 - I may have to have a goosey at that).

For now, I notice that rebb's txqbsp has an option to "make detail leak" for this exact purpose, so I can try that I guess. 

Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days. 

Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days.

Hiding anything in netradiant does not exclude it from compile, so that would not help in debugging detail-sealing-void issues 

Use txqbsp_xt, there is a switch -makedetailleak that does what you want. 

Aye, that will have to do