Problems with inherited DefaultSceneRoot in blueprint, and physics on child BP

I’m trying to set up a hierarchy of blueprints, where I have a parent blueprint behaviour (event graph, properties), and then child blueprints that inherit that behaviour into specific types of objects.

These parent blueprints are only there to allow their behaviour graphs and properties to be inherited, they have no mesh component and are not designed to be created on their own.

However, every Blueprint needs to have a DefaultSceneRoot component.


Now, my problem is that if I create a specific child blueprint and want to give it a static mesh component, I need to create that as a child of the DefaultSceneRoot - I cannot replace the inherited scene root component.

Adding physics simulation to the static mesh component makes it separate from the root of the BP. That means that moving the object no longer affects the physics-simulated component (it gets left behind), and that I can’t iterate through the BP’s components any more (which I need to be able to do for a visual effect.)


What I really want to do is replace that useless DefaultSceneRoot that I’ve inherited from the script-only ancestor blueprints, so that the root of my new blueprint is the physics-enabled static mesh, but there doesn’t seem to be any way to do that.

The only solution I can think of is to set up an empty static mesh on the parent BP, and then to use a combination of editable properties and a construction script to allow the actual mesh to use and whether or not physics simulation is enabled to be set on the children through properties. That’d be possible, but seems like an awkward and somewhat hacky workaround.

Maybe the whole thing can be overcome by using a C++ class instead of a blueprint as an ancestor, though I’d rather not do that if I don’t have to, especially when I already have the system working through Blueprints.


Does anyone have any suggestions on what the proper way to do this kind of thing is?

If you want to get rid of that thing as far as visuals. +Add Component “Scene”.
Take the new “scene” drag and drop it on top of the old one. You will still have the scene there, but the image will go away.

I hope that helps.

But the root is inherited, it cannot be replaced?
Plus, another scene wouldn’t solve the problem, the root still wouldn’t be the physics object.

71942-cannotbereplaced.png

How?

It explicitly says “This is the default scene root component. It cannot be copied, renamed or deleted.”

Why do you want to delete it anyway?

I mean a Scene component is just acting as container . It should be of no harm for you.

As I said in the original post, I want the static mesh (from the child BP) to be the root of the object. Maybe I’m doing something altogether wrong, but when I add a static mesh underneath it and then give that static mesh physics, the static mesh gets disconnected from its parent.

After that, I am no longer able to move it (because it gets left behind when moving the entire object) and also can no longer loop through all of the blueprint’s components because the static mesh is no longer attached to the root.

When you add physics. Then static mesh will move automatically . I dont think I am getting your problem exactly.

I mean that I’m no longer able to move (e.g. teleport) the object from another blueprint script in-game, because the physical static mesh has been disconnected from the root of the object, so moving the entire object won’t move the static mesh. It gets “left behind.”

Check out this other question where your problem is answered very well.

Yes, I had read that before. It explains why subcomponents are detached when the game starts (and it makes perfect sense), but it still doesn’t solve the problem of child blueprints inheriting a useless DefaultSceneRoot that can’t be removed or overridden.

What I am trying to do is define behaviour for a type of object (in this case, an item which can be picked up), without specifying any visible component of that object yet (as that should be defined by child blueprint classes.)

I want the child classes to be able to inherit the behaviour (I can be picked up), but define their own shape, physics, etc.

However, doing this means that I can no longer teleport the object around (e.g. when dropping or placing it) because the mesh is no longer attached to the root.
I can also no longer loop through all of the components of the object to highlight it when the player looks at it, because, again, the mesh is detached from the root.

Adding physics is detaching mesh from parent. This is how Engine works maybe. It have nothing to do with default scene root as far as I know.
If you just want to make changes into static mesh of different pickups, you can declare a public variable of static mesh type inside your parent blueprint and then you can add a desired static mesh while using it in level.

I have a sort-of solution. It’s still a huge hack, but at least it’s a self-contained hack that only needs to be set on the parent blueprint, and allows me to set up the children as normal through the blueprints component screen.

Basically, the parent blueprint has an empty static mesh component, and a construction script that looks for the first child static mesh component, copies all of its properties up to the root mesh, and then deletes the child mesh.
One caveat is that not all of the properties on the static mesh are available for getting and setting.

The ideal solution would be if the engine supported “code-only” blueprints with no root component (similar to a “blueprint script component”) that could be inherited from by a normal blueprint.


Additional: There is a feature request from around a year ago - UE-2584 - to allow altering of inherited components, [as mentioned UE4 staff here][2]. I assume this feature was never implemented.

1 Like

I mean a Scene component is just
acting as container . It should be of
no harm for you.

Yes it can be. When a collisioncomponent in a child-blueprint is not the root (so it must replace the default scene_root) then all forms of collision won’t work.

Facing the same issue, this makes the inheritance problematic. Unreal components is a mess.

1 Like