I feel like this is almost certainly not intentional behaviour. When using a NON-complex line trace (single or multi) against a Static Mesh with more than one collision hull, only the first collision hull actually registers a hit. All other hulls are ignored.
This can be tested with the VR demo map mesh, which has 13 primitives. When doing a line-trace against it (I created an object channel which its supposed to block) - only the floor hull will block that trace, the walls etc. will not.
This is either undocumented behaviour or a bug IMO.
I think that’s intended behaviour. A LineTraceByChannel should return the first blocking hit. If you want multiple trace hit results you need to use MultiLineTraceByChannel and it returns all objects hit.
That’s not what the question is addressing I’m afraid.
The issue is that if a Static Mesh has multiple collision hulls, only the first collision hull will block collision queries. I’ve re-worded the question to make it easier to understand.
You need to use the MultiLineTraceForObjects and not the ByChannel Version.
I think TraceByChannel Ignores repeated hits for the same actor for efficiency and because it’s generally used to detect when actors are blocking a trace so additional hits for the same actor would be redundant.
I tried it out with the MultiLineTraceForObjects and it seemed to work just fine even with multiple hulls.
This still doesn’t solve the issue. This isn’t an issue with Multi-Line Trace, it’s an issue with a single line trace.
If a Static mesh has more than one collision primitive, then ONLY the first primitive will block line traces. Any trace against a different primitive will not be blocked. I’m adding a video to show the issue.
So crisis averted, but the result of this is pretty frustrating. After ages spent debugging trying to work out why this wasn’t working, it’s because the collision hulls on the SM_Room_01 mesh that comes with the engine are not set up properly. If you look closely near the centre of this image, you can see a big gap between collision primitives.
What I was doing to find this bug was tracing down from the sky to the world KillZ. If you look there, you can see a gap where the walls and the floor don’t line up. In my code, I was clamping the max X and Y position of my trace to be within a certain area - and I just so happened so set that area so that it was perfectly in line with the holes in the meshes’ collision:
What I thought was happening was that the trace was hitting the walls from the top and not blocking anything. You can see here that when the trace is against the floor, it blocks properly:
