Issue 1: Convex Collision Transformation Missing for External Collision Sources
Description: When adding external collision sources to a Chaos Cloth simulation (e.g., via Add Collision Source from a different Skeletal Mesh Component), Convex colliders fail to transform correctly with the bones. While Sphere and Box primitives work as expected, Convex shapes appear to remain at the component origin or ignore bone rotation in the solver.
Root Cause Analysis: After debugging the source code, we found a discrepancy in how Convex data is handled compared to other primitives:
Data Structure Deficiency: In ClothCollisionPrim.h, FClothCollisionPrim_Convex lacks LocalPosition and LocalRotation members, which are present in FClothCollisionPrim_Box.
Improper Sync Logic: In ClothCollisionData.cpp, the FClothCollisionData::AppendTransformed function only transforms SurfacePoints. However, SurfacePoints are primarily used for visualization or GJK-based paths.
Solver Dependency: The core collision detection in PBDSoftBodyCollisionConstraint.cpp calls PhiWithNormal, which eventually relies on FConvex::PhiWithNormalInternal. This function calculates penetration based on the Planes array. These planes are baked in bone-local space and are never updated during the simulation.
Identity BaseTransform: In ChaosClothingSimulationCollider.cpp, inside FClothingSimulationCollider::FLODData::Add, the BaseTransforms for Convex elements are hardcoded to Identity. This forces the solver to evaluate the static Planes in the wrong coordinate space.
Proposed Fix: We have successfully fixed this locally by:
Adding LocalPosition and LocalRotation to FClothCollisionPrim_Convex.
Updating these members in FClothCollisionData::AppendTransformed using the BoneTransforms.
In FClothingSimulationCollider::FLODData::Add, populating BaseTransforms[Index] with the updated LocalPosition and LocalRotation instead of Identity.
Stopping the per-vertex transformation of SurfacePoints in AppendTransformed to avoid “double transformation” when BaseTransform is applied.
Issue 2: Convex CCD Stability Issues due to Plane Intersection Semantics
Description: Enabling CCD (Continuous Collision Detection) for Cloth results in worse collision stability against Convex shapes. Particles tunnel through the convex volume more easily when CCD is active compared to discrete collision.
Root Cause Analysis: The issue lies in the intersection logic used for CCD:
Call Stack:FConvex::FindClosestIntersectionImp calls TPlaneConcrete::FindClosestIntersection (defined in Plane.h).
Incorrect Semantics: The Plane implementation of FindClosestIntersection treats the plane as a double-sided board with a specific thickness. It calculates intersections based on a ray hitting a 2D surface.
Convex Conflict: This “double-sided” logic contradicts the semantic definition of a Convex Volume, which is defined by the intersection of half-spaces. If a fast-moving particle enters the volume, the CCD logic might incorrectly resolve the intersection as if it hit the “back side” of a thin board, leading to tunneling or “popping” through the shape rather than being pushed out.
Request: Does Epic have plans to refactor the FindClosestIntersection logic for Convex shapes to better respect volume semantics rather than individual plane intersections? Additionally, please confirm if the missing transformation logic for Convex primitives mentioned in Issue 1 is a known regression in 5.6.
We do not have current plans to fix or even were aware of the issues you’ve mentioned as far as I know.
With regards to using CCD, we often recommend to increase the number of substeps to the simulation instead. This has the double benefit to both improve collision and simulation at the same time while using the most optimized collision detection path.
Same with convex, we tend to prioritize other collision shapes such as the kinematic colliders (which have recently been added to the Physics Asset) for better accuracy.
I will fill a bug report to track the multiple issues you’ve mentioned so that they can be fixed in future versions.
Many thanks for your help in reporting and diagnosing these.
Regarding the suggestion to use Kinematic Colliders (Skinned Triangle Mesh / Level Set) in UE 5.6, I have a specific question about External Collision Sources:
1. Feasibility via Runtime API Does AddCollisionSource support injecting Kinematic Skinned Triangle Mesh or Level Set data from an external Physics Asset (e.g., a vehicle Actor)? I noticed that FClothCollisionData in the source code only seems to support analytical primitives (Spheres, Boxes, Capsules, Convex), with no container for passing dynamic mesh data to the solver.
2. Recommended Workflow If AddCollisionSource does not support these new kinematic types, what is the best practice for high-speed external rigid bodies? Since Convex primitives currently have broken transformations (the issue I reported) and CCD semantic issues, should we fallback to Capsules for all external interactions, or is there a different API intended for this?
We need to decide whether to maintain our local engine fix for FClothCollisionPrim_Convex or refactor our assets.
There seems to be a misunderstanding regarding the API I am using.
To be clear: I am not using USkeletalMeshComponent::AddClothCollisionSource().
I am using the UChaosClothComponent::AddCollisionSource function from the Chaos Cloth Asset plugin. (See:Engine\Plugins\ChaosClothAsset\Source\ChaosClothAssetEngine\Public\ChaosClothAsset\ClothComponent.h*)*
Crucially, this function’s signature explicitly exposes a boolean(bUseSphylsOnly ) to control the shape types: void AddCollisionSource(USkinnedMeshComponent* SourceComponent, const UPhysicsAsset* SourcePhysicsAsset, bool bUseSphylsOnly = false);
I see now. I was task switching from working with the recent Skeletal Mesh Cloth Asset integration and totally missed the point that this was Cloth Component code which works differently.
Yes, you are correct, FClothCollisionData isn’t ready to deal with extended collision data as seen in this comment when extracting the physics asset collision:
// Extract collisions
// Currently not handling extended collision data
Looking further up the callstack, I can tell that changing FClothCollisionData to accept skinned triangle meshes would probably be a large and difficult change for you to maintain. To be clear, my earlier suggestion wasn’t specifically related to external collision sources, more about collision in general. But I now realise it wasn’t really helpful in this context.
Fixing the convex code would probably be an easier fix.
To answer your question:
> We need to decide whether to maintain our local engine fix forFClothCollisionPrim_Convexor refactor our assets.
This depends on whether you are prioritizing performance or collision accuracy.
If you are in a real-time/game environment then I’d still probably recommend to only spheres and capsules. Maybe set UseSphylsOnly to false and also use boxes if necessary. Using CCD would also be very costly. Usually higher number of substeps, backstop and animdrive are the tools used to keep the cloth simulation budget to a manageable amount of CPU while getting some reasonable collision response.
If not, or if collision matters more than simulation time, then I’d suggest you try fixing the convex type code path by yourself. This shouldn’t be too difficult and will hold until we work out an official fix for this issue.
This said, I do not have much context around the reason why you are trying to use external collision sources instead of the Cloth Asset physics asset. There might be other easier ways to achieve the same result, such as setting the physics asset in the Dataflow graph in Editor or calling SetPhysicsAsset on the ClothAsset itself in runtime if these colliders are character specific.
The current issue stems from a non-standard interaction scenario where traditional Physics Asset (PhAT) workflows are logically inapplicable. Please consider the following constraints:
Environment-Vehicle Interaction: This is a cross-actor interaction between static environmental cloth (e.g., architectural banners/flags) and dynamic colliders (Vehicles/Pawns).
Runtime Dynamism: The colliders are Vehicles that are spawned and moved at runtime. They are not components of the cloth’s skeletal hierarchy, nor can their geometry be pre-determined.
I suppose you’ve decided to discard the SetCollideWithEnvironment then? Because it also deals with convex shapes and might not have the convex issue you’ve reported.
While attaching additional static colliders to the skeleton is a functional workaround, it introduces a dual-maintenance workflow for our art pipeline. Since the vehicle already possesses a calibrated Physics Asset (PhAT) for gameplay, duplicating these shapes solely for cloth simulation violates the “Single Source of Truth” principle and increases the risk of synchronization errors during production.
Therefore, relying on the existing Physics Asset via
AddCollisionSource
remains our preferred architectural choice to ensure data consistency. We will focus on resolving the stability issues within that approach.