Constant Light With Sharp Falloff

General Development Source 1
#1

I am trying to configure some lights that have constant or near-constant attenuation up to a certain radius, but then fall off abruptly (this would dramatically help with the ‘lighting pileup’ problems that have been dogging me since Day 1 of BMPD). It is possible to set up something similar using the 50% and 100% falloff distance values with the ‘hard falloff’ option set…

1920×1080

but every setting I’ve tried for the 50% falloff distance (the 100% falloff value determines the ‘stop’ radius, which I want to configure arbitrarily in about the 200-500 range) results in quadratic-like attenuation (there’s a real constant light on the right side of the above image, for comparison).

For a while I thought that the ‘maximum distance’ parameter controlled this and it was broken only in the most recent version of the engine (and that it would be fixed in the Xengine Update), but now I find that it is seemingly nonfunctional in all versions of the engine. Not quite sure what to do from here.

#2

I’m no mapper, but have you tried setting the 50% distance to (or near) 0? Or to (or near) the same distance as the 100% falloff?

EDIT: For that matter, what happens if you set the 50% falloff level to be greater (maybe even significantly greater) than the 100% falloff value? Maybe the 50% distance is setting a literal half-life ( :smiley: ) for a geometric curve of attenuating light levels, but the 100% distance and hard falloff option override that to zero at that distance.

#3

Works fine for me:

1343×712


1147×660

#4

This actually seems to have done the trick.

1920×1080

There is the one undesirable property that the light in question must be made extremely bright (in the hundreds of thousands or even millions, the one shown here has a 50% falloff dist of 0.01 and a brightness of 500000) and I can see these being kind of hard to work with, but overall I think I am on the right track.

I remember experimenting with similar lights much earlier on, but that was with a bunch of other factors that may have made them unsuitable.

#5

UPDATE: These lights cause some very strange artifacts on props and NPCs at various locations where they either are close to the light or close to its falloff:

1920×1080

This might get fixed in the Xengine update, but until I know more I’m really not sure if this is the right way to proceed.

#6

Try a normal brightness but an enormously large 50% falloff distance instead. Much bigger than your 100% distance, if it will let you.

#7

That, sadly, causes the hard falloff to be pushed out to the larger 50% distance. Making the 50% and 100% distances nearly equal just results in very severe artifacts, most commonly a very bright ‘ring’ around pitch blackness.

#8

Did you just… completely ignore my post?

#9

No, I just didn’t see it because it was tiny compared to the others.

Using the settings provided I get something with a significantly brighter ‘center’ and dimmer corners than the constant, which is what I’m trying to avoid:

1920×1080

#10

Yeah, but that’s just down to the size of the room, because this looks like the one on the right:

1366×768

#11

@Admiral Sakai I believe the reason you’re having so much trouble with lighting is that you’re using it in ways it was never designed to be used.

Let me explain. Like all game lights, Source lights aren’t very realistic. They don’t behave as real lights do. We can work around this with clever usage of point lights and spotlights, but the fact remains that these lights don’t work realistically, and you’re making a lot of unnecessary work for yourself by trying to make them do so.

I’ll bring up a picture from one of your threads to illustrate this point:

1680×1050

Now, this is close to realistic office lighting. There are very few shadows, and the whole place is brightly lit. But there’s two problems here. One: the near constant lighting washes everything else out. Notice how flat everything looks with so few shadows? That’s because they help our brains perceive depth. In addition, the usage of constant light has all-but-completely eliminated the shadows of static props; creating a rather unrealistic looking floor. Notice how the floor underneath the desks isn’t even slightly dimmer than that of the floor around it? Indeed, the only shadows I can see here are the extremely dark dynamic shadows cast by physics props, which contrast very sharply with the lack of shadows anywhere else.

Two: that’s not how it’s done by the devs in their pre-disaster area of Sector C.

1920×1080

Notice the shadows, how dim the room is overall. In real life, this lighting would be a pain to work in: it’s way too dim to see well, but it’s what they went with because it looks much better.

On a more technical note, you’d probably achieve better results by placing a higher density of more focused light sources rather than your current setup of that makes large use of a few constant light sources.

#12

If you add more focused light sources, won’t you have a higher chance of running into the lovely “TOO MANY LIGHT SOURCES ON BRUSH” compile error?
Or does that only happen for named lights?

#13

Pretty sure it only happens for named lights.

@jadebenn, I think you’ve hit the nail on the head as far as what the problem was with my earlier attempts at these maps; currently I am shooting for a kind of a happy medium where most areas are bright enough to be a pleasant workplace (unless they’re, like, a maintenance closet or something), but there’s still a clear falloff as one gets further and further away from the actual light sources. I’ve switched to the “more, smaller lights” paradigm and it seems to be working pretty well so far; it’s difficult to work on these maps ATM though because decals, NPCs, and props are all currently very broken in how they light relative to world geometry and the engine fixes involved are IIRC wrapped up in the December Xen update. I’ll be posting screenshots with a good amount of the glitchy stuff removed soon, however.

#14

Keep in mind that these are a work in progress and there are a lot of things in Black Mesa currently that just don’t light properly, but it should give you some idea of what I’m going for:

1920×1080
1920×1080
1920×1080

#15

I wonder why you’re not getting prop lighting. You should at least be getting point lighting, if not vertex.

Are you compiling with -staticproplighting?

#16

I deliberately disabled prop lighting because things like the billboards light waaaay too brightly.

#17

You could probably fix that by attaching the billboard to a lighting origin placed in a slightly dimmer room.

#18

It’s going to be fixed in the Xengine Update so I’m not really going out of my way to deal with it.

#19

Oh, okay. That makes sense. Overall, that picture is a massive improvement. Bright enough to be plausible, but not enough to wash everything out. I assume you’re still working on the color, so I won’t comment on that.

I am confused as to why there still appears to be no shadows cast on the floor by props. I assumed it was the constant light washing everything out in the first picture, but that shouldn’t be the case here.

#20

It’s a combination of the lightmap density of the floors being low and many of the props having their shadows disabled, which is actually inherited from the canon map (although it’s less noticeable there because the map itself is so dark). I’ll probably fix it when the static props themselves aren’t such a giant pile of horrible.

The color is about as good as it’s going to get on the current engine build, although once Black Mesa adds more support for color correction I may go back and tweak it. The textures are actually my own, as the canonical ones do not work well when taken out of that dark environment, and I may tweak their coloring as well (I’m particularly dissatisfied with the ceiling tiles, which look way too uniform and don’t really show well the occasional darker tile that’s on the canon texture).

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.