Bounce lights and the light gem:

[Baal]

Thanks, that will be useful.

 

Although I think a constant falloff is the better solution. It makes sense that the light makes you more visible, it just should be in proportion with what you see in its surroundings.

[nbohr1more]

There is a plan to add cubemap projected lights with spherical falloff in an upcoming release so that will make the falloff behavior more predictable.

That said, the current "LightFalloffImage" method is pretty flexible. You can make the falloff pattern go bright to dim to bright again to dim again by

making that pattern in the texture... I think you can even invert the falloff pattern which would be ideal in your use case.

[grayman]

It wouldn't look as good without the specular portion. And we already use zone ambient.

 

The whole issue is not THAT important though. It's fine in most cases and you can get by without it. But where we use it, it looks damn good.

 

Zone ambient and ambient bounce lights are two different things. Zone ambient applies a uniform illumination to all surfaces in the zone. Ambient bounce lights only apply illumination to the surfaces w/in their light volume. So that's not a reason not to apply the ambient texture.

 

The relevant reason for not relying on the ambient texture of the bounce light is the lack of specular. So if that's important, then an ambient texture isn't the solution for you.

[grayman]

Are falloff images relevant to the LG illumination calculation?

 

When I worked with the "can an AI see this?" code, I found that the falloff images weren't available to the illumination calculations, so they couldn't be used. The simpler linear falloff method is used instead.

[nbohr1more]

Yes, but only in the sense that the player model is a real object that receives light and the falloff image also controls how much of it.

[Bikerdude]

• Zone ambient and ambient bounce lights are two different things.

So if that's important, then an ambient texture isn't the solution for you.

• we are using both in our WIP.

correct, but cant hurt to try and see what it looks like

[Baal]

I am aware of everything you mention in the first post, but thanks.

 

I don't know very much about the lightgem. Isn't that just rendered and lit like everything else but in a separate pass? I guess I'll have to try and put a constant falloff image on a light and see what it does.

Edited April 1, 2015 by Baal

[SteveL]

Are falloff images relevant to the LG illumination calculation?

 

When I worked with the "can an AI see this?" code, I found that the falloff images weren't available to the illumination calculations, so they couldn't be used. The simpler linear falloff method is used instead.

Yes, falloff works for the lightgem because its brightness is "calculated" by the renderer. It draws a white shape where the player is, using all light and shadow just like when drawing the main screen view, then captures an image of the shape and samples it to see how bright it ends up.

[Bikerdude]

I've added a tracker for the spawnarg: http://bugs.thedarkmod.com/view.php?id=4128

Whats the realistic time frame for this, I ask because would it require a new main .exe or could it be scripted..? so I could add it to an existing map.

[RPGista]

Hmmm, Im not sure I got what a "bouncelight" is either, but if im undertanding correctly, what I did in my map to simulate bounced lights was to set up a very low value projected light illuminating the shadowed surface, from the opposite direction and on a safe distance. So if you are walking inside the shadow area, the spot light wouldnt affect you much. And yes, if you walk right next to the source of it, it should light you up pretty well, but you can avoid that by simply putting the light source in an already well lit area, or above the player, facing downwards.

 

This would probably mean redoing many light setups inside the map though, so maybe an example for the future.

[Bikerdude]

using projected lights would be fiddly at best, better to wait for Steve's method.

[SteveL]

Whats the realistic time frame for this, I ask because would it require a new main .exe or could it be scripted..? so I could add it to an existing map.

 

There's no way I can see to script it unfortunately. I'll do it in the next day or two, but it'll be a 2.04 thing.

[Bikerdude]

There's no way I can see to script it unfortunately. I'll do it in the next day or two, but it'll be a 2.04 thing.

Morning

 

Ah in that case no rush, the wip will just have to be released as is and then updated when 2.04 is out etc.

[SteveL]

I added a "lightgem" spawnarg for lights that defaults to 1 a couple of days after the above posts. grayman has raised a point that's worth debating though: should this spawnarg also affect the visibility (to AI) of other things like ropes and bodies? At the moment it just causes the light to be ignored when calculating the player's lightgem. If you're using it in a map though, would you expect or want it to affect AI sight in general, not just the player/lightgem?

[nbohr1more]

Making these bounce lights affect AI visibility would seriously limit the use case here as it would make bodies (etc)

just as "unnaturally bright" as the player.

 

If we had an arg to invert the falloff so that the light_center was darkest and the volume boundary was brightest

then we wouldn't need to exclude these lights because they would act like real bounces.

 

As a simple workaround option, neither player vis nor AI vis should include these lights.

[Bikerdude]

As a simple workaround option, neither player vis nor AI vis should include these lights.

This was the solution I was after.

[SteveL]

If we had an arg to invert the falloff so that the light_center was darkest and the volume boundary was brightest

then we wouldn't need to exclude these lights because they would act like real bounces.

Wouldn't that give the lights hard square corners?

 

As a simple workaround option, neither player vis nor AI vis should include these lights.

Thanks, that's +1 in favour of their not affecting AI vision at all (as opposed to their ignoring only the lightgem).

 

Perhaps rename the spawnarg something more generic like "ai_see" instead, still showing up in the editor and defaulting to 1.

[nbohr1more]

 

 

Wouldn't that give the lights hard square corners?

 

 

It would if your light volume did not extend past the wall of the room (etc) but since we are targeting walls with this type of

light, this scenario would be rare. Of course you could also modulate it a bit with a custom projection image.

[grayman]

I vote that the object illumination code use the spawnarg in the same sense that it'll be used for lightgem illumination, and that the spawnarg name be generalized. "ai_see" is fine.

[SteveL]

Thanks for the feedback all. Done,

[Tels]

Should these lights also not contribute to the "ambient light" with the ambient zoning system? E.g. must the script code be updated to ignore such lights?

[nbohr1more]

You could include them in ambient zone calculations but I presume you'd want to reduce their statistical weight or influence there.

To some degree, these act as an alternate ambient model so I guess it depends on the mapper preference.... FM authors?

[SteveL]

I'm agnostic about that one too. Presumably we're talking about some fairly dim lights here, and don't people tune the ambient multiplier to suit the room anyway?

[Tels]

What I meant was that the code currently calculating the dynamic ambient light does NOT exclude these lights and if they are fairly close to the player, they probably increase the ambient quite a bit.

 

The same problem exists with fog lights, ambient lights (which are usually huge, so they are weighted unfairly, too) and the player lantern.

 

Basically, every light that is either huge, or very close to the player.

 

These should all be ignored in this calculation. And I think any light with "ai_see" "0" should be, too. Otherwise these lights are ignored by AI, but they raise the dynamic ambient, which then makes the AI see better...

[duzenko]

The logic behind this thing is confusing me

How come visible lights aren't supposed to be affecting LG and AI? Quite counter-intuitive to players as well