I like placing the lights myself for lava, gives better control. 

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. 

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 :{ 

I'll check it out - I never test those, but hopefully it's easy to fix. 

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. 

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. 

Thanks! 

 

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? 

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 :) 

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. 

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 :/ 

� but _dirt -1 did! \o/ 

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. 

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. 

added the _sunlight3 stuff to worldspawn

https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd 

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? 

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.