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?
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.
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.