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...". 

win32 os x src tgz src git light manual

with some new stuff:

* light: fence texture tracing, for bmodels with "_shadow" "1"
* light: surface light support via "_surface" "texturename" light key

convenience:
* light: respect "_dirt" "-1" bmodel key in -dirtdebug mode
* light: allow setting "-dist" and "-range" command-line flags in worldspawn
("_dist", "_range")
* light: accept "_sunlight_mangle" as an alternative for "_sun_mangle"

other:
* all: increase stack size to 8MB. Fixes qbsp crash with bbin1.map on Windows, light crashes.
* qbsp: switch to hardcoded MAX_MAP_PLANES (262K), speeds up map file loading phase.
* qbsp: MakeFaceEdges: accelerate with a hash table to avoid slow O(n^2) search for edges
* qbsp: ChooseMidPlaneFromList: fix off-by-one error in axial plane test. On the first SolidBSP pass, gives fewer split nodes on bbin1.map (128k vs 199k)
* light: MatchTargets: disable copying "style" key/value from a light to the entity that targets it. Don't see any point, and causes problems if "style" is meaningful for the targetting entity (e.g. a monster).

Thanks Scampie/Lunaran for the ideas earlier in the thread about surface lights. I agree it's limited because you can't customize individual lights, but it still may be handy (e.g. for lighting a big lava surface).

Also thanks to mh for the example of how to do surface lights in one of his MHColor builds. 

 

Someone post screenshots! I wanna see lava lighting up some shit... 

MakeFaceEdges: accelerate with a hash table might be a nice patch to have in txqbsp-xt. Your SolidBSP is already lightning fast, and I noticed MakeFaceEdges was one of the bottlenecks on big maps; with this patch it completes almost instantly.

I was looking at bringing some of the qbsp optimizations from txqbsp-xt to tyrutils: the 1024-unit max node size, and the different way that SelectPartition measures the bounding box of the list of surfaces.
These brought the compile time of the huge bbin1.map in line with txqbsp-xt (as well as improving leaf/node counts close to what txqbsp-xt gets), but they also caused telefragged.map to leak, so I didn't merge those changes in (maybe next snapshot I'll put them in with a command-line flag, though). 

How hard would it be to add all the surfaces a mirror can see to the visibility for any area that can see the mirror?

I have mirror alpha implemented in Mark V beta but I'm trying to decide how to tackle visibility.

I thought I'd ask this before I decide on a course of action. 

Sounds like it wouldn't be too hard, as a postprocessing step after vis. Something like: 1) find all leafs that have a mirror in them (based on a texture prefix?) 2) for each leaf X, check whether each other leaf in its PVS is a mirror-containing leaf marked in 1. if yes, merge the mirror-leaf's PVS into X's PVS. 

tbh you're probably better off doing that in the engine, if only because it means you don't have to trust the vis tools.
plus it also opens up the possibility of q3-style portals with complex gamecode. 

Hehe, I've been meditating ever since ericw posted back.

Thinking about that kind of dilemma. i.e. What about moving mirrors, etc.

Also the possibility of mirrors in maps that didn't expect to have them.

I've got probably 1 more week of polishing up the engine before I think hard about this.