Why would light bake information be lost when closing a level?

Development Rendering
, , , , ,
1

I am losing lighting info when I close and reopen my levels. I suspect the issue is with how my actors are constructed and how my lights are instantiated, but I do not fully understand what the issue is.

To encounter the issue all I have to do is the following steps.
Step 1: Bake the lighting
Step 2: Close the level (usually by switching to another one)
Step 3: Open the level again → Lighting needs to be rebuilt

However, lighting info isn’t lost on every mesh, it is only on select meshes where the info is lost. If I check which specific actors/components are the issues by typing the “DumpUnbuiltLightInteractions” I find that the following types of objects are the source of my problem:

  • Static Light Components instantiated in the constructor
  • Hierarchical Instanced Static Meshes that are on a child actor
  • Static Meshes on a Child Actor created by duplication (ctrl+w)
  • Static Meshes on Child Actors of Child Actors

It should be noted that the majority of these actors are parented from a class that has its mobility set to Movable by default, and would be changed in the constructor. Due to the technical debt on the project, changing the parent class is not a very realistic option. (Most instances of this class are dynamic by nature)

Does anyone know what these issues might be stemming from? Am I just running up against the limits of what is possible in the constructor? I want to see if anyone has a better understanding of this issue before I implement any drastic changes

Any help would be welcome, thank you!

1 Like
2

if you don’t save the level the bake data isn’t saved
so if you change a bunch of blueprints and build lights, and save the bp’s but not the map, then the light data is gone.

3

I am pretty careful with saving, unfortunately, I do not think that that is the issue at hand. The lighting is discarded on specific objects, not the entire level

4

Hey there @Viking_VR_Team! Things done in the constructor can be a bit funky for stuff that’s supposed to be decided at compile much of the time. Recently had “Phantom” UI remaining after being destroyed because it was destroyed in the constructor before full instantiation was complete.

The constructors limits aside, it’s still odd that they don’t remain cached on close. With the components you mentioned I’d expect the maps to be rebuilt after changes, but not on each load.