"It also fixes a pretty critical bug Lunaran noticed"
Is it possible that has anythi g to do with shadows forming along face splits in the floor, e.g. along diagonals? I've been getting wierd lighting ever since I started to have to use bsp2. (map got too big) 

re: #279

Ok, I am officially intrigued.

I am also not entirely sure now what the real downsides are with the current ugly splitting, other than it just looking nasty to someone used to nice clean meshes. Would we see potential performance benefits to changing the procedure so it splits less or avoids splits entirely, as you describe? 

do you still get those artifacts with my builds, e.g. the one in #287?

There shouldn't be artifacts from using bsp2, but you never know. If it's still happening with the last build I can take a look at the map if you want. 

It's not a bug with light, it's a bug with tyrann's bsp.exe Here's 3 pictures showing the difference between tyrann's latest qbsp and good ol txqbsp:

https://dl.dropboxusercontent.com/u/20160676/tyrann_lightingerror1.jpg

Lines drawn to highlight ugly areas:
https://dl.dropboxusercontent.com/u/20160676/tyrann_lightingerror2.jpg

https://dl.dropboxusercontent.com/u/20160676/txqbsp_beautiful.jpg

Please note that tyrann's looks the same regardless of whether I use bsp2 (all vis groups visible) or normal bsp (a couple visgroups turned off).
The txqbsp has to have the visgroups turned off since it doesn't compile for bsp2.

Any idea what's going on? 

I guess this isn't really the right thread for it. ericw's light works ok btw. 

Okay, it appears to have something to do with subdivide face. In tyrann's qbsp I'm fiddling with adjusting the -subdivide ## parameter and getting different results, usually crashes such as Alloc fails or Failed to Subdivide Face. Hopefully I can figure out what is going on and why it would differ from txqbsp's implementation. FYI, the textures in my scene are scaled at 0.50 on every wall, floor and ceiling. I wonder if that has something to do with it? 

Figured it out. Jackhammer editor breaks world texture alignment when flipping brushes with Texture Lock turned on. I found that more than half of the textures in the room in the screenshots above had their World check box unticked. Ticked them (which caused them to flip negatively on the x-axis), flipped their X-axis so they were aligned correctly again, and BAM - - perfect lighting!

Editor problem.

User problem (not understanding my editor). 

So...in conclusion, Tyrann's qbsp for some reason doesn't handle undefined face alignment (neither World nor Face checked) very well and causes poor lighting along the edges on those faces that aren't World or Face aligned when created in Jackhammer. Txqbsp handles these okay so there must be some fundamental difference in handling of Subdivide Face between the two.

Just a heads up to anyone else who has this issue when they are using Jackhammer. 

glad you narrowed it down Qmaster.
Could you post part of the .map file (or even just that one brush that gets the black stripe) just for reference? I might be able to fix qbsp if it's an each change.

Btw, rebb's modifed txqbsp is worth checking out, it's probably the best qbsp right now (handles bsp2, detail brushes): http://www.voidspark.net/projects/bjptools_xt/ 

Here you go, I copied and pasted out a small portion of my main map to create a small test map. It's pretty ugly, I retextured it with all the same texture to save time and so that you could open it in standard quake (I'm using a different palette for my game).

.MAP File:
https://dl.dropboxusercontent.com/u/20160676/lighttest.map

.BSP File (Looks awful! and I don't mean just the texturing):
https://dl.dropboxusercontent.com/u/20160676/lighttest.bsp

Compile Log:
https://dl.dropboxusercontent.com/u/20160676/lighttest_log.txt

P.S. The percentages have a newline for every % or something, FYI. 

Also, when I say undefined face alignment, I mean arbitrarily aligned: https://developer.valvesoftware.com/wiki/Texture_alignment#Arbitrary_Alignment 

I tried compiling the map, looks whatever the problem was is already fixed in my modded tyrutils, as I don't get the weird patterns that are in the bsp you posted. (The qbsp.exe in my packs has a couple of fixes from Tyrann newer than his last 0.15 release).

Could you try with both the qbsp.exe and light.exe from here? http://celephais.net/board/view_thread.php?id=60967&start=287&end=287

Excerpt from my compile log:
$ ~/dev/tyrutils/bin/qbsp -bsp2 lighttest_tyr.map
---- qbsp / TyrUtils v0.15-17-g84caccd ----
..
$ ~/dev/tyrutils/bin/light lighttest_tyr.bsp
---- light / TyrUtils v0.15-17-g84caccd ----
.. 

Tried to compile willem's jam5 map with tyrutils, got this:

$ vis MapJam5_Warren
---- vis / TyrUtils v0.15-5-g5111c54 ----
running with 4 threads
testlevel = 4
BSP is version 29
14599 leafs
2613 clusters
8492 portals
Loaded previous state. Resuming progress...
Calculating Full Vis:
0....1....2....3....4....5....6....7....8....9....
Expanding clusters...
************ ERROR ************
Vismap expansion overflow


-vv probably gives more info, but it outputs a lot 

how long did it take you to get there?

i used h2map to create prt file from the already compiled bsp and then vis.exe to re-vis the map. it is working so far, but it's extremely slow. at this rate it will beat castle of the dark ages vis world record... 

We might want to accept that it's a terrible BSP and move on. :) I would do many things differently if I started that thing over... 

no way.. it's too early to give up :-) 

not long, i interrupted it often, total i would guess an hour or two. i5-3470. I went from the .map, not the existing files. 

i'm at 20% after 15 hours. it reminds me recompiling travail levels for transparent water support. of course, back then i had crappy single core cpu and no multi-thread vis tool. 

I'm curious as to how vis can be broken like that if - as you say in another thread - detail brushes were used extensively. 

Probably detail touching the void(wild guess). 

Is that a problem? There's TONS of that. 

this can be the reason for some trouble.
Try deleting all detail brushes and compile again.
If it leaks now, there is your problem. 

-makedetailleak is the switch in txqbsp_xt. 

It happens after

leaf 10366 : 12797 visible
leaf 10367 : 12797 visible
leaf 10368 : 12797 visible
************ ERROR ************
Vismap expansion overflow

so either leaf 10369 is the trouble maker or what code runs after the "Expanding clusters...".