I’d like to prevent certain lights to affect other levels, which are streamed into the persistent level.
The UDK used to have option like Lighting Channels aswell as the option Only Affect Same And Specified Levels in the light properties, which would do the job I guess, but aren’t available in the UE4 yet.
which is done by baking the lighting in each level separately, which then leads to an error, telling me to rebuilt lighting, when streaming all these into the persistent level.
If I then rebuild the lighting in the persistent level, even when trying to disable levels by toggling the visibility off in the Levels Panel, I get this:
No bake lighting error, but unwanted light bleeding from the directional light in the left box (which would be the sunlight in my real level, the other boxes would be rooms the player can enter, which should not be affected by the sunlight).
Lighting channels are not possible with UE4 due to deferred rendering.
You also need to remember that anything in the persistent level will be in any sub-levels.
For instance, you’re directional light source that is in your persistent level (“real level”) will bake into any other levels, even if they are not visible.
In order to do this, you will need to have 4 levels using your example.
Persistent Level: Do not put anything in here that you don’t want to be visible or baked in any other sub-levels
Level 1: Meshes and Light Red
Level 2: Meshes and Light Green
Level 3: Meshes and Light Blue
When you build lighting you’ll need to do these all individually. Since the persistent no longer has anything in it, you will be able to make only the level 1-3 visible and then build lighting specifically for these levels. Hide and repeat for the next level.
When all is said and done you’ll have no lighting errors.
This is actually exactly what I already did in my example. But I have to bake the levels by opening each map individually. Which then leads to the “Lighting needs to be rebuilt” error, when playing the Persistent Level after baking them. If I try to bake the lighting of each level from the Persistent level (by hiding every level but the one I want to bake the lighting of), even through the directional light is in the Level 1 only, it still bleeds through the other two levels.
I am able to get the lighting needs to be rebuilt. Currently there are no plans to make this functionality better supported than the first method I described. Even though there is minimal light leaking.
One way to get around this though is to use the console command for “DisableAllScreenMessages.” While the Lighting needs to be rebuilt will not be cleared, it will no longer display on the screen now.
If you know that you’re lighting has been built the way you like this can be one way to get around a “warning” message like that.
Hi,
I’m fighting against the same problem for my level.
I have some oversized “rooms” and want to light the areas separately.
I’ve put all lights in streamed levels, nothing in the persistent except the streaming volumes, but I still have all lights affecting all levels when I open the main level.
I tried both methods to build my lightmaps: doing it in the main level, hiding the sublevels one at time and opening the sublevels. Nothing works.
This is a big problem for us, because the light building is very long and we are still not able to obtain the desired effect.
With deferred rendering it is not really possible to keep the light from affecting other areas. Using the methods touched on above is the only way, but you will still have the “lighting needs to be rebuilt” warning, although this can be overridden with the console command listed above as well.
Hi Tim… I suspected it, bu could you please clarify one thing? How having the “lighting needs to be rebuilt” warning affect performance at runtime? I always supposed that in that case UE uses a sort of dynamic ligthing… so we’ll have a lot of MIA (missing in action) fps
In the instance above it doesn’t affect lighting at run time because the error message generated from a workaround and no lighting actually needs to be rebuilt.
It’s also not a bug, since it’s a hacky way of getting the above method to work. If there were legitimately objects that didn’t have shadows build in the scene these would use dynamic lighting and cause performance issues.
This is a break down of how I did it above, which may or may not work in your case. It can be an involved setup.
All Lighting is Static/Stationary
4 levels/maps:
Persistent: nothing is placed in this level
Level 1: Couple of meshes and Red Light.
Level 2: Couple of meshes and Blue Light
Level 3: Couple of meshes and Green Light.
Since I knew these levels would be loaded/streamed in via my Persistent level I couldn’t just hide a level and build lighting for each with the light bleed from other levels. To get around this you can open each level individually by double-clicking on them in the Content Browser and then build lighting for each, save and close.
After this, going back to the original Persistent Level and loading in will produce the clean light builds as seen above, but the persistent level will assume lighting has not been built for these levels. It’s not going to default back to dynamic preview lighting, but the warning will be there thus the need to remove the warning with “DisableAllScreenMessages”.
I’m having a similar issue in 4.11 preview 7. I have an empty persistant level and have setup like you suggested, but I’m getting a performance hit even though on the individual levels im at 120fps 8ms draw. Pretty much my lighting looks correct but when I start the level I get a lighting unbuilt error and I drop frame rate by about 30% is there a way to tell if I am silenty switching to dynamic preview lighting? My setup is
persistent level -empty minus my main character
Room level- indoor baked lighting directional light set to stationary and a few static lights and a skylight.
Desert level-outdoor baked lighting directional light and a sky light
Im trying to do a day night transistion from the room level to the desert level
I mention the warning being displayed in one of the earlier posts. When you build lighting by opening these levels independently, the persistent level can’t know that lighting was already built for these sub-levels, so you’ll get the warning. If you know that it’s working the way you’d like you can always disable the warning by using the CVar “DISABLEALLSCREENMESSAGES” to not have the warning show when you play your game.
You can also use the command DumpUnbuiltLightInteractions to see if you see anything in the output log window that would indicate some issues.
One thing you need to keep in mind when trying to get around the lighting system this way is that you are 1) breaking PBR workflow and 2) this is not an intended workflow so you are likely to run into some or many issues doing this.
Don’t forget that the Post Process Volumes in your level can be a powerful tool as well since you can directly use these to control your baked Global Illumination by adjusting the color and intensity.
I had a very similar issue to what Railgunspecialist initially described.
And a few months back I saw this post, and tested your solution of separating the different bakes per level and then toggle the visibility of those levels until everything is baked.
That solution worked fine in 4.13 but with the update to 4.14 it seems that it no longer works!
If you download the lighttest.zip (that railgunspecialist posted), opened it with 4.14 and do what you described previously you will see what I am talking about.
Using the persistent to bake light per level seems to work. But once you make all levels visible, only the last level baked will be correct (all the other ones will be blacked out).
Does this new behavior have anything to do with the introduction of the BuildData file?
Do I need to go back to 4.13, to be able to properly bake light per level?
I have the exact same problem, I think that would be great if we could specify volumes that the lights affect or levels. I have to do a four plan house and 32gb of ram isn’t enought to build everything together.
how can epic have no plans to fix something that is such a major handicap? im making a vr game that relies on baked lighting and whenever a new level streams in it destroys the baked lighting in other areas. its crazy to think that unreal has no ability to lock baked lighting so they dont bleed over into other sub levels, yet that is reality. this is a major handicap to what we are trying to do
The solution to not getting the “lighting needs to be rebuild error” is that once you’ve built your lighting separately, uncheck “affects world” on each light.
Hello . just want to ask if you ever bumped into this problem ? I have multiple levels. main level for house and 4 levels for grass and foliage . I also have level which contains all the lights ( directional, sky, spot, rec ) . on my main level I have a movable objects ( doors ) I set this to movable because I want it to be interactable within click . I also set detail cell in world settings to 2 so that the appearance of the movable objects looks like a static object right after bake . the problem is after I baked all of the levels one by one and streaming them together, the movable objects ( even the third person mesh which is obviously movable) turned back to its bright appearance . please refer to the image below .
