Thanks, those instructions worked. :)

Now I just need to gather enough courage (and set aside enough time in case of repeated failure) to attempt building TB2 as per your instructions, and I'll be back in business. 

 

How are you guys going about finding leaks using netradiant and qbsp/txqbsp? Specifically looking to find the "Detail Nodes facing the Void". I can use q3map2 to find normal entity leaks, but it doesn't work for func_stuff. Is there an easier way than hunting through the map seams? 

The main idea is to use the pointfiles (mapname.pts) output by qbsp/txqbsp. The quake engine can load them with the "pointfile" command. I use Trenchbroom to load them.

re: "Detail Nodes facing the Void" warning, this is unique to how func_detail was integrated into Quake tools. It's not the same as a leak.. as far as I know, the only problem that warning can cause is reduced vis quality (the fact that this is an issue at all may be a bug in vis, not sure.)

To avoid the warning: having world brushes seal in the func_detail is not good enough, because detail clips away world, and the warning happens after the CSG phase when every brush is clipped against every other one. You want to ensure there are some non-detail *faces* left in the final bsp (what you see in-engine) that, if you extend the planes they are on, enclose all of the detail faces.

e.g. if you have an outdoor area where the entire floor is detail, I think you will get that warning 

So, I did some experimenting and func_detail can actually be used to seal the map. Um...what?? Also, func_detail brushes are still being used to slice up the space into more and more leafs. Again...huh?? So func_detail is essentially worthless except to speed up vis then? I could use func_wall to save on leafs and not worry about leaks mysteriously showing up when I hide the (leak would be there anyway).

I thought the point of func_detail was to not affect vis, like, at all. No leafs added, no slicing other brushes. Is it possible for func_detail to work like in Source: https://developer.valvesoftware.com/wiki/Func_detail 

func_detail will always cut up brushes. It's sole purpose is to speed up vis. 

Assuming latest ericw tools are used, what are the downsides of using buttloads of func_wall in place of func_detail? 

func_wall lighting might get a bit funky. You'd have to remember to include things like _shadows and _dirt etc.
That's the thing I can think of mostly being affected. 

The other issue with using brush entities is that you are contributing to the entity count. If you're trying to stay under 255 ents for extra compatibility I guess then it's better to stick with func_detail. 

func_wall downsides:
- counts towards entity limits (I guess they are probably static ents?)
- likely will have overdraw?
- they can have different rendering performance quirks depending on the engine (and how well the GL driver optimizes what the engine is doing).

Quakespasm: there is some setup cost per-func_wall rendered, but they use the same drawing code as the world, so they can have lots of faces and still render fast

Fitz085 and I believe MarkV use R_DrawSequentialPoly which scales badly on funcs with lots of faces 

Also, func_detail needs to create leafs, otherwise collision wouldn't work, rendering might break depending on the engine. The engine needs to have been designed with func_detail in mind to support not creating leaves (q2/q3/source?). 

Ok. On a related note, can func_wall have keys added to receive and block lighting identically to a func_detail. 

"_shadow" "1" 

 

Is there a simple reason why the light tools can't be extended to produce lightmaps of essentially arbitrary resolution?

More generallly, -extra 4 is still producing aliased shadows for me (e.g. here: https://ubiquitousgame.files.wordpress.com/2016/09/01.jpg). Is there anything I could try to get better looking lightmap resolution? 

It would require new file formats and engine support I would imagine.

This was thoroughly investigated a while back and actually got working, and from what I remember the feedback went something like:

"Oh this is cool but a bit too sharp actually, can the shadows be made softer?" (makes it softer) "Hmmm, even softer?" (makes it even softer) "...softer still?...ok actually on reflection I think quake's default lightmap resolution actually looks better but thanks anyway ^_^" 

I imagine the tools to generate the lightmaps weren't as good then? From what I can tell the quality of lighting improved quite a bit in the last N years. 

This is a limitation of the vanilla BSP format. Lit2 solves it, but only a few engines supports it. 

I think it was only something like one year ago when this was explored. Might be wrong - my temporal awareness is somewhat shoddy to say the least. 

what about "-soft 2" or even more? 

higher-res lightmaps have their perks: http://triptohell.info/moodles/junk/fte-20150311190731-0.jpg

the biggest issue is that lightmap changes (both flashing lights and dlights) become abusive, which essentually requires multithreading and/or rtlights in order to prevent it being unplayable, which greatly limits the number of engines willing to implement it.

crank it up to max and the bsp files become insanely huge, but that's only to be expected from poor-man's megatexture. :)

either way, the stepping issue doesn't really go away. the only way to fix that is to use cubic filtering instead of linear filtering.
currently this requires custom glsl. I really ought to investigate it some time. :s 

I think there is also some room to improve the filtering within light.exe.. it's using a box filter for -soft and -extra, which is the worst possible filter, I want to try lancosz or others.

Anyway to get the best quality currently you should combine -soft and -extra4.
-extra4 alone will be sharper but have more aliasing 

Thanks for the explanation all 

the biggest issue is that lightmap changes (both flashing lights and dlights) become abusive, which essentually requires multithreading and/or rtlights in order to prevent it being unplayable, which greatly limits the number of engines willing to implement it.

As an aside, I've always thought the ideal handling for light styles would be to upload the four styles as 4 separate textures and combine them using multitexture (or multiple passses) when rendering. Are there any engines that do this? 

rmqe does, iirc.
my engine that tries to draw the entire worldmodel in a single draw call also does.

the fragment shader is a bit faster if you do all 4 lightmaps with a single texture, at least when there's no lit support. you can then do the style->value lookups in the vertex shader and your fragment shader basically gains only a dot4product compared to a luma texture.