When UWorld::ComponentOverlapMulti is called (for example through the ComponentOverlapComponents blueprint node) passing a component which is welded to a parent, it will use the parent shape to run the overlap query rather than the shape of the component itself. See for example the attached repro project, where a sphere child is attached to a cube parent, and the child component is queried for overlaps at its position. The Chaos Visual Debugger show the overlap query running with the parent shape but at the child’s position:
[Image Removed]
and the BP node detects an overlap even if the sphere isn’t touching the other cube.
This seems to be due to `PrimComp->GetBodyInstance()` getting the BodyInstance of the parent and not the child; then `FBodyInstance::OverlapMulti` should iterate on all the shapes in the welded set, but only queries for overlaps if `IsShapeBoundToBody(ShapeRef)` is true, effectively only using the parent shape.
Intuitively I’d say that overlap queries on a welded child should (only) check the child shape. There might be a case for using all the welded shapes maybe (welded bodies being treated as one generally). Using only the parent shape though seems unambiguously wrong.
In my case, changing the shape of the children is not an option. I could try to disable welding but it might be impractical. I suppose I could run the query on the child BodyInstance directly from C++.
I am a bit surprised by the behavior though. Intuitively I’d imagine that, when welded, the children act as part of the parent, so when testing the parent you would query all the children too, but when test a child you would just query the child. Querying the parent and the children together in all cases would also make sense (they behave as one single body). What happens instead is that the parent shape alone is used for all queries (when passing either the parent or the child to ComponentOverlapComponent) and the child shape is ignored, which seems weird.
I didn’t find comments in ComponentOverlapMultiByChannel/OverlapMulti specific to the welded case, so I can’t tell whether this specific behavior is intended, an oversight or just a corner case that isn’t fully specified. I think it would be useful to confirm with Epic, so if it is actually an oversight then it can be fixed. It would be better if this case worked by default rather than by having to bypass welding.
Thank you for reaching out and bringing this issue to our attention.
Also, thank you for providing a repro project, which makes visualizing the problem way simpler.
Indeed, I was able to observe that the shape that the overlap query is using is the parent’s.
When you hover over the AutoWeld property in Welded>Sphere>Physics>Advanced>AutoWeld, there is a message warning that “Physical settings like collision profile and body settings are determined by the root”, so it looks like the behavior is not unexpected.
Let me know if you are blocked by this and in need of a workaround.
My immediate advice is to be mindful of/avoid this particular problematic setup by either disabling the welding or using children with similar shapes to their parents.
I’ll investigate further and possibly open a JIRA report, sharing a trackable issue link once I have it.
I gotta agree with you that this behavior is misleading, but source code inspection does make it look like it is so by design.
I don’t have access to the exact rationale behind it, but I could ask Epic if this info is valuable to you - just say the word.
As a workaround, I think the cleanest way would be to do as you already suggested: use C++ and shape the query yourself, avoiding the UWorld::ComponentOverlapMultiByChannel’s PrimComp->GetBodyInstance() call, where bGetWelded defaults to true.
Another possible solution would be to avoid welding the components and use physics constraints to hold them together instead, although it might be impractical depending on your setup.
I was told that this specific behavior is intended, as it is baked in architecturally (ie, the ‘unit’ of object is an actor, not a shape), and the decision was most probably motivated by performance reasons.