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. 

Awesome! Thank you for adding surface lights to the tools ericw! And all the other little improvements! 

Am I the only one who thinks we should have a proper standard for mirrors before building infrastructure to support them? We all remember what happened with skyboxes and fog. 

is support for am_detail dropped completely in favour of func_detail? 

https://twitter.com/back2cccp/status/593157752442253312

just to clarify how this works, it's nothing more than automated copy & paste by the compiler. the "_surface" key is put on a light, this turns that light into a template 

Nice, and I like that implementation ... 

This is already being used in my retro jam map :)