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
Yeah 
I like placing the lights myself for lava, gives better control. 
Scampie 
Thanks for the 128 units clarification.

I wanted to ask that before, but couldn't formulate the question properly. 
 
I don't know if there's an option for this already, but it would be cool for the dirtmap to be sized accordingly to the angle of the surface. This way, it would give a better impression of being dirt, since it would appear to have been affected by gravity and friction (horizontal surfaces gets the most dirt, vertical surfaces gets the least dirt).

Implementing this through an adaptive -dirtgain would probably be enough. -dirtscale would have to remain the same, to ensure equal shading at the edges. 
Antilights Broken? 
As far as I can tell, antilights (lights with negative value) no longer work - can anyone verify?

I was using quite a few of these :{ 
Argh 
I'll check it out - I never test those, but hopefully it's easy to fix. 
Cheers 
to elaborate:

One of the things I made use of before were antilights with a "style" value - crucially these only subtracted light from other lights with the same style value. 
Kinn 
Are you using minlight? 
 
Ok, they should be fixed in the dev build: http://quakespasm.ericwa.com/job/tyrutils-ericw/

I just made a mistake when reworking the light culling in the last release (to make -gate give a proper speedup), and it was culling all of the antilights.

The special behaviour of style should still work. I didn't realize they would work that way at first, but it makes sense, because whenever a light with "style" set hits a surface, there's a new lightmap allocated for that style number - so a negative light with that style number would only affect that separate lightmap. 
Awesome 
Thanks! 
Thats A Neat Idea 
 
_surface_spotlight Workaround 
It seems like when _surface_spotlight is set in the entity the actual surface no longer illuminates as it would without. Is there a work around or is this a bug? 
I Think That's Intended 
To get a regular surface light in addition to the spotlight, just have two template entities, one with and one without _surface_spotlight set. You can have multiple lights with the same _surface value :) 
Slapping Forehead! 
Thanks that will work - and it totally makes sense. 
 
I think dirtmapping should not be applied in points where there's a light close by, 16 or 32 units maybe. The low resolution of the lightmaps makes small surfaces in cramped places close to a light go fully dark. 
#220 
Hehe, I was thinking something similar, but it needs to be controllable per light.

Remember you can work around all the issues currently by using _nodirt on a per-light basis. However, that requires more light ents to be added, which may get fiddly and annoying as the map scales up.

A way of doing what you are saying would be to introduce a _nodirt_radius key on a light, which means the light gets "dirty" as normal except on surfaces within (_nodirt_radius) from the light.

the transition between nodirt and dirt needs to be blended in as well to avoid ugly transitions. Ugh, maybe another key is needed to define when the blend starts :/ 
_nodirt Didn't Work 
� but _dirt -1 did! \o/ 
Mankrip 
sorry I forget the names of the keys, I think they have changed once or twice as the feature developed 
 
No problem; I'm still using my custom version from when I implemented lit water support. 
V0.15.4 Released 
change list & downloads:
https://github.com/ericwa/tyrutils-ericw/releases

Mostly bugfixes, except there is a new _sunlight3 that comes from the bottom hemisphere, instead of the top (_sunlight2).
This is mostly for maps floating in the clouds, where you want skybox under the map that emits light. Combine both sunlight 2+3 for light coming from all directions, and use two different colors for crazy effects.

Also, the -parse_escape_sequences option for light is a gimmick that lets you make red text in door/trigger messages, which previously you could only do with custom QC. 
Updated Jackhammer Fgd 
Cools Stuff 
I'd like to see a little demonstration of the new _sunlight3. 
 
I added to my privately hacked tyrlite branch a "domelight" (this was pre-sunlight2), with control over color and intensity coming from straight up, the horizon, and straight down, blending between them (even though I'm not really working on a map that would take advantage of that.)

There's enough ways to light a world from the sky that moving stuff like this from infinitely numbered worldspawn keyvalues to a light_sun entity would be prudent, except for the "no spawn func" errors it would produce. Does stripping an entity from the bsp seem dangerous or counter to some method of production? How often do people really re-light a BSP without re-BSPing it first? 
 
info_null is ignored by the game engine, so you could have an info_null full of sun properties.

But is it really better than just putting it on the worldspawn? 
Put Them In A Light Entity 
and flag it with a special key (eg _sun: 1) to tell light.exe that this is just your holder for the sun properties and not a normal light

classname: light
_sun: 1
_some_cool_sun_property: 21.463

I have spent maybe 2 seconds thinking about this, so there may be a better way. 
 
is it really better than just putting it on the worldspawn?

Just feels cleaner to keep the sun properties encapsulated in a single dedicated entity that you can copy 'n' paste between maps easily.

Also, getting a bit carried away with this...but with a sun as its own entity - you could support multiple suns by having multiple entities. 
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.