Considering my lighting knowledge is terrible at best, here's the bit where I go: "I've seen surface lights mentioned but how does it work?" 

that screenshot reminds me of something that I experimented with.

http://quakeguy.tumblr.com/post/120732856652/stained-glass-window-casting-light

I have a feeling that however you did it might be more competent because you have managed to get the actual texture to look like it's projected, whereas mine is a bit more of a hacky workaround using alpha masked textures and a couple of different coloured lights. 

_surface_spotlight sounds cool. So it just sets a spotlight based on the surface normal or something? 

Stained-glass window lighting to me always looks exactly like those rainbow-splatter lightmap glitches you'd see in games from the early 2000s that remind you that you need to update your OpenGL drivers. 

Yep, it sets the spotlight based on the surface normal. It's just a little convenience thing, I always found setting "mangle" to be a pain. This way you can rotate the light fixture brushes any angle and the spotlight will always shine the correct direction. :-)

oGkspAz, there's an example screenshot + entity at the bottom of: http://ericwa.github.io/tyrutils-ericw . Basically add key/value "_surface" "texname" to a light entity, and copies of that light will be cloned on all faces with that texture name. 

Surfaces lights in these tools are pretty simple things.

You place a light, anywhere in the map, and put whatever _color and light and delay settings you want on it... you then put "_surface" "NAME_OF_TEXTURE" on that light, and the light compiler will automagically copy that light around just in front of any surface with that texture, spaced apart every 128 units.

It's best for things like textures that are clearly light sources, a nice convenience so that you can mess with a single light once, and all of them will be lit up. It can also be good for something like Lava, and doing the legwork of lighting it all up for you. 

A minor thing though is that if BSP chops your surface up, you get a new light for each face which can make things brighter than expected in places. This seems to be a problem with liquid surfaces mainly. 

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.