Allowing hierarchical armatures of primitive components in a single actor (patch)

I want to be able to build an articulated armature, physically simulated, out of separate UPrimitiveComponents.
I don’t want to use a skinned mesh – rigid static meshes only.
I want this all contained into a single Actor for simplicity.

While this couldn’t be done with UE 4.15, the diff to make this possible didn’t seem particularly large.
In fact, one of the main problems was that the engine explicitly unlinked physically simulated components, unconditionally, even if that’s not necessary.

So, I developed a small diff that enables this behavior, and seems to work just as normal for any actor that doesn’t have two linked primitive components which both have physical simulation turned on.

I have three questions:

  1. Who wants to give it a spin?

  2. Who wants to give it a read-over to see if I’m missing something?

  3. How likely would this be to be accepted back into trunk? I’d prefer not to need a custom build of the engine forever.

Patch: https://github.com/jwatte/UnrealEngine/commit/f2f305db07ddb2dd5f666dd137ccf45fc98c82b6

What it looks like in editor:

What it looks like in engine, without patch:

What it looks like in engine, with patch:

Not sure what set you off on this path, but there is no problem with creating chained physical bodies in standard UE4. You just need to setup a PhysicsConstraintComponent at each joint. From your screenshot it looks like you’re trying to do it via the constraints properties on the primitive component - these are very limited and indeed are I think only meant for world space-relative constraints.

And yes, UE4 automatically detaches (in the component hierarchy sense) all simulating bodies, since it doesn’t really make sense to specify their transform with respect to another body when it’s updating freely according to physics simulation. This is distinct from the reference frames specified in the constraint components though, which, so long as you configure them correctly (and I have to say I dislike the way UE4 wants you to do this), will update as the bodies move and allow you to create chains in the way you’d expect.

Agree with Kamrann, the reason why components are detached when simulating physics is not a bug but a requirement to avoid issues where your system would just loose energy. Like how air drag force for example, would effect such bodies? What will happen to a system of bodies where one piece in the chain get much higher airdrag than others - it should “drag” other bodies with it, which means you need to have dynamic constraints where forces will be applied to bodies in the chain to keep them in the chain. Currently it can be done by using physics constraint actor/component or articulations (not exposed in UE4 but available in PhysX).

A-ha! Well, that makes sense now. The question then becomes: Why can simulated PrimitiveComponents have their own constraints at all then?
Those constraints seems largely useless – especially since the axes are expressed in world space, not component space, for the 6DOF constraint.
(I have a follow-up patch that changes this to be in component space, which makes the constraints a lot more useful.)
Anyway, if the articulated armature is easily expressed using the stock engine and PhysicsConstraintComponent then that’s probably easiest to use, even though it generates more components.

I don’t think that’s backed up by the code nor physical simulation. If you want a component to affect physics, you turn on physical simulation. If physical simulation is not on for the component, then it has zero impact on the simulation.

The reason components are detached when simulating is that the code blindly applies a transform to all children when the physics code updates the parent component. But if the children are also physically simulated, and have already been updated for the turn, then the blind-child-application overwrites the physics application, and it doesn’t render correctly. If you look at the patch, a better way of solving this is to not apply transforms to children that are physically simulated (just how you don’t apply transforms to children that have absolute/world-space coordinates selected.)

Yes, that is exactly what my patch does, for any component that is parented to another component that is also simulating physics. That’s what physics simulation joints do.
But, it sounds best to abandon that patch and just go with PhysicsConstraintObject, which achieves the same thing, with more control, but more components.

They have constraints for applications like 2D game or other gameplay cases. When such constraint is applied you are accepting loss of the energy - if you constraint object to not move in Y axis any acceleration in this axis will be lost, which is not physically correct, but you might not care as you don’t want object to move in that direction at all.

Not sure what you mean by joints but physics constraints generate forces and use those forces to pull objects into place, they don’t override transforms of objects as that would be physically incorrect.

At the end of the day you can manually sweep all components and calculate their position from sweep results, you don’t have to simulate physics to “have physics”.