So I asked AI about it: The issue is caused by a PCGVolume with a brush component. The collision preset of this component has “ignore” set for all channels for “collision response”. Collision enabled is set to “Query only”. Why is it causing physical collisions with the physic bodies from the control rig’s solver? When I set “collision enabled” to some mode that does not include queries (“physics only”, “probe only” or “no collision”) the issue disappears.
…and let it look through the codebase. The answer it gave seems reasonable given the results I see, here is a shortened/edited version:
-------------------------------------------------------------------------------
Yes — this behavior makes sense from the current implementation. The PCGVolume brush component is being included because Control Rig Physics world collision first does a query overlap. That query is based on object type / broad overlap presence, not your per-channel “Ignore” responses in the way you’d expect here. Once found, the component is converted into an Immediate Physics kinematic collider and that collider is configured to block everything inside the Control Rig physics solver.
Why Query Only matters
In the world-object collection step, Control Rig Physics calls:
World->OverlapMultiByObjectType(…)
with object query params like:
AllStaticObjects and:
QueryParams.MobilityType = EQueryMobilityType::Any;
This is a scene query. So a component that is static, queryable and has collision enabled for queries can show up in the overlap results even if its collision responses are all set to Ignore.
Why “Ignore all channels” still doesn’t save it
Because after the overlap finds the component, Control Rig Physics creates an Immediate Physics actor from it and adds it to the solver’s colliding pairs. The important thing is that the imported actor’s shape filter is set to effectively block all for the immediate solver. In practice, that means the original component’s fine-grained Unreal collision-response setup is not being preserved for this Control Rig Physics world-collision path. So your brush component’s settings are used only enough to let it be discovered by the query, but once imported into the solver, it becomes a real collision object there.
A PCGVolume brush component often has large bounds, query-enabled geometry, unusual collision/body setup compared to a normal mesh and geometry that exists mainly for editor/procedural workflows, not for runtime rigid-body interaction.
So it’s exactly the kind of thing that can be harmless for normal gameplay collision, but still get picked up by a broad “find static queryable things near me” pass and then become a nasty solver collider.
-------------------------------------------------------------------------------
If this is right, it’s a bit unexpected behaviour. I would like the solver to not create physical collisions for query-only objects (at least as an option to toggle on the Spawn Solver node), do you think that might get implemented in the future?
Also, a bit unexpected is that it is going to ignore objects that have physical collision turned on, but not queries, having an option to include those could be useful, although I don’t have any particular application right now (I guess it’s a bit unusual to have something that is allowed to collide but being queried).
