News | Forum | People | FAQ | Links | Search | Register | Log in
Tyrutils-ericw V0.15.1
Hey, I got around to setting up a website for my branch of tyrutils: (complete with lots of screenshots of different settings of AO, sunlight, etc!)
http://ericwa.github.io/tyrutils-ericw
and making an "official" release of it.

Nothing major changed compared with the last snapshot (may 1st), but a couple new things:

* .lux file support from Spike, for deluxemapping
* gamma control with -gamma flag and "_gamma" key
* rename -dirty flag to -dirt for consistency
* fence texture tracing is now opt-in only with the "-fence" flag.
* light should run a bit faster


This doesn't have lit2. Not sure what to do with that, tbh.

If there's a demand for it, I was thinking I could make a tool that upscales all textures in a wad by 2x or 4x, and adds a "-2x"/"-4x" suffix to the names. You could then manually get the higher-res lightmap on certain faces by applying the upscaled texture, and lowering the texture scale to 0.5 or 0.25 in your editor.

The only real disadvantage of this hacky method over lit2 is more face subdivision by qbsp. This isn't great, but it shouldn't be an issue if the hack is used sparingly (and bsp2 can be used if needed for higher face/vert limits.)

Anyway, enjoy, I hope this is pretty bug-free.
First | Previous | Next | Last
Hmm 
I haven't tested it with Hammer at all, I imagine there some syntax craziness going on! 
What Do These Error Messages Mean? 
*** WARNING 12: New portal was clipped away in CutNodePortals_r

*** WARNING 16: Texture __TB_empty not found

I got them while compiling a TB2-made map using qbsp from this branch. I've been compiling every so often to test things out and I mostly do not get any errors. Would just like to know what I could have changed that would have resulted in these errors (and hence what I should avoid doing in future). 
 
CutNodePortals_r is usually caused by complex brushwork, often occurs where several planes meet at one point and/or there are brushes with vertexes off the grid. If it gave coordinates, look there in your map to see what could be the cause.

Example, txqbsp_xt will report it like this:

WARNING:CutNodePortals_r: new portal was clipped away near (2592 -518 -40)

Texture TB_empty sounds like some kind of missing texture error where TB substituted "Texture __TB_empty" in it's place of its name. 
 
Depending on where it is, you can often just ignore a CutNodePortals_r warning, but sometimes it causes small invisible walls that'll block player movement. Turning complicated brushwork in the area of the warning into func_walls will also sometimes fix it.

I got a lot of this in my jam6 map due to the weird brushes making the damaged walkway, so I just made them a func_wall. 
 
"__TB_empty" is the texture name Trenchbroom puts on a face with no texture. If you know the brush, you put a texture on it, if not, do a find/replace in notepad or something and search for "__TB_empty" and replace it with some other texturename (Does TB/TB2 have a texture find/replace? if so, use that) 
__TB_empty 
is used when you have a face without a texture. TB2 has to insert some string as the texture name, and this is the placeholder it uses for such situations. 
 
"" is a string, no? :) :) :)

srsly tho, yeah, I opened my .map in Sublime Text and did a find/replace 
Thank You Very Much, Rick, Scampie And SleepwalkR 
...for both explaining what causes those errors and giving me pointers on how to fix them (or potentially work around them, in the case of CutNodePortals_r). 
Matecha 
Texture names are not quoted in the map file. God knows how different compilers would interpret "". 
 
Radiant uses a blank space, luckily it also recognizes that blank space as something you can find and replace in the editor. 
Ericw 
By the way, my favorite new feature of the light utility is the ability for func_walls to cast shadows. I used it a several times in my jam 6 map. The 12 fingered torchieres in the lava and the hanging lanterns beside the last steps up are all func_walls casting cool looking shadows. 
 
I think Tyrann added that, but yeah it's awesome! 
Agreed 
I used "_shadow" key quite a bit... but there's one obvious spot where it caused an issue that I should've worked around: A func_illusionary with "_shadow" "1" on the floor casts blackness on the floor below it, so any dynamic entity on top of that func_illusionary will be unlit because it uses the lightmap of the solid floor (which is fully shadowed) as the brightness of the entity above it. This isn't a compiler problem, it works as intended, but can be unexpected that that is how it works. This is why there is a fully dark Ogre in the map.

I had to do that because of a clipping error, but I should've tried some other things to fix it, but it was getting really close to the deadline. 
 
That's similar to the old "black scrags against a bright sky" thing that many maps suffer from.

To fix that particular problem you had, sometimes you can put a func_wall floor underneath to catch the shadow, then put a real floor below that which is lit normally to provide the entity lighting. But it can be tricky to get the brightness balanced.

Yeah, that deadline was a pain :) 
 
been meaning the mention this... -fast is missing from light.exe... Could we have this back, since it can take 20-30 minutes to light stuff now with all those deviant lights and such... 
 
Any way to attach a lightstyle to a shadow from a bmodel? 
Haha 
I think that might actually be possible. It would be a bit of work to code, possibly not too bad though. 
 
cool, it's just a nice-to-have. maybe you have some floor you want casting shadows, but later needs to break or something... 
New Build Soon? 
There's a fix for mixed face contents I'd like to have that was added to git on 31/07, but the latest build is from 13/07 (according to readme).
Will there be a new build soon-ish or will I have to do it myself? (= pain) 
There Are Nightly Builds 
Yay! Excellent! 
 
Czg: 
Yeah, those nightly builds should be fine to use.

In other news I found a serious bug in the surface lights code that was causing it to spam multiple copies (sometimes 10+) of each of the surface lights. This is unrelated to the bug where setting "_deviance" "0" on a surface light would also spam copies.. This explains why they were going crazy for some people during the map jam, and the extra long compile times with surface lights.

That should be fixed in the nightly builds. I'm working on some speedups for light right now and hope to have a new release soon. 
New 0.15.2 Build 
available on the website: http://ericwa.github.io/tyrutils-ericw/

Changes:
* qbsp: add "-maxNodeSize" option, from txqbsp-xt. Defaults to 1024. Makes large maps process much faster and should generate better bsp trees. If it causes a problem disable with "-maxNodeSize 0"
* qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt
* qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour.
* light: add "-surflight_subdivide" flag to control amount of surface lights created
* light, vis: use below normal process priority on Windows
* light: allow negative surface light offset
* light: average the lit file color components to generate the bsp lightmap value. TODO: use a perceptually weighted average.
* light: fix lighting of hipnotic rotating entities.
* light: fix crash in "Bad texture axes on face:"
* light: fix surface lights being mistakenly duplicated
* light: add "-onlyents"
* light: add "-dirtangle" setting to control dirtmapping cone angle, default 88 degrees.
 
Yes Yes Yes 
But what about phone shading!!! 
 
Apple or Android? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.