News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.11
TyrUtils v0.11 has been released:

*Support BSP2 format (qbsp requires the "-bsp2" command line option)
*qbsp: Fix animating texture bug when brushes are textured with alt-animations
* qbsp: Fix a crash in tjunc calculations
* qbsp: Exit with error if verticies exceed 65535 (BSP29 limit)
* qbsp: Add experimental "-forcegoodtree" command line option (thanks Rebb)
* vis: reduce "leaf recursion" error to a warning and continue processing

Download from the utils page as usual (Win32 / OSX / source).
First | Previous | Next | Last
Hmm 
Probably detail touching the void(wild guess). 
 
Is that a problem? There's TONS of that. 
Iirc 
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...". 
April 17 TyrUtils-ericw Snapshot 
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. 
Thank You Sir! 
 
 
Someone post screenshots! I wanna see lava lighting up some shit... 
Rebb 
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. 
Baker 
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. 
Holy Crap! 
Awesome! Thank you for adding surface lights to the tools ericw! And all the other little improvements! 
Mirrors 
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. 
Am_detail 
is support for am_detail dropped completely in favour of func_detail? 
Surface Lights Screenshot 
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 :) 
 
My god. This is amazing. Just had a play with it tonight ... it's like getting lighting for free. Fuck ... FUCK. Gotta map... 
Glad To Hear It 
 
Minor Qbsp Update 
win32 os x src

* qbsp: fix broken -onlyents flag
* qbsp: fix texture offset on rotate_object, so they match in the
editor. Added "-oldrottex" flag to revert to old behaviour. From txqbsp-xt.

No changes to light though. 
Lighting... 
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 :) 
Hm 
lighting...

will be handy for speedmapping 
 
surface light = very good stuff! 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.