Multiple collider components within a blueprint class (aka. compound collision)

Development Programming & Scripting Blueprint
1

I’m seeing some weird collision issues in UE4.2.1 when using more than one collider component in a blueprint. A quick summary of what I’m seeing/repro steps:

  • I derive a blueprint class “Test” from Actor.
  • I add a Box shape component as the root of “Test”, with collision set to BlockAll + simulating physics + gravity enabled. At this stage, I can place the object in the world and watch it fall and collide with the ground plane as expected.
  • I add a second Sphere shape component parented to the root of “Test”, with collision enabled (but not simulating physics) and set to BlockAll. I’ve moved this sphere so it’s not colliding with the root Box shape component. At this point, I can place the object in the world and watch the box collision collide with the ground plane as expected, but the sphere collision is completely ignored by the physics/collision system.

The final setup looks like:

MultipleColliders1.png
MultipleColliders1.png744×803 137 KB

  • Now I move the sphere shape so it overlaps with the box shape slightly. When I place the object in the world and simulate, I see the whole object move upwards instead of falling with gravity, presumably because the sphere is internally colliding with the box each frame.

This setup looks like:

MultipleColliders2.png
MultipleColliders2.png744×803 136 KB

So I have three questions:

a) Why is the sphere collision not working in the first situation? If what I’m doing is fundamentally wrong, is there some documentation or C++ comments about this somewhere? I couldn’t find anything in my hunt. If we can only have colliders on the root components, this is a pretty crazy limitation of Unreal Engine’s collision system. Unity let us create all manner of compound colliders using primitives, and kept the total mass associated with the rigid body and not the individual colliders, which made more sense to me.

b) In the second situation, why is the object moving upwards? As mentioned I assumed it’s because of inter-collision between the two components, but why are they colliding if the sphere doesn’t collide with the world?

c) Will 4.3 fix all these problems? :slight_smile: I saw there’s some compound collision features coming, however they looked to be limited to the static mesh editor. What about us plebs who want to use a skeletal mesh for the visual side of things and use compound collision primitives for the physics?

Thanks!

2

If an engine can do ragdoll, it can certainly do compound object collision(basically a joint that can’t move).
You just didn’t search for document, that’s all.

3

So the only way to achieve this is with joints and multiple rigid bodies? That’s a bit of a performance concern. Ideally I was hoping for a solution that would weld multiple primitive components together as a single rigid body at the PhysX level. Is this not possible?

Edit: Explaining a little further, in Unity there is a clear distinction between collision and rigid bodies. You can combine multiple collision primitives to act as one rigid body with compound collision. This doesn’t require physics joints, the engine automatically welds all colliders found underneath the rigid body in the hierarchy into a single compound collider. What concerns me with UE4 is this lack of a distinction (each PrimitiveComponent has its own rigidbody), which makes it difficult to build compound collision from primitives efficiently. Of course we can use static meshes with their own collision meshes, but as a gameplay programmer I find it very useful to be able to build collision from primitives in the editor, and for efficiency having this option is also nice, as mesh collision is slow.

Perhaps the 4.3 changes will fix this - see CUSTOMIZABLE STATIC MESH COLLISION: Unreal Engine 4.3 Update Preview

But getting back to the original question - I don’t understand why I’m seeing no sphere collision with the world in the first instance, but I am seeing box-sphere collision in the second instance. It seems like a bug…

There is some potentially relevant engine code that’s currently disabled. If you search for “WITH_BODY_WELDING” you’ll see FBodyInstance has a function Weld: “Takes two body instances and welds them together to create a single simulated rigid body”

If anybody can shed some light on the situation I’d be very appreciative.

4

i dont think that customizable static mesh work for you problem.

Are you test a rooT empty and the cube and sphere like chills and the same level?

5

RE: customizable static mesh, yeah what I’m describing is more about assembling compound collision in the blueprint components view. But as PenguinTD pointed out, it may be that the only way to do this in UE4 is with joints, which is disappointing.

But as for the weird symptoms I described above, I’m not 100% understanding your last sentence, but to clarify, what I’m seeing above happens in a clean level (an empty scene with a ground plane and two chairs), with 1 blueprint called “Test” derived from Actor, and I’m not doing any extra steps not mentioned above when testing.

6

are you test this:

-Root(arrow)
–Box1 simulating physics on
–Sphere1 simulating physics on

btw you have similar behaviours in unty if put a rigid body on both components.

Sorry for my english.

7

Ah yes I understand now, thanks for explaining erWilly.

I tried a few combinations. Here’s the results:

Root (arrow)
– Box1 (simulating physics on)
– Sphere 1 (simulating physics on)

Both the box and sphere move independently of each other, and both collide with the world. This is as I would expect.

Root (arrow)
– Box1 (simulating physics on)
…-- Sphere 1 (simulating physics on) <– Sphere 1 parented to Box 1

Only the box collides with the world (the sphere has no collision), but the sphere maintains its relative position to the box. This is a weird setup (a rigid body parented to a rigid body), so that’s fair enough. I guess I would have expected both the box and sphere to behave like the first example, but hey, whatever.

