I am working on a project and have run into a lighting issue. So I made a simple structure to test things. This is an enclosed level consisting of a corridor and two rooms branching off left and right. The whole thing is made with the default engine cubes scaled appropriately.
The room lights are rect lights and Lumen is being used. Those lights are on their own level.
In the editor when without playing the level, if I hide the light level the scene is black.
However when I play the level and I use a switch to turn off all the lights, they go off but the scene does not go black, I get this: (There are no lights on in the right room where you see the lighter area in this image.) It is almost like these is a baked light in place but no baking is used.
i cannot replicate that. how does this working exactly? i created a level for the lights and loaded them in as a level instance. i can hide them and it fades to black. are you using any emissives or anything that would stay resident and keep the light on? a lil bit weird. yes.
You really shouldn’t use colors with levels that are above 0.95 or lower than 0.05. For a pure white wall, you’d probably want to pull it down to around 0.9. But this sounds more like an autoexposure issue, if it’s persisting when the lights are turned off.
This is with auto-exposure off. So the pure red/yellow is not an issue or auto-exposure.
This is all being done on a Mac and does seem to be a “bug” in that the fade to black does not complete but just stops part way. I was messing around with some settings in the editor while the level was still playing and the fade to black completed but I have no idea why. I could not replicate the fade again. So I am stuck with this.
So there does seem to be an issue of Lumen cleaning up after itself and it takes so long.
So a blackout jump scare seems to be impossible.
I guess I could fake it with a lights level, which includes the glowing panels for the roof lights and a level with the panels only and no glow. (The switch correctly turns off the glow, so that is not the issue in the current example.)
ohh. that doorway is open to the outside. it’s actually a straight down directional light entering the room from the outside just bouncing around. actually really good GI.
and it did trigger a complete fade. However it did take forever as your video shows.
I then ran the code again with the 1 changed to 0 and that also triggered a slow fade.
This would seem to suggest that it is Lumens cache/resampling that is not getting updated correctly or not being completed before the next frame is drawn.
This would also suggest that the problem will be worse on lower performing hardware and maybe OK on a decent machine.
i reckon this is a rare usecase scenario. too me it looks like it clears the lumen history frames one frame at a time, instead of wiping the whole memory instantly on keypress and it’d be rebuilding it on key release. makes sense from a compute load balance perspective, but for the jumpscare content it should be entirely wiped out, flash and be rebuild. game graphics mechanic.
if you got the source code i’m sure you could find a way to implement that. : )
or maybe you wanna try to disable lumen mid game play and render clean black, and re-enable it after your jumpscare. that’s a whole art/compute pipeline switch tho.
well… i’ve gone thru the cvar list and flicked all the switches i deem necessary. it does a instant black out, now. and it rebuilds everything upon release. it’s up to you to save the states of the cvars for “safe coding” practice and your choice how you trigger it and keep it in this “disabled” state.
