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
 
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? 
Hexen2 Support Patch 
http://triptohell.info/moodles/junk/tyr-h2.patch
adds -hexen2 argument to qbsp to generate a h2(mp) bsp.
vis and light also accept hexen2 bsps.

doesn't do anything about palettes.
silently ignores hexen2's extra 'light' attribute of each plane, if specified. this is consistent with other hexen2 tools (iiuc).
doesn't do any special behaviour with watervis, so unlike hexen2 lava is watervised by default.
do NOT try loading a hexen2 bsp in a quake engine (other than ones that explicitly support it). doing so will likely result in crashes (and vice versa).

-hexen2 -bsp2 are accepted simultaneously. fteqw supports this, other hexen2 engines will need to be tweaked now that there's a tool that can actually generate them. this relaxes the clipnode limit that otherwise severely limits the sizes of hexen2 maps (to two fifths of a quake map, approx).

let me know if I broke anything... 
Spike 
wow, thanks! this will be nice to have.
I will test this a bit and merge it in.

ExportClipNodes is confusing, I don't get what the "diff" variable is doing and why was it only modifying model->headnode[1], but it will probably be clear if I watch it in the debugger. 
 
yeah, that took me a while to figure out too...

its reordering the clipnode trees because they're calculated by hulls then models, but stored in the file as models then hulls, so the previously stored hulls need to be remapped to cope with the clipnodes added into the previous models (ie: clipcount has changed since the tree for the previous hull was generated).
the alternative would be to store the trees as-is and fix them up later.

I forgot to do anything about world.spawnflags&1 signifying mission pack+hulls. I'm not sure that there's much point in it not being set, but meh. 
 
Hexen 2 bsp2 support - cool, I might finish my big H2 map then. I considered using it elsewhere but it doesn't really match there either. It has been just collecting dust since it broke the format like a clumsy child breaks eggs. :-/

just like my ROEM maps have been collecting dust since I got vaguely pissed off with RMQ gameplay and Quake at large but was too bored, sick, busy to do much about it. Can't puzzle out the gameplay but also can't release them for vanilla quake (too big, too spacious etc)

anyway, hordes of fucking archer knights, at the ready? I'll have to try H2BSP2 some day.

uh, Hexen 2 jam in honour of this feature? Or am I hallucinating. I probably am. No one makes Hexen 2 maps anymore. If you want to Hexen 2 map, hit me up? 
Feature Request? 
Detail brushes that are (I imagine) accidentally used to seal the void are bad, right? Might it be worth putting in a -nodetail switch or something that lets you do a test compile that discards all the detail brushes, allowing you to find leaks that are purely in the (non-detail) world brushes? 
Kinn 
If you're using TB you can actually hide certain brushes.

Just go to the View tab on the right and deselect Detail Brushes. 
Fifth 
I use Netradiant, and never could get into TB unfortunately (although I like the sound of TB2 - I may have to have a goosey at that).

For now, I notice that rebb's txqbsp has an option to "make detail leak" for this exact purpose, so I can try that I guess. 
 
Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days. 
 
Since func_detail is an entity, I imagine your editor must have some facility for hiding/showing groups of entities ... altho I don't know much about Radiant these days.

Hiding anything in netradiant does not exclude it from compile, so that would not help in debugging detail-sealing-void issues 
KInn 
Use txqbsp_xt, there is a switch -makedetailleak that does what you want. 
Mfx 
Aye, that will have to do 
 
In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version. 
 
In radiant, you just press L to bring up the entity list, and select all the func_details by clicking the first one and shift-clicking the last one in the list... you just just delete them, save as, and compile the detail-less version. 
Idea... 
I know there's been plenty of talk of a prefab feature before, and I think last time it ended with people talking about doing it editor-side.

However, I never like the idea of restricting the choice of editors, and I know plenty of us are using an editor that is no longer in active development (e.g. netradiant) and really want to stick with it, so is it worth talking about a compiler-side prefab feature?

The user interface would be simple - a "func_prefab" entity with a key that points to the filepath of a .map file containing whatever you want copying over. Rotation should work as expected. I don't think scaling would get used as much but that might also be worth supporting

Of course in old editors you'd lose the ability to see the geometry in your map, but in a lot of cases I don't think this would be much of an issue as you'd position the brushes in your prefab map file so that a sensible anchor point would be at the origin.

Thoughts? 
The Problem With A Posteriori Transformations 
Is how to ensure that the textures are still aligned. Translation is easy, scaling is not so easy, and rotation is a bitch. Also difficult are targetnames etc. 
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.