StartAwake is not respected in a welded hierarchy

Development Asset Creation
, ,
1

Hi Epic,

We’ve observed that the StartAwake flag appears to be broken for welded hierarchies constructed from simple PrimitiveComponents in Blueprints. Even when the root primitive has StartAwake = false, the instance is immediately awakened on PIE.

We suspect this behavior is due to how welded hierarchies are constructed.

During the initialization of a PrimitiveComponent, the method FBodyInstance::UpdatePhysicsFilterData is called, which explicitly wakes the object via FPhysicsInterface::WakeUp_AssumesLocked(Actor).

Later, there is an additional call from FBodyInstance::InitDynamicProperties_AssumesLocked that attempts to sleep the object based on the StartAwake flag.

However, it seems that for welded hierarchies, additional calls to UpdatePhysicsFilterData are triggered for each welded shape. These calls awaken the object again—this time without any check to respect the StartAwake flag.

This is a significant issue for us, as it can cause objects to randomly fall through the floor in a streamed world.

Can you confirm whether this is expected behavior? Or are we potentially misunderstanding something or misconfiguring our setup?

Thanks,

Magnus

2

Steps to Reproduce

  1. Open scene
  2. Open CubeDrop level
  3. Observe the 4 different blueprint instances in the level. All except 1 have StartAwake = false and SimulatePhysics = true on the root.
  4. Enter PIE
  5. Observe that SingleCube sleeps
  6. Observe that WeldedCubes start simulating
  7. Observe that UnweldedCubes sleeps
3

Hello [mention removed]​

Thank you for reaching out and reporting this issue.

I’ve previously handled another case stating the same issue [Content removed]

The proposed fix was being tracked in this link and it’s marked as fixed on 5.6:

I’ll test again with the latest engine version and confirm.

All the best,

[mention removed]​

4

Thx Rafael !

5

Perfect. Thanks for checking.

6

Thre resolved issue has a commit number Unreal Engine Issues and Bug Tracker (UE\-237599)

But, that refers to your non-public perforce repo, right ? Is there a changelist in the public git repo we can refer to, if we want to cherry pick the fix ?

7

The git link is just what we needed :slight_smile:

Thanks a lot for the swift replies, and have a great day.

8

Hello [mention removed]​

Thank you for the repro project.

I’ve run it through Perforce’s UE5.7 CL42031367.

I was able to confirm that the issue was fixed and the behavior was as expected:

[Image Removed]All cubes remained sleeping during the simulation (except for the top/child cube on CubeUnwelded, which was marked as Kinematic, as expected):

[Image Removed]Let me know if you need anything else.

All the best,

[mention removed]​

9

Hello [mention removed]​

Indeed, CL40652267 is marked as private, sorry about that.

Can you check CL40652296 instead?

For the git commit, check https://github.com/EpicGames/UnrealEngine/commit/a0240acdd5d80c86d397d252f83989995444e6bd

Let me know.

All the best,

[mention removed]​

10

Hello [mention removed]​

I’m glad I was able to help.

I’ll close the case now.

All the best,

[mention removed]​