Feedback Compound colliders are nonviable for many production use cases.

Issue: all colliders are merged into a single compound collider. The layers are also merged. This creates issues for many use cases.

Use case 1: Rotating child colliders as separate entities is not possible with compound colliders.
Example 1: Tank turret
Example 2: Animated characters example, a character control capsule collider. Depending on the animation crawling/standing the hitboxes may become obscured by the capsule collider.

Use case 2: Separating hitboxes from rigidbody physics interaction.
Example 1: Wheels or tank track hurt boxes. These boxes often collide with terrain when part of a compound collider. This behavior is undesirable. These boxes are only used to determine if tires or tank tracks are damaged. Having these colliders as part of a compound collider cause lots of undesired collision interactions that become part of the rigidbody solver.
Example 2: Animated character's hitboxes such as a large head damage box.

Use case 3: Colliders within colliders.
Example 1: Energy shield that protects the unit
Example 2: Animated characters which have a capsule collider as a rigidbody. Inside this, capsule you attach arm or leg hitboxes to bones. Since the layers are all merged raycasts will never hit the internal arm or leg hitboxes.
Example 3: A hitbox that is partly blocked at certain angles.

Use case 4: Increased raycast complexity and unexpected results.
Example 1: Raycasting only against a specific layer. This is possible but only if you expect the compound collider to be a convex hull and you are just trying to get a segment of that hull's surface. Even then requiring a ColliderKey results in increased complexity. This still does not solve the issue of other children blocking the raycast.

 

this also effecting me, may case is, a building part with multiple Socket, these socket collider can be detected by raycast to provide snapping functionality (these sockets only use for physics query)

 

In my use cases, the worst part is that the collider contains the categories / layer information.

So the collider needs to be cloned any time you want to change its collision filter individually (or be set to unique).

If I ever saw something that should be an IComponentData, it's CollisionFilter.

It completely falls apart from there once compound colliders are involved. At least some sort of control over which colliders are globbed together and which become their own entities would be a huge improvement to the authoring workflow.

 

Compound colliders definitely need to improve or some other form of compound needs to be introduced.
Games like besiege, trailmakers where you want to have dynamically added/removed parts are really complicated work to achieve in ECS. The compound collider gets out of control when you have a few hundred objects in it