DRD Team

Hello,

I noticed that dynamic lights in the dev builds are behaving slightly different than the 2.2.0 version. As you can see in the dev build the dynamic light is more intense on the ground, even though it's on the wall (same thing vice versa). It works fine with the official build. While in general this isn't very noticable, it is when you play with a flashlight mod for example.

Dev build (2.3 176, same thing with 232)


2.2.0

What's the mod which shows the bug?

This issue seems to reproducible with any dynamic light source, like this one for example.

EDIT: It started with this commit and the next one didn't fix it.

Not surprising. This mod is implementing the flash light in an absolutely bad manner that just doesn't work with proper light attenuation. It fires a hitscan and then places an actor with an attached dynamic light close to the wall. I really don't know if I should compromise the system for something this poorly done.

That's nothing new. That's a technique old late 90's shooters used for flashlights; Half-Life (GoldSrc version) and Unreal included.

Alright, thanks for the explanation. Since it's a cheap method I guess there's nothing I could do with it, so I just delete it from my mod.

This was one of the first things I noticed with the new physically correct lights and I agree 100% with Graf Zahl:

It is a shit way to do flashlights.

(I do it this way for my mod too so don't take offense. Realizing now that it's a bad idea that just won't work with the attenuated lights)

The only proper way to do flashlights in games in 2016 is directional spotlights...

So, attaching a dynamic light to a puff is considered bad now?

The puff itself will cause proper lighting but let's not forget: The puff is the source of the light, not the flashlight the player holds and with proper light calculations that looks odd.

To be fair, the hitscan-point method of the flashlight was likely developed before the proper attenuation methods became widespread. However, Unreal has always used attenuation calculations and it still used that method. My guess is, it made the hitscan target object big enough that it backed out from the wall a bit so that it would look less odd.

Nevermind the flashlight. The problem is that this change affects puffs spawned by hitscan attacks in general. Here is a weapon that is not a flashlight: Skulltag's BFG10K. It's a hitscan weapon, with its puff having a dynamic light attached to it.

(Upper is from 2.2.0; lower is from 2.3pre-222-g6a6263a)

Hm, ok. I think I'll handle the light attenuation differently then, it looks like far too many mods depend on it being off.

I believe under these circumstances the best solution is to

- add an explicit flag even for attached lights
- add a global MAPINFO option so mods can enable attenuation globally if they want to and
- add a user switch that can enable and disable it globally.

Of course any light explicitly being set to either be attenuated or not attenuated will never be subject to any of these global settings.

The main issue here is that the engine doesn't know any concept on the light source's size. It's just an infinitely small point. Normally, anything within the actual light source should always be fullbright with the brightness falloff only starting with larger distances.If it was implemented like that, attenuation could work globally.

I have reset the default to the old method. I'll do attenuated lights as an option only because it'd break too many existing mods.

This has been addressed to make light attenuation opt-in, so default will be the established behavior.