Hybrid Dynamic Lighting

Community Community & Industry Discussion
1

For a long time, I had been annoyed by the shadows of stationary lights. The reason for that is that I had been making maps for various Call of Duty titles before I started working with Unreal, and the spot lights on CoD would turn themselves into dynamic lights.

These lights turn of when they go off screen and turn on again when the camera turns to them.

Also on some titles, we were able to decide how many dynamic lights would work on the options menu (4-5 on average).

Like directional lights, I don’t know when cascaded shadow maps will come for stationary lights. However, I almost got what I wanted with a BP actor.

There is a light that is stationary and movable in the BP actor, and there’s a cone mesh and a collision so as to check if the light is on screen. (this mesh has a transparent material)

Here’s how it works. I defined some base functions (radius, intensity, angle etc.) and these functions simultaneously interact with all the objects inside the BP. For example, the collision ball and the cone mesh enlarges when radius is increased.

After asigning certain values and rendering the map, the intensity of stationary light is multipled by 0 and movable light’s is multipled by 1 when the character enters the BP actor. That way, the stationary lights and their shadows stop functioning and, but global illumination lights stay and a sharp movable light works on top of that.

**Lightmap Density.

HighresScreenshot00001.jpg
HighresScreenshot00001.jpg1743×980 353 KB
**

Only Movable

Movable.jpg
Movable.jpg1743×980 151 KB

Only Stationary

Stationary.jpg
Stationary.jpg1743×980 161 KB

Stationary/Dynamic Hybrid Lighting.

StationaryMovable.jpg
StationaryMovable.jpg1743×980 161 KB

There were limits to those lights on CoD (out 120, inner 90. it’s 60-45 for unreal), so I applied those limits. The reasonfor that is because when maximum values are used, shadows reach too wide and it may cause it to go out of the bounds of the cone mesh.

bp4.jpg
bp4.jpg1104×602 130 KB

You can change their refresh rate by changing time. I made it refresh once in every half second.
We are still working on this lighting system. I’m sharing it with you as it is because I can’t seem to make it any better than it is. I would love to hear them if you guys have any different opinions or ideas about it. Thanks in advance.

I would like to thank the community member jacky for his valuable help.

2

Honestly, from my short hour long use of it, it works very nicely.

What I would definitely recommend, depending on environment restraints among other things. Is not something particularly related to your lighting setup, but dynamic lighting in general. You should setup a base lighting throughout your level with static lighting (I highly recommend Luos’ GPULightmass if you have powerful enough hardware to bake the level. Much higher quality shadows and lighting.) And you should add a distance culling variable to your lighting setup, so that if you’re far enough away that the dynamic lighting doesn’t add much impact over the already baked static lighting, it will be disabled, saving potentially a significant amount of performance depending on how many lights and objects you have and how aggressively you wish to cull the lighting.

I added such distance culling nodes to the construction script and a few nodes at the end to limit the attenuation radii in relation to the timeline curve. Same thing you did with the light intensity but with the attenuation radius. I did this because, afaik, and please someone feel free to correct me if I am mistaken, the light is still considered to be active and projecting by the engine even if the intensity is set to zero. But by affecting the attenuation radius instead, you’re effectively clamping the amount of lighting calculation that needs to be done per light because it’s limiting how far the light projects. Honestly, this solution could be superfluous and unnecessary, as I haven’t tested it extensively enough yet.

Another thing you could definitely do is migrate some of the boolean logic and arithmetic to C++, because its easier for the engine to process a single line of code than an individual node. Granted, there aren’t any ticks in the spotlight so I don’t think this will have a significant performance boost, but if you’re trying to squeeze out as much performance as possible, might as well.

Lastly, depending on how much, if any, dithering your mesh materials use, you should play around with the contact shadows. It can add a significant amount of visual detail and impact with very little or no performance drop, especially if your levels have a lot of tiny debris like mine do. Like (pebble, trash, scattered papers, etc.)

Ultimately, this is great! I’m sure a lot of people will be very thankful for what you’ve done as I’m sure there are plenty of artists and devs (including myself), that either never noticed this, or did notice (my case) but didn’t notice that the moveable light did not suffer this same issue.

I plan to keep on testing and reporting back with any noticeable finds!

3

This looks great! Is there any performance impact when using this kind kind of lighting setup?

4

When it get close to spotlight he enters movable from stationary in 0.5 seconds and during this entry they both work at the same time. I guess this is the most expensive moment of it all. I couldn’t add something still upon this system. I’m working on a map and I will test this performance test on that map. Stationary and Movable light how costly it is, the more expensive the system.