I think I have found a bug in UE4, was able to reproduce it in a minimal example project. So I submitted a bug report at Report a Bug - Unreal Engine, including a link to the example project that demonstrates this issue (and just that). I also described the problem in the UE4 forums. But so far I got no response from the UE4 team at Epic, so I don’t know whether this is really a bug or something else and how to proceed.
Problem is: For us this is a show stopper, we cannot continue with our game as long as this is not fixed - we even don’t see any workaround at all. So my (general) question is: How can we contact Epic to find out whether this is really a bug, also if and when it will be fixed. Or at least what workaround we have.
I understand that Epic does have many other things to do, but at least some kind of response would be great.
We are out of ideas at the moment
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
{
TArray<int32> Result;
if (UStaticMesh* Mesh = GetStaticMesh())
{
FSphere Sphere(Center, Radius);
if (bSphereInWorldSpace)
{
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());
if (Sphere.Intersects(InstanceSphere))
{
Result.Add(Index);
}
}
}
return Result;
}
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.
Hey DamirH, thank you very much for your reply.
As for a bigger radus: I tried it with values up to 1.0, but always the same result.
Subclassing and overriding might be an option, thanks for the idea.
I just thought this might be a bug so Epic would be interested to know.
Last but not least, if [FONT=courier new]FHitResult::Item would be the instanced mesh index, that would be more than awesome.
I will give that oe a try, thank you very much for this hint!
Ohh dear, the [FONT=courier new]FHitResult::Item does indeed contain the index of the instanced mesh.
Thank you so much DamirH, you have saved us a lot of time.