Root (arrow)
– Box1 (simulating physics on)
…-- Sphere 1 (simulating physics off) <– Sphere 1 parented to Box 1, not simulating physics

This behaves the same as the last example. This surprised me - I would expect Sphere 1 to have collision with the world, and maintain its position relative to Box 1.

Also, I still don’t understand why the two objects collide with each other when they overlap, but the sphere doesn’t collide with the world.

It seems this kind of compound collision (with a single rigid body) just isn’t supported, and the only workaround is to use joints to attach the rigid bodies to each other, like PenguinTD suggested.

Thanks for your help, and no problems RE: english! :slight_smile:

8

Rare yes, Thanks to you for share you tests.

You can do it a “Feedback for Epic” for WELDING rigid bodys in blueprints I see useful.

9

What did you set the Object Types to in the components screen? Also why don’t you have “Simulation generate Hit Events” enabled? You only create overlap event’s and that’s not what you’re trying to achieve if you want to simulate physics events.

10

basically doesn’t matter what the engine(Unity or UE4) did, they all use those basic constraint types beneath the surface.
It’s just that if the compound collision is a high demand feature, I think Epic would put it in and make it more intuitive.
Other than that, I think current way of exposing constraints are better than nothing or just solid constraint.

11

KillerSneak: The object type for both the sphere and box is set to “BlockAll”, as is the ground plane. I don’t have “Simulation generates hit events” enabled as this just controls whether the blueprint ReceiveHit/OnComponentHit events are fired. The physics collisions should happen regardless of this setting. More info here: Collision in Unreal Engine | Unreal Engine 5.2 Documentation

PenguinTD: Hmm, I don’t believe this is correct. There is a fundamental difference between a physics joint connecting two rigid bodies (even fixed joints) and a single rigid body with multiple collision primitives welded to it.

Fixed joints are best used in situations where the joint may be broken at some stage (eg. a car wheel breaking off from the chassis). Joints incur additional overhead from the physics engine, and may suffer from drift in certain situations. This comment on the PhysX documentation page for creating joints sums it up best:

“Note: All joints are enforced by the dynamics solver, so although under ideal conditions the objects will maintain their spatial relationship, there may be some drift. A common alternative, which is cheaper to simulate and does not suffer from drift, is to construct a single actor with multiple shapes. However fixed joints are useful, for example, when a joint must be breakable or report its constraint force.”

A single rigid body with multiple collision shapes is best used when you never want to change the collision, as it’s cheaper and doesn’t require the physics solver to continually keep the joints aligned, or calculate the forces acting on the joint.

From a UI perspective, I think Epic could add the ability to create rigid bodies with multiple welded shapes by allowing a blueprint component hierarchy as follows:

[Root] Box1 (collision + physics enabled, simulating physics on)
±- Box2 (collision + physics enabled, simulating physics off)
±- Sphere1 (collision + physics enabled, simulating physics off)

When compiling the blueprint, it would detect that Box2 and Sphere1 are parented to Box1 with collision enabled but simulating physics disabled, so it would weld them to Box1 at the PhysX level.

12

Well, that’s how the document says, and it doesn’t tell you how they do it with multiple shapes right?
Wielding is, essentailly, constraint that just won’t break/rotate/exert, this type is better when you want to change things on the fly, doesn’t matter if you want to break it or not.
They are still multiple rigid bodies though.

Another type, that you quoted, is basically creating a new convex hull collision object used for the entire hierarchy.
There are several approaches to this convex hull object creation to speed up collision detection and force calculation.
In your case(happens to be not a good example), sphere would use more convex hull objects to approximate, and cube would probably be 2 objects.
One of the algorithms to do this is HACD (“Hierarchical approximate convex decomposition” by Khaled Mamou), and the problem is they might cause penetration because it’s just approximation.
So it will not essentially faster if your base shape is already simple, sphere and box happens to be the fastest types for collision detection.

It’s not always cheaper to convert multiple object into a single one, it depends on what kind of base shape your providing geo is.

13

I am with sds- about performance if you compiles in the editor…
…but incluse if there is not diferences in the performance, they are two facts :
1º The pipeline working flow is more fast and easy.
2º (Only if you are a famboy of unreal like me) Unity does.

14

No, No, No, No.
I came here due to google search, and saw this reply; even though it’s from 4 years ago, it still appears that unreal just can’t do it out of the box at the component/blueprint(actor) level.

Both Unity and Unreal use the same physics engine; PhysX. I believe even now they’re even using the SAME version.
In Unity, you can combine multiple colliders into one object for a rigidbody, via Components. (PhysX has supported this for almost 10 years…)
ie:
in Unity:
YourGameObject
±–RigidbodyComponent
+BoxColliderComponent
+SphereColliderComponent
±----ChildMesh
±------ChildBoxCollider

this does not do “welding” It creates a COMPOUND collision, with ONE SINGLE RIGIDBODY.
Unreal DOES use PhysX’s ability for this, but ONLY directly inside StaticMesh assets.
ie: when you setup collision in the static mesh asset, you can add spheres, boxes, capsules, etc, and they will all be a single compound shape.
It doesn’t add joints, or constraints (except in the case of a SkeletalMesh asset.)

Unreal needs this ability on the COMPONENT level.

3 Likes