I noticed that the code for FBodyInstance::SetInstanceSimulatePhysics detaches a physics body from its root when enabling physics. But disabling physics does not re-attach the body.
You can reproduce this quite simply.
Enable physics on Sphere, move it around. Disable physics on Sphere and change the world rotation of the root component Scene and the Sphere won’t follow. However if you re-attach Sphere to her root, things work as expected.
// #bug
// When you enable physics on a sub-component, that subcomponent gets detached from her root
// So when we disable physics on the sub-component we need to re-attach it.
PhysicsComp->SetSimulatePhysics(false);
PhysicsComp->AttachTo(GetRootComponent(), NAME_None, EAttachLocation::KeepWorldPosition);
Though I haven’t delved into physics in UE4 deeply I suspect this is as intended. If you activate a box sitting in the back of a moving truck and it falls off then you deactivate it what would you expect to happen?
If I deactivate physics on a sub-component, I would expect it to follow all the normal rules of sub-component life, like following its parent. You could make the same argument for setting the translation on a sub-component directly, should it be detached from the root?
I’m trying to follow the simple reproduction steps you provided but I’m not seeing the same behavior. After creating a scene component as the root component and a static mesh component as part of the hierarchy, I set the static mesh to simulate physics in code. In the editor I created a blueprint based on the class and played. I first moved the actor around then ejected and set simulate physics to false in the editor. The mesh still showed as beeing connected in the Details panel hierarchy and selecting the root component and changing it’s rotation at this point also rotated the static mesh. Is there anything else I’m missing to match your setup?
[Opinion] I’ll be honest - in most cases I’m not a huge fan of sub-components with extended lifetimes simulating physics independently of their parents, they should in general be created as independent actors.
In the case you state my thought is that once the component is activated as its own physical body reattaching it without consideration is likely to create some pretty odd scenarios (box 100m from truck now swiping through the world) and leaving the box attached to the truck when physics attaches it to something else is pretty pointless so the engine takes the lesser of two evils (i.e. cause fewer end game bugs, while maybe causing some head-scratching during development).
To explain my original statement my background is large open worlds with complex physics and this definitely shapes my way of thinking. In these worlds object roll into view with other objects attached. Sometimes those child objects (the box) get knocked off and their parent (the truck) drives off and gets removed from the world (saving performance, no longer relevant to the player). The box needs to remain interactive and coherent to the player until such time as the engine can clean it up gracefully without breaking the solid and coherent nature of the world you’ve been working so hard to create (so off screen or far away, not interacted with recently, not seen recently, rules can vary based on object type).
This s**t gets complicated (and is going to get more complicated - the scenarios above had many subtleties and different solutions in the end) - I’ve generally found that given a group of gameplay designers there will be a significant disparity in expectations of engine behavior based on the exact scenario each is trying to solve. The engine needs to hit some middleground, with buttons to hit to tailor for the most common variations and options to extend core behaviors in ways the original designers couldn’t begin too imagine. Fun!!!
Start the game with physics disabled on the collision sphere (Sphere). Press 3 to see it rotate, press 3 again to stop. Press 1 to give physics a nudge, press 2 to disable physics, press 3 to see that rotation no longer works.
Another side note is that if you repro and then pause and eject and select the object in the editor, the editor fixes up all the attachments behind the scenes and the rotation will start to work again.
I think this is expected. When you enable simulation, it detaches the cube from the ‘Scene’ root component, so changing the rotation of Scene will not affect the box any more.
While I do understand why this behavior is “By Design” (as noted in Unreal Engine Issues and Bug Tracker (UE-19584)), and your explanation made it click for me, I would highly recommend some code documentation to be added along the lines of “If bSimulate is true, also detaches the component from its parent.”.
This “bug” (I would still classify it as documentation bug, after all, it’s a function that does stuff you would never expect it to by reading the name or documentation) bit me during a game jam and I wasted roughly 10 hours trying to figure out what the hell was going on until my mental model was set straight.
Such a line could help other people similarly inexperienced with UE4 not to waste time figuring this out on their own or randomly stumbling upon this thread during google searches.
Another maybe neater option would be adding “bool bDetach” to the parameters of setSimulatePhysics (obvisously default true for bw compatibility), which would give an immediate hint that detaching is going to happen. I’d be very happy to see someone doing this probably easy change. Please do let me know if you do
This would be really awesome and I think many people would love this. If there was a way to set the phsics component that the actor follows instead of having to make it the root component, it would allow ALOT more flexibility. I’ve ran into this many times creating systems that inherit from each other.
