Given I am set to create documentation/videos on this for launch, can I have someone verify if I did this is a technically sound way? So I know that I am able to explain and demonstrate this correctly.
Based on previous discussions, this is what I came up with:
1.) Is there anything in here I should have done differently or is not good?
2.) I believe I got the mix between static and stationary right, and use of shadow (considering nothing is all too red), except for the little rock. The red thing beneath the playerstart is red. This is a physics actor. I don’t understand why that is red but the nearby geometry is not? Is this ok? It is a small object, but lets say I would have had several large physics actors instead?
3.) I have a mesh (fog plane) that only uses an unlit material and thus should have Accept Lights false. However Accept Lights is no longer anywhere in the properties. What should I do? I do not want the engine to waste a lightmap on this mesh. A similar situation would be when I have a mesh that is invisible in game, I would not want that to receive lighting either. Does the engine automatically fix this, or is this a forgotten feature?
Hi thanks!
Right so you are saying performance wise stationary lights should not be used when they do not cast shadows? In such case moveable lights should always be used (without shadow casting)? Correct? Because this is a major thing and I want to be sure I got this right.
Yeah I know static lights are less than great, but I can’t illuminate a level like this with just stationary/moveable so my current setup is my solution. I hope it is Ok? One of the problems I hit for example were my large ambient lights, I don’t know how else I could have done those?
Aha, so I need to change the modify frequency. A few months ago I had a problem with trying to make a light component within a blueprint static, rather than moveable, I take Modify Frequency can also be used to make a pointlight component static then?
The performance of non-shadow casting stationary lights and non-shadow casting movable lights are identical. Actually movable can be faster as they can be included in the tiled deferred pass.
What are you able to do with static lights that you cannot do with stationary or movable lights? Are you hitting limits because of stationary light overlap?
Yep, the light types differ only in modify frequency. We hope to make that clearer in the future. Static == Static, OccasionallyModified == Stationary, Dynamic == Movable.
Yeah I hit the limit. And if I turn off shadow casting on my ambient lights it doesn’t look as good, you’d lose out some on the darkness between objects then/light travels too far. I could place tons of small dynamic lights to counter that, but that is a lot of work and doesn’t feel userfriendly. Is it really that to use static lights for these very weak ambient lights?
I also raised my apartment building example several times in the past but never been able to get an answer to that.
3 Apartments above each other. Sunlight outside. Each apartment has a living room light, and a kitchen light. That’s 7 lights in total.
I see no way this can be lit in the engine as it is right now? You can’t turn off shadow casting at all on any one of these, and the overlap is impossible to avoid. I guess I can manually toggle lights on and off dependent on where in the level you are, but that is really annoying to do all the time?
Using static lights in that case is fine / expected.
For your apartment example, it is a limitation we’re aware of. In the future we hope to lift that limitation at some cost to performance.
To reproduce the apartments lit by different colours, could you use Levels and have lights on different levels affecting objects only on their level?
UE4 uses deferred shading. Any per-object masking of light influence adds quite a bit of cost and complexity: e.g. how to handle dynamic objects.
Is it possible that you could add parameters to clamp the range of a dynamic point light ? Here I think Positive XYZ, an Negative XYZ parameters would allow us to control the explicit range of a light. It’s a way to effectively constrain a light to a bounding box parameter and control light leaking.
