Light as if static greyed out or disabled

I’m using a set of actors in a blueprint, which contains both static meshes and spotlights. The blueprint is an elevator with no doors or walls, just a skeleton type of thing. (See attached Image).

My aim is to procedurally generate an elevator each time the player moves towards the edge of the floor, in any direction. Sort of like a maze.

So before I tried generating it procedurally, I took a noob approach and tried making multiple copies of the blueprint, in all three x, y and z coordinates. And the editor got painfully slow. But when I switched from the Lit to the Unlit viewmode, the editor works fast as normal. So I figured that the lighting is taking too much time to compute, because the lights and the static meshes are all Movable.

I set every mesh and spotlight to Static and tried to Bake the lighting onto the components, so that each time just the elevator as a Static Mesh is rendered and Lighting isn’t calculated for each instance of it.
However, the option of “Light as if Static” is disabled or greyed out and I can’t enable it.

Every parent component and all the components in the blueprints are static, and yet the option is disabled.
How can I enable it?

Hi Roahithraj,

That option is only available when a static mesh has it’s mobility set to Movable. It doesn’t apply to any others. It’s also only useful for movable meshes that only need to move a little bit but that you want it to have a baked shadow. For 99% of situations out there this option is never needed for common level design or light building.

For something like an Elevator that moves, you may get more artifacts or the mesh may turn completely dark if it moves too much. If you set them all to static and and then move the mesh that will still break lighting and you’ll have the warning in red in the top right of the level during play that says “Lighting needs to be rebuilt for (n Objects)”.


Thank you so much Tim. I figured it out. However, my main task is to have many number of static elevators (without walls) procedurally, in all three directions, sort of like a maze that is made just by the same elevator over and over again. So it looks something like this:

The problem is, every light is computed each time and the editor becomes very slow when I switch to the Lit mode. I want the lights to be static and not compute each time. Effectively, I want a layer of elevators procedurally generated in any direction that the player moves, be it X, Y or Z, infinitely.

I can find a way to procedurally generate the elevators from other tutorials, but how do I deal with the lighting and it’s computing time?

Is there any way to bake the lighting of the blueprint on to the static meshes, and then discard the lights so that the materials on the static meshes appear with the lighting but without any lights interacting with it?

None of the lights need to cast a shadow in the scene. Just light the static meshes in the blueprint once.

Thank you so much for answering.

Is there any way to bake the lighting
of the blueprint on to the static

Lighting cannot be baked into a BP like this. Each instance of it in a level will need to have it’s light baked to be accurate. You could always fake this by making a lighting texture in your modeling program if you’re using it’s baking or you can paint lighting in with something like Photoshop for the texture. All this can be plugged into the emissive input with a multiply using a 0 to n value to determine how bright that texture should be.

As for other things you can potentially research and test to control how the procedural meshes are lit.

  1. If you’re using Runtime generation for the level so that it’s different each time you play, you can try using a static mesh at the lowest part of the level and then surrounding the level with a Lightmass Importance Volume. Inside the Lightmass Importance Volume place a Lightmass Character Indirect Detail Volume and scale this more closely to fit your level play area where the geometry will be. This volume places more indirect lighting samples throughout the volume to (show > Visualize > Volume Lighting Samples) better light dynamic actors that are not close to surface.

For the surface that is below the level. Have it visible in the editor, but make sure to set it to be “Actor Hidden in Game” that way it will generate the lighting samples, but not be visible when you play the game. For artistic tweaks and lighting tweaks use the World Settings > Lightmass settings and change the Environment Color and Environment Intensity to better suit your needs.

  1. If you’re generating the procedural part in the Construction Script before the level loads and it will not change for the different levels, you can build lighting. I don’t think you’re doing this base don your description, but the CS can be used to procedurally setup a seed and then…

…build the lighting since it won’t change. This has to be specifically setup and the level shouldn’t be auto-generated at runtime.

  1. 4.13 has a new option for all light types to set a max distance that it should be rendered. You can set the max distance and the distance that the light should fade in/out of from. This could be helpful for curbing some of the performance issues you’re having with the lighting. Although I would expect you not to have as much trouble with them not shadow casting, but this can largely depend on the machine that is being used to develop with and also the Actors rendered on screen too.

  1. Lastly, you have the post process volume at your disposal to help things as well. You can assign a Cubemap to your unbound post process volume to help offset some of the lighting in the scene too. This cubemap doesn’t have to be a specific image of a background like most are for reflections, but instead, you can also use solid colors to help control the reflection lighting. It’s a possibility, but the other approaches should help as well.

Anway, I hope this helps and give you some alternative solutions to approach lighting from.

Okay, first of all, wow. Thank you so much for outlining all those approaches. I understood some parts, and some I didn’t, but that’s because I’m yet to explore those aspects of the Engine. But, thanks a lot for these methods. I will definitely try them out, though it will take me a while to understand and implement each, but I sure will try them out soon.
Thanks again, Tim.

Give the ones you can a shot and if you have follow-up questions I’ll gladly help guide you to the information you need to research and learn some more. :slight_smile: