MultiSphere Trace not returning Impact location

Development World Creation
, , , , ,
1

Hi, I’m trying to get the impact point of a MultiSphere trace but it looks like that it is returning the sphere location instead.
Please see the link below for more information. (I’ve posted it earlier in the blueprint section but couldn’t move it here).

Is this a bug or I’m doing it wrong?
I tried with MultiLine trace and it works fine and returned me locations of actual impact (on the wall) instead.

2

Odd, I used one of these last night in a Blueprint. I wasn’t tracing for actors with skeletal mesh components and the correct debug points showed up.

While the C++ for this Blueprint function does use a depreceated function:

	return SphereTraceMultiByObject_DEPRECATED(WorldContextObject, Start, End, Radius, CollisionObjectTraces, bTraceComplex, ActorsToIgnore, DrawDebugType, OutHits, bIgnoreSelf);
}

The code it uses is similar to what I’ve done manually in C++ and the way it displays debug points is based on the hit result impact points:

		// draw hits
		for (int32 HitIdx=0; HitIdx<OutHits.Num(); ++HitIdx)
		{
			FHitResult const& Hit = OutHits[HitIdx];
			::DrawDebugPoint(World, Hit.ImpactPoint, KISMET_TRACE_DEBUG_IMPACTPOINT_SIZE, (Hit.bBlockingHit ? FColor::Red : FColor::Green), bPersistent, LifeTime);
		}

Does tracing for less types have any affect?
e.g. WorldStatic and nothing else.

3

I’ve tried with just WorldStatic but still the same.
I’ve just tried it with C++ but I’m still getting the wrong impact location. I’ve added the code below to replace the default jump function of the game character class from the 3rd person template.

TArray<FHitResult> hitResults;
    const FVector start = GetActorLocation();
    const FVector end = start + FVector(1.0f, 0.0f, 0.0f);
    FCollisionObjectQueryParams objectList;
    objectList.AddObjectTypesToQuery(ECC_WorldStatic);
    
    GetWorld()->SweepMulti(hitResults, start, end, FQuat(), FCollisionShape::MakeSphere(50.0f), FCollisionQueryParams(), objectList);
    		 
    for (int32 HitIdx = 0; HitIdx<hitResults.Num(); ++HitIdx) {
    	FHitResult const& Hit = hitResults[HitIdx];
    	::DrawDebugPoint(GetWorld(), Hit.ImpactPoint, 15.0f, (Hit.bBlockingHit ? FColor::Red : FColor::Green), true, 3.0f);
    }
4

SingleSphere, Capsule etc have the same problem too.
The only thing that works are the Line traces.

5

Hi,

This is indeed a bug. The problem happens when the sphere at the start location is already overlapping with the hit object you’re testing against.

We’ll be looking into this, thanks for bringing it up!
Sorry for the trouble

6

has this bug been listed to the next update?

7

Hi WillianG83,

Thank you for bringing this to our attention. This report was missed when we migrated to our new tracking software. I re-entered this as JIRA UE-7826 in our system and the developers will be investigating the issue further.

Cheers,

TJ

8

I looked in to this and it actually doesn’t appear to be an engine bug, but it’s something we can message more clearly so I’ve taken some steps to do that.

In cases like this where you make a query and are initially overlapping something, we can’t really determine a good ImpactPoint or ImpactLocation, because you started in the object with more than one point of contact (a whole surface of contact). In this case we set Location and ImpactPoint to the start location.

I added a new bool to BreakHitResult to report “Initial Overlap”, and improved the comments on the other relevant fields to hopefully make this more clear in the future.

9

Has this issue been solved yet?

10

See my answer to the post. This is not a bug; in the case of initial overlaps there is no defined ImpactPoint or Location. 4.8 will make this more clear in the exposed values in BreakHitResult and in documentation.

11

What is a good work around then? For instance I’ve got a grenade and am doing a multisphere line trace from the actor’s origin for any damagable actors, simulating shrapnel damage. Once I got the impact point, I’m tracing back to ensure the hit location isn’t blocked by some non-penetrable actor.

However, in this case the trace starts at the grenade’s origin, and thus initially overlaps damagable actors. I’ll provide pictures if my setup isn’t clear.

12

A good workaround, at least for me was to not set the start and end of the trace at the exact same location