Just an update on this. We think the only way that we can reliably get the lighting working on Android (for now) is to use the island settings (FC1.0) for the postprocessing effects.
It’s really annoying as you can’t see the lighting changes in UEFN.
So you have to tweak and test, and hope.
When we revert to our old lighting rig it works perfectly when connecting and testing from UEFN to Android - but fails when testing an Island code on Android published from the same build.
I’ve noticed that in your editor screenshot that you have both explicit lighting actors (DirectionalLight, SkyLight) and an active Time of Day Manager (TODM) enabled which also has those same components built-in.
I suspect that is likely causing this sporadic blown out lighting. There should only be a single DirectionalLight/SkyLight in your map and likely which one becomes active will be dependent on which one loads in first.
Could you try either disabling the TODM via WorldSettings > Disable All Time of Day Managers or hide your DirectionalLight/SkyLight and see if that resolves your issue?
We’ve exposed access to a number of lighting setups, but they aren’t meant to be used at the same time. More details on the use cases can be found in our Lighting Quick Start Guide.
OK - we need to use the Volumetric Day sequence devices to alter the fog density on different portions of the map (AFAIK you can’t do this with Exponential height fog?) - and we experienced quite a few bugs when we tried to use cinematics to control the fog density. However we left the lighting aspects of these unticked, only using them for the fog - and if I recall we couldn’t then control the position of the light independantly of the time of day. Will double check but I’m pretty sure that’s why we ended up where we were.
Will report back - but to sum up:
we need a lighting setup that lets us control the density of the fog in different areas
We want to be able to control the position and intensity of the sun independantly to that
We need to also have the B&W post processing effect.
When we tested having removed only the post processing effects we didn’t see the issue, however this may have been a coincidence
I see. Could you elaborate a bit more on what you mean by “control the position and intensity of the sun independently to that”?
Do you mean you want to control the sun independent of the DaySequenceDevice volumes? Or that you want more control over the sun and intensity over the course of a day night cycle than what the DaySequenceDevice provides like animated intensity over the course of the day?
You could create a non-volumetric DaySequenceDevice and override the sunlight with options to either set a Fixed time of day or alter the arc of the Sun rotation (RotationX/Z).
The Enable Sun Component setting does turn off the directional light in the TODM for the effective volume of the device by toggling the visibility of the component. However that whole category only applies if the Sunlight category checkbox is activated as well. That said, that’s only viable if you can manage the visibility of your own DirectionalLight as clients move in/out of the volumes which I don’t believe we support at the moment.
As far as positioning the light goes, yeah unfortunately it’s not as easy as positioning a standalone DirectionalLight actor. I believe to get roughly the same rotation, you’d be looking at a Fixed time of day of ~4.28125 and setting Rotation X/Z to 0.0. Rotation X/Z drive a parent transform above the sun component. That would result in ~(0, -13.86, 0). Unfortunately we don’t currently allow you to inspect the actual TODM components, so the best you can do is eyeball it atm. We do this because the TODM is dynamically spawned so editing it directly in editor would be confusing as those edits would not persist. But for read back, that’s a valid use case. I’ve made a note to revisit that UX.
It does appear that the DaySequence device is the only way you could achieve volume based fog densities at the moment, so working through these issues to work with the TODM is likely the only path forward if that’s the primary constraint.
Thanks for the response - not having the shafts of light is the biggest issue for us when switching - it really added to the game. So much so we’ve reverted to island settings to manage the fog and postprocessing and are using the directional light for the sun and shafts of light.
It’s by no means an ideal solution as you cannot see any of the island settings take effect in UEFN and we can’t use post processing volumes for things like blackouts (and we really liked defining areas of fog) but it’s what we’ve had to fall back on to get it looking the least worst on the most platforms.
The best solution for us would be the ability to define different lighting on a per platform/setting basis.
Also worth mentioning I think we saw this issue very early on when using Exponential height fog - can’t prove it right now (we’ve tried so many combos to fix it)
Ah that’s unfortunate. I’ll make a note for adding light shaft support to the DaySequenceDevice. I don’t see why we couldn’t have that.
There is a LightingScalabilityManager that somewhat does what you’re asking. It allows you to associate actors with the manager on different scalabilities and the manager will then toggle the visibility of those lights based on the active scalability.
