Func_Msgboard: Tyrutils-ericw V0.15.1

Posted by ericw on 2015/07/14 00:34:45

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

#976 posted by Mugwump on 2017/09/20 04:57:12

I like ClEric and Qompiler (maybe shortened to Qompil?). Putting a Q instead of an initial C is a Quake tradition and it would be a nice nod to it.

I agree with Qmaster that Arcaneutils is meh for the exact same reasons. Oh, and whoever came up with The Compiler of Erich Zann is an evil genius! Reminded me of a Mekong Delta album.

#977 posted by muk on 2017/09/20 05:02:31

I have a batch file called qompiler :P

https://github.com/muk0r/qompiler

its kind of broken right now though.

I Knew It Sounded Familiar!

#978 posted by Mugwump on 2017/09/20 05:11:16

TheLastQuakeToolsYouWillEverWant

#979 posted by brassbite on 2017/09/20 07:30:24

Short: TLQTYWEW

WEW

#980 posted by oh, that person on 2017/09/20 07:41:08

👌

#981 posted by ＰＲＩＴＣＨＡＲＤ on 2017/09/20 14:20:22

Map jam where every map title is a possible toolset name and the best map wins the right to name the tools

Cue "penispiler"

#982 posted by anonymous user on 2017/09/20 14:52:39

Slipgatools

The Lesson To Be Learned

#983 posted by negke on 2017/09/20 18:23:25

Don't ask Func for name/theme/feature suggestions...

Cuntpiler

#984 posted by Mugwump on 2017/09/20 19:22:37

Better End The Suggestion Period

#985 posted by ericw on 2017/09/20 20:02:07

ok - scratch arcaneutils. Thanks for the ideas.
probably "ericw-tools" is the pragmatic choice becuase I've heard people refer to it as that anway.. hm.

Yup

#986 posted by Mugwump on 2017/09/20 23:01:45

You've added so much to TyrUtils that your fork is not really Tyrann's anymore. It deserves your own brand.

Keep Your Name In It

#987 posted by sevin on 2017/09/21 14:01:01

It's casual and easy to remember. Plus reminds everyone who's working on it.

Question

#988 posted by mankrip on 2017/09/24 21:03:33

If a func_wall entity has skip-textured faces that goes deep inside the world's brushes, crossing multiple VIS areas, will said entity be "visible" across all those VIS areas, even though it has no faces to render in there?

Maybe this is more of an engine problem.

#989 posted by ericw on 2017/09/24 22:33:34

I am guessing "yes" they will be visible. skip faces are deleted towards the end of qbsp so they're included in the model mins/maxs - I think.

To optimize for this case I think the engine could build a tighter visible mins/maxs by iterating over all faces/vertices of the model.

#990 posted by ericw on 2017/09/24 22:33:34

#991 posted by Spike on 2017/09/25 01:31:44

the qbsp must(imho) calc model bounds according to the maximum of both rendered geometry as well as related collision structures.

Failure to account for collisions means you'll end up missing initial collisions, resulting in entities getting stuck and unable to leave again (more than just a precision error). This is true (although perhaps rarer) even in vanilla.

#992 posted by muk on 2017/10/22 05:43:37

played with _falloff, its pretty damn handy. is support for the other delays feasible?

Cool

#993 posted by ericw on 2017/10/22 21:12:19

It should be possible to support for delay 1/2/5 as well. it would be a bit different for these because they extend forever, so maybe "_falloff" would set the distance where they hit 1/255 brightness, or something?

Shadows On The Snow...

#994 posted by Redfield on 2017/10/24 19:46:09

Using TyrUtils v0.15.11, working on my Frozen map and have encountered some strange shadows. Look at the rock shadow just below the crosshair, this occurs in a few places in the map, the shadow is not very soft and has harsh transition between dark and soft:

https://i.imgur.com/yz7m73G.jpg

Current settings:
sunlight: 200
sunlight_color: 211 163 139
sunlight_mangle: 90 -55 0
sunlight_penumbra: 4
sunlight2: 200
sunlight2_color: 147 115 135
dirt: 1
dirtdepth: 96
dirtgain: 0.75
dirtscale: 0.75
bounce: 1

Its strange because the shadows look good in other places. Any ideas what's going on here?

#995 posted by ericw on 2017/10/24 20:34:24

Is this the seam you mean?
https://imgur.com/a/IrMnN

Are the faces that meet in the rectangle I drew phong shaded? Are they on the same plane?

I guess it's the sample-point-positioning code not working properly. Is the map sealed? Sealing it may help if it's not.

Aside from that all I can suggest is tweak the geometry. Unfortunately there's no easy fix on the tools side and any time I adjust this code it tends to break some maps and make others better.

In general it looks like 0.15.9 was the sweet spot. I would revert to that but it can't handle faces that are partially covered, e.g. func_detail_wall.

#996 posted by Redfield on 2017/10/24 21:53:16

The map is sealed. I changed the geometry of the ground so that there was no seam between brushes near the shadow and the issue cleared up. Only the rock was a detail brush with phong, the ground wasn't.

It is tricky to get rid of all these seams. If I revert to using v0.15.9 can I still use bounce lighting?

#997 posted by ericw on 2017/10/24 22:06:16

Yeah - bounce was added in 0.15.5.
All the old releases are on the GitHub releases page:
https://github.com/ericwa/ericw-tools/releases/tag/ericw-v0.15.9

Sorry to hear but I'll try to fix it in the next release :-/

Edit

#998 posted by Redfield on 2017/10/24 22:07:38

Looks like I can use bounce. I may go with v0.15.9 for now. Thanks.

Ran Into An Issue With Some Lights Being Removed

#999 posted by iriyap on 2017/10/30 10:32:49

Tried re-lighting the stock id1, hipnotic and rogue BSPs with -extra4 -soft. The result is, many badly lit patches sticking out from brush seams and various corners are finally gone, and the shadow edges are just so much better, see an example here.

However, in hipnotic some maps lose some of their lights and become too dark. E.g. the start map loses the lighting from the two lamps in the room where you spawn, even if I run light.exe with no extra options. Any way I can fix this?

Some More Findings On This Weird Issue

#1000 posted by iriyap on 2017/10/30 12:09:38

Okay, so I ran hipnotic's start.bsp through several different versions of light.exe and the results are curious.

I've tried the original TyrUtils, then BJP's enhanced tools, and then finally found the original light.exe from the official hipnotic devkit. The exact same compiler that the original developers used. Still no dice, the map loses some of its lights if re-lit.

Why does this happen? Did they delete some entities from the compiled .bsp file to save on memory usage or what? Really disappointing.

First | Previous | Next | Last

You must be logged in to post in this thread.