 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I'm curious as to how vis can be broken like that if - as you say in another thread - detail brushes were used extensively.
this can be the reason for some trouble.
Try deleting all detail brushes and compile again. If it leaks now, there is your problem. 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. 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.
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 My god. This is amazing. Just had a play with it tonight
Tinkering with this, it's great. I used it for the lava in my RJ3 map but I'm toying with it for all light textures atm, it might turn out to be a really good time saver :)
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |