I looked at your other thread and it’s quite simple - what you’re experiencing is not a bug. I can’t say for certain why what you’re seeing is happening but it’s fair simple to debug it. Take a look at the code of GetInstancesOverlappingSphere:
TArray<int32> UInstancedStaticMeshComponent::GetInstancesOverlappingSphere(const FVector& Center, float Radius, bool bSphereInWorldSpace) const
if (UStaticMesh* Mesh = GetStaticMesh())
FSphere Sphere(Center, Radius);
Sphere = Sphere.TransformBy(GetComponentTransform().Inverse());
const float StaticMeshBoundsRadius = Mesh->GetBounds().SphereRadius;
for (int32 Index = 0; Index < PerInstanceSMData.Num(); Index++)
const FMatrix& Matrix = PerInstanceSMData[Index].Transform;
const FSphere InstanceSphere(Matrix.GetOrigin(), StaticMeshBoundsRadius * Matrix.GetScaleVector().GetMax());
The whole thing is very simple and very straightforward, there’s nothing to go wrong. It takes the radius of the bounds of your mesh and checks if they intersect the sphere you passed in as a parameter. Due to the way this works (i.e. it doesn’t actually look at the collider of the ISM instances), there will be some discrepancies between your trace results and your overlap results. My best guess for a fix would be to just slightly increase the sphere radius you pass into the ISM.
That being said, if that behavior is not to your liking, it’s a virtual function so you can create your own ISM subclass, override it, and have it handle the check any way you want.
THAT being said, I am pretty certain that FHitResult::Item contains the instance index if you’re tracing against a ISM, but to be fair I could be misremembering that one.