Hey all,
I’m curious, if you add a static mesh to a blueprint does it instantly become a moveable and hence not static object or do they actually build static lighting if they’re not actually moving in the world?
If it’s placed there at runtime then no, it wouldn’t use static lighting, but if it’s part of the level and simply assembled by blueprints then it can bake lighting.
Thanks Darth,
Ok by placed there at runtime you mean if I spawn the blueprint dynamically through blueprint code? So if I were to create a blueprint of a set of buildings that uses construction script to randomly set the building meshes to be used and the rotation of those meshes, but then I hand place the blueprint in the world and build, it will use static lighting? How can you tell is a mesh is using static lighting or not?
When you add a mesh manually to a blueprint as a component, or even when you add it using a “add static mesh component” node, if you click on that node, the details panel will show you the mobility of the object as Static, Stationary or Movable. That being said, in order to have baked lighting, the mesh has to be in place when you go to build lighting. If the mesh is only spawned when you play the game (aka after Event begin play), it can’t use baked lighting. If your construction script is used to generate the meshes, You can bake lighting on them, but keep in mind that if any of your construction script code causes the static mesh component to move for any reason, you will break the lighting and have to rebuild it.
Cool thanks for the help guys!
Hi, I have 3 Blueprints of 3 seperate tables. Each table toggles visibility on and off when I press buttons during game play. When game first starts only one table is visible, I press a button that table disappears, and another table takes it place. All three tables are in the same place. My problem is after I bake lighting, there are shadows/artifacts from one table on the other tables. I want to be able to light all three tables as if static so I chose “Force Surface” for Lightmap type, is this correct? All the BP’s mobility is set to movable. Any help would be very much appreciated.
You can’t use static lighting for what you’re doing. If an object moves or is hidden, then it is no longer static. Static means it never changes. So you need to use dynamic lighting.
The point between Static, Stationary or Movable are based on the way they are loaded and instantiated into the level which explain why a blueprint is not automatically a Static, Stationary or Movable mesh.
In terms of practices, here the general ways these are managed:
• A Static Mesh is a mesh that has all its data already implemented in the Map’s Data.
You could call them Pre-Calculated assets. Even in this day and age where gaming PC can be quite powerful, none of any PC could manage an HD & HQ scene where all the assets would be calculated in real-time. At best, it would be a per-screen-pixel process that would take at least a minimum of 6MB per pixel if you consider all the kind of data it has to calculates and retro-calculate. (To give an idea, such system would requires about 2.8To of VRAM to render at 800x600.) To save on that per-pixel stuff, visual effect can be pre-calculated which is what we refer as “Baked”. A bit like in cooking, you always bake the cake before you put it on a platter to eat it.
With this concept, a Static Mesh is always a mesh that has a precise position and orientation in a set world. Depending on the complexity of the lighting system in place, it could also includes the lighting data. This like ambient occlusion and occlusion culling are also pre-calculated in an optimized way that takes far less resources than if calculated in real-time.
The best example is that of the level’s walls and ground, if it never changes.
If we were to put this into the perspective of Fortnite, as an example, anything that can’t be destroyed nor moved is a Static Mesh such as the Terrain and some giant rocks parts.
• A Stationary Mesh is a mesh that has a fixed position and rotation in 3D space, but from which specific things can change such as the model, materials, animation, etc. It’s an asset that pre-load everything about it, but also allows specific details to be overwritten in real-time without having to recreate the instance each time. An important note about Stationary Mesh is that their shadow will NOT be baked onto Static Meshes, but will use instead the real-time shadows like a Movable Mesh. The main “save” out of Stationary Mesh is that it save a lot when it comes to physics and “semi-permanent” features.
Again with Fortnite, destructible building part are Stationary Meshes because their lighting is real-time, but their position is fixed. Another example would be the flickering lights themselves. A fire camp’s light source would be a Stationary Mesh if you want said light to seem alive. A flag that moves in the wind through would also be a Stationary Mesh as long as it doesn’t move.
It’s possible to do a quick trick by swapping a Stationary Mesh with a Movable Mesh upon destruction which is far more optimized, memory wise, than just modifying a Movable Mesh.
• The Movable Mesh is a mesh that gets all its rendered data through real-time unless said data is baked directly into its material/textures (obviously). To put it simple, if there are any risk of having its position, rotation or even physic interacted with (other than basic collision), it’s a Movable Mesh.
Now that this has been specified, here an important thing about Blueprint’s Actor Mobility, it’s not a preset, but a set.
- If you set a Blueprint with any interactive physic other than immovable collision, the engine will automatically set it to Movable Mesh even if you set it up as a Static or Stationary Mesh.
- If you instantiate a Blueprint through another Blueprint’s script, it’s, by default, a Movable Mesh even if it’s set as a Static. If you instantiate a Stationary Mesh, you got to instantiate it exactly at the position and orientation you want it because it will switch to a Movable Mesh as soon as you correct its position and/or rotation.
- Static, Stationary and Movable mesh can ALL have physic interaction, but Static is limited to collision-based physics.
- You load a map with Static meshes and, through their blueprints, move or delete them around, but moving create some memory issues where the Static mesh is suddenly turned invisible/disabled by the engine and a Movable Mesh copy of it is instantiated in its place. It is a kind of a waste of memory that can’t be recovered due to how Static Mesh are pretty much semi-permanent in a level unless another level is loaded and the present level is unloaded. It’s far more better, in case of modifying an asset that doesn’t “move” to make it as a Stationary Mesh and, if something happens to it, replace it by the Movable Mesh (such as a destructed version of it) as Stationary Mesh and Movable Mesh truly gets deleted from the scene persistent memory unlike Static Meshes.
- You can make a Static Mesh disappear and it will stays as a Static Mesh in memory, but this will bring an issue with all baked data (such as the AO and shadows) because Static Mesh shadows and AO doesn’t exactly update in such as way that allows them to make shadows disappears. In a system with a Daylight system, each shadows phases of every Static Mesh are usually pre-computed in a special multi-layered way kinda like a color map that represent the shadows position based on a specific Float value (which is like the time of the day). For example, if the time is 18:00, the float value is 0.75 and it create baked shadows on the specific colors/layer of the baked shadow. (That’s how games like the Division 1 & 2 and GTA4 and GTAV works with their real-time lighting system on static map.) To put it in simple terms, with a simple color map, you can store up to 4 layers of 255 stages, meaning you can save up to 1020 shadow transition stages or, if you prefer, you can get the shadow map updated whenever the sun and moon move 0.35 degrees in the sky. If you apply a mixing of transitions, you get an unlimited amount of mid-between transition between shadows phases which looks really similar to real-time shadows, but pre-baked. In any cases, Static Mesh won’t allow you to make a shadow disappear if it’s baked as long as you don’t have any system in place to store the shadow-less version of the baked lightmap.
Maybe pretty much a noob reply to the “3 tables” scenario… But could you include a PostProcess Volume into the BP, and add a Bloom Effect to fake “baked lighting” and wing-it, since it is dynamic and dynamic lighting is more taxing? That’s how i would jury-rig that scene, IMHO.
Or, in another example, add a Constant Vector(B) and Multiply(AxB) to a Duplicate of the TextureSample(A) in Material Editor, the Constant should be et to desired amount to Multiply the Duplicate TextureSample with the Constant, and use that for Emissive plugin control (Constant on lesser than 1.0 i would assume, so it doesn’t literally “glow” you see.)
This is how I would do it. I would make 2 copies of your level. Bake each table and floor and after baking delete the rest.
Now as long as you dont need to rebake, you can stream each into your master level, floor and table. Streaming levels is handy. Im sure there are other ways but this popped into mind as I have done it before.
Hi, Rasamaya. If you use Level Streaming to do this, won’t it make the packaged application large. If I have an Archviz scene where I want to change out 3 sets of tables or 5 sets of beds, that means I need to have 5 different levels, would that increase the size of my demo.
Meanwhile I see that the static meshes I place on blueprints in the editor, eg when I make (hierarchical) instances of those are set to Movable by default.
@KeyC0de you have to set the actor components mobility to static in the blueprint. In later engine versions, setting the mobility of one component sets the mobility of all components. In older versions you would have to set mobility of all components. (v4.23 sets all components mobility)
New blueprints default to moveable.
Just switch mobility of your hism to static in any case.
@NotSoAccurateNo1 Yes, of course that is what I do. I’m reporting it because this shouldn’t be the default behavior. Yes, I’m using 4.23.
Anything put inside a BP is set to moveable by default because BP aren’t inherently static. They can be spawned or moved at runtime. It’s not a glitch, it’s the assumed natural setup because if they got set to static at first, 95% of all intentions of their use wouldn’t function. Think of a Door Blueprint with a static mesh used for the door that also moves. Static mesh also just means that it doesn’t have a skeleton, not that it will necessarily remain static in the scene. My guess is they assumed that it’s easier to force those who rarely intend to use them as actual static meshes to simply change the behavior type rather than force everyone who intends for them to be moveable to switch the behavior type.