Upper Red line is the impact point that should be on (or very close to) the static mesh. Unfortunately it spends ~33% of the time chilling at a indeterminate space away from the mesh is what gets returned by the trace. Appears to happen more often on collisions that are scaled out a fair amount.
While I’m at it I may as well mention that the debug lines forming the box sweep motion seem to be way off from the actual rotation (in the above picture the middle lines are from what I guess to be their yaw remaining unchanged) But that’s less important to me than the impact point being correct. If there’s something I can set so those are more accurate, please let me know.
FCollisionShape SweepBox = FCollisionShape::MakeBox(FVector(55,1,1)); FCollisionQueryParams TraceQueryParams; TraceQueryParams.bTraceComplex = false; TraceQueryParams.AddIgnoredActor(this); TraceQueryParams.bFindInitialOverlaps = true; TraceQueryParams.bReturnPhysicalMaterial = true; //debug trace stuff const FName TraceTag("DebugTraceTag"); GetWorld()->DebugDrawTraceTag = TraceTag; TraceQueryParams.TraceTag = TraceTag; FHitResult OutHit; GetWorld()->SweepSingleByChannel( OutHit, //result GetActorLocation() + FVector(0, 0, 200), GetActorLocation() + FVector(0, 0, -100), GetActorRotation().Quaternion(), ECollisionChannel::ECC_Camera, SweepBox, TraceQueryParams);
Same behavior in blueprints in a completely new project: The issue seems to occur more often if you scale out whatever you are trying to hit.
This one confuses me even more:
Any help to make the impact point actually reflect the impact that occurred would be appreciated. I have already written extra traces that occur should things go wrong with a box sweep but I can’t even figure out how to tell if this is occuring on a given hit result. For example, there are a couples of ways to tell if your trace started from inside of an object so you can trace from another direction, but this doesn’t have a pattern I can easily see. Thanks for reading!!