Well, you can copy/paste lights more easily from one map to another than worldspawn keys, and you can specify all the wait/delay/color/style/etc shenanigans you want instead of just a brightness. I like scampie's method. 

 

That has the same limitation tho ... every time you use that texture, it's going to emit the same light value. 

I didn't say that's why I liked it. It seems like a pretty reasonable way to set per-map texture light automation if that's a thing people want, I just don't personally. 

I WOULD use a system like this, because most of my lighting I just copy identical lights around everywhere anyway. I never really tweak individual lights that often.

I think the value here is that you can use it when you need it... if you have a million little 16x16 lights that are mostly accents, it makes it very easy to set them all up as a single _surface light and you can tweak them all at once. But you aren't required to use the system for all your lights, and can do per-use lights for anything else and tweak to your hearts delight. 

Adding worldspawn keys for the various -dirt flags should be super easy.

Awesome shot, quaddy! It makes me curious how much phong shading within the light tool would help avoid some of those sharp edges in the lightmap - interpolating normals of the sample points if the angle between faces is leas than some value. 

...more along the lines of some very specific textures in the control of the person making the level instead of someone else deciding for you what the brightness, delay etc was going to be.

Most (not all just to cover the bases) levels use the same textures over and over again. So, for example, *lava might emit a bright but short radius and it "Should" be consistent throughout the level.

Lighting, for me anyway, was always where I stopped mapping. I'm too picky about it.

A tech level might use the same light "Fixture" several times over so consistency might be desirable in some cases.

There's nothing stopping a mapper from taking tech_lite(X) and renaming a copy in the .wad as tech_lite(X+1) with tech_lite(X+1) having a default lightmap value attached to it. 

But you aren't required to use the system for all your lights, and can do per-use lights for anything else and tweak to your hearts delight.

If the light texture is getting the same light entity cloned onto it by the compiler every time, how would I create an exception, besides duplicating the texture? 

Sorry, I guess I was confusing by stating something obvious for no real reason.

I simply meant that you could set it up for just the light textures you wanted it use it for (such as lots of little lights), and light by normal methods for anything else (such as you might not set up larger light textures and do those by hand to fill the specific areas they are used it) 

I really liked when doing Quake3 maps that I just put a light texture on something, and BOOM, it was lit. But I would get really annoyed having to edit a .shader, or create a new one, to modify the lights, for me it always feels like a distraction to leave the editor to change things... so being an object you set up for yourself in the editor is key for me. And if some mappers don't want to use the system, than there's nothing wrong with doing things the old fashioned way, or just limited use of it! 

sorry, I ramble a bit 

You COULD do something like that to create sort of a lighting prefab system tho ...

Like in the worldspawn set up a

"light_hot" "light:450,wait:4.0,blahblah"

And then in your light entities use:

"prefab" "light_hot"

to refer to that setting ... might be interesting.

Or not.

Whatever. 

When I was making honey I had already written a converter from my editor's native format to .map, so for a moment I toyed around with adding functionality for a light stylesheet of sorts, where you'd place a light, give it a "class" and it would grab the correct values from a file. What was nice was that it could also generate secondary lights, so you could place a single spotlight in the map, and the tool would create fill lights and bounce lights in the right places.
In the end it wasn't really worth it and I refactored it out because copy/paste is so simple in the editor anyway, and mass-changing values was also quick because there were some advanced search tools that let you find similar entities in an instant. 

"and mass-changing values was also quick because there were some advanced search tools that let you find similar entities in an instant. "

Hmm? I don't think I know about this ... how and in which editor? 

It was our in-house editor at Starbreeze. There was a really old version released to the public, but it's kinda shit tbh.
The map format was fairly similar to Quake, so writing a converter wasn't too much work. 

Ahh nice. Yeah, Ogier always looked interesting to me from the screenshots. 

"ogier" is Polish for "stallion" 

for entities. Map->Entity Report

You can bulk-edit keys n stuff. 

Hello chaps, long time lurker etc. Very impressed with what you've done to this dear old game, so much that I thought I'd have a bit of a play around, which led me to this little issue (unless I'm missing something obvious, which is quite possible).

Dirtmapping happens after the usual lights have lit the map, which makes sense otherwise there would be no lit surfaces to make "dirty". This usually looks really good, but I noticed a situation where it is problematic.

Imagine a light inside a small alcove. The dirtmapping makes the alcove very dark, despite the bright light, because the inside surfaces are all very occluded.

Here is an image showing what I mean (I have used -dirtscale 2.0)

http://i.imgur.com/XKHEGrf.jpg

I can't think of a nice simple general solution to fix this.

One option I thought of could be to create a property you could add to light entities - e.g. "postdirt" "1" - this flag would tell the light compiler to actually process this particular light after the the dirtmapping pass. What this would mean is you could create small, bright, but low radius lights in places like the alcove pictured, in addition to the main alcove light, which would then just brighten the insides of the alcove up again after the dirtmapping has done its thing.

I'm sure there are other ways to slice this particular sausage though. 

.. isn't ideal.

Back when i implemented it with ydnar, AO was a bit of a "novelty".

The main inspiration for this particular one came from "dirtmapping" shaders for Mental-Ray, where it was applied as a dirt mask and not really used for lighting, although it could be made to work with that too.

I believe someone later added a new Q3Map2 switch that only applies it on map-wide ambient light, which would be more correct.

That would be an option, on top of making lights able to opt-in for the AO ( "_useAO" key ? ).

That way you can make low fill-lights that act as localized ambients, while main lights are not subscribed to the AO and will act more physically correct. 

That sounds like a good way to go. Having an AO opt-in/out flag on individual lights would give us total control over the look. 

Cool, didn't realize you did the original dirt code rebb :)

Yeah, some sort of key to opt-in on a per-light basis sounds like a good idea (or opt out?) I don't know if would be overkill to have flags for enabling dirt on the minlight and dirt on the sunlight, too. 

I'd probably go for opt-in as the default behaviour (if none is specified) on all lights, as I think it looks good most of the time - it's really just the light-in-an-alcove sort of situations where it looks bad. 

it's coming along nicely, and also looks like it's straightforward to have adjustable dirtscale/dirtgain per-light, so you can have bigger AO shadows in outdoor areas, etc. Only the dirtmode and dirtdepth settings need to be constant across the map. 

I guess it depends what type of lights the mapper places more often, low fill lights or main lights. AO is mainly an effect meant for ambient lighting and can look strange when applied on main lights or sunlight.