A Trace Oddity

[Amstrad00]

I currently have a blueprint set up to run multiple line traces consecutively. The first from the camera and then a second from the weapon socket, using the first trace’s collision point as its endpoint. The initial trace runs fine and reports location and any actors hit properly, the second trace is behaving oddly however and not always properly colliding. Even when tracing to a different spot on the same object it had collided with before.

Some examples:

[anonymous_user_b9532c9a]

Hi Jotham Perkins,

Can you show me a screenshot of your traces and how you have them set up?

[Amstrad00]

Sure, here’s the setup

And here’s two views of the same trace

My current workaround for this involves using a sphere trace with a small radius for the trace fired from the weapon, but I see no reason two traces fired one after the other like this should be giving such odd results.

[anonymous_user_b9532c9a]

Try placing a branch node after your first trace. It may be moving too quickly to fully register correctly. If you place a branch from your return value of the first trace, and if true run the second trace, it may give it enough time to correctly register the locations.

[Amstrad00]

Trying that, I’m still getting cases where the second trace isn’t reporting properly or is reporting the value of a previous hit. Working off the theory of it being a timing issue I also tried a delay node with 0.1 duration and received similar results. Upping the duration to a full second still produces the errors (never-minding that a full second delay is unacceptably long)

In previous attempts to work around this I’ve also attempted to run the initial trace using a blueprint on the player, storing the vector in a variable and then running the second trace on the weapon which still resulted in the above described behavior.

[anonymous_user_b9532c9a]

Unfortunately I haven’t been able to reproduce this on my end. I’ve tried several different setups but each time it seems like my second trace is working exactly as intended. What specifically are you trying to get the second trace to do?

[Amstrad00]

I’m using the two traces as seen to accurately handle weapons fire.
A single trace from the player camera to the reticule at screen center would be accurate in most cases, but not those in which the path from the weapon’s muzzle was somehow blocked by interceding geometry.
If we instead trace from the weapon muzzle (or even just a socket on the character) along a vector from the player camera, the result better accounts for possible geometry interference, but the end point is far less accurate and in most cases does not fall under the reticule.
We solve this problem by using the first trace to establish an accurate endpoint for the second trace, while using the second trace to test if we’ve actually hit a valid target.

As I’ve mentioned above, I’ve managed to work around the issues I’m having with using two line traces by simply using a sphere trace with a small radius for my second trace, which returns the desired results. But I’m somewhat surprised that I’m the only one encountering oddities with using back to back line traces.

[anonymous_user_b9532c9a]

Which version of the editor are you using?

[Amstrad00]

I’m using 4.7.3, the issue was also occurring under 4.7.2.

[anonymous_user_b9532c9a]

Do you have a sample project you would be comfortable sharing that is showing this error? I haven’t been able to reproduce it on my end so far.

[Amstrad00]

I was able to recreate this without trouble from a fresh copy of the Third Person Template, here is my project:

Dropbox - File Deleted

I’ve included both an example of the buggy behavior as a left click event on the player blueprint and my current workaround as a right click event. Keep in mind you may need to fire a few times before encountering the error, while at other times it’ll happen immediately. Just keep an eye on the print output.

[anonymous_user_b9532c9a]

I had a look and it looks to me like the trace is doing everything as intended. When I press it it will register the traced to target unless another object gets in the way, at which point it will register a hit on that target instead. In every instance it seems to be acting as I would expect it to. Try upgrading to 4.7.4 and see if you see the same thing.

[Amstrad00]

Really hoped the update would have this working properly and we could close this issue, but I’m still encountering it. I’d say 8/10 the trace works fine, and then it bugs out. Once it bugs out it seems to stay bugged.

[anonymous_user_b9532c9a]

link text
I’ve attached a video of what I’m seeing on my end. The first 10 seconds or so is LMB trace, the second 10-15 is RMB. The only oddity I found was with the RMB I was sometimes able to hit the pawn skeletal mesh, but that may be due to the Tpose getting caught behind the player capsule as opposed to a bug. Is there anything else I can try to reproduce this on my end to your knowledge?

[Amstrad00]

You’re clearly reproducing the bug in that video.
Those blocks are CubeMesh2 through CubeMesh7 from left to right.

Here you’ve shot CubeMesh7, but the second trace is still reporting the hit to CubeMesh6

Here you’ve shot CubeMesh4, but the second trace is still reporting CubeMesh5 you hit previously

Here the last three traces you fired are all bad, you’ve shot CubeMesh4, CubeMesh3 and even the large CubeMesh2_4 in the background, but the second trace is still reporting the hit to the small CubeMesh5 you shot 4 traces ago.

Nearly all the shots you fire with the RMB later in the video are perfectly demonstrating the expected behavior of the LMB button trace. Both output messages are showing the same target hit for every trace fired. The only exception I noticed there was when you happened to fire right along the edge of an object, which I chalk up to the fact the second trace on the RMB is a sphere trace with a radius so it’s likely to catch edges like that.

[anonymous_user_b9532c9a]

Hi Jothan Perkins,

Thank you for that information. That made it much more clear what I was looking for and can confirm that the bug was reproduced. I have entered a bug report, UE-13311 to be assessed by the development staff.

[zeroexception]

There are a few issues going on here, some which you can fix, some which I have fixed in the engine:

1. You should check the return value of LineTraceByChannel (which indicates whether there was a hit) before using the hit result, because you don’t know if you actually hit anything.
2. This one is more subtle: you should not assume that tracing exactly to the end point of a previous hit will result in another hit. This is due to float precision; while logically this seems correct, the hit location won’t be exactly on the surface, or when multiplying by a trace direction some precision differences will occur. I suggest adding a small extra distance to the second trace along the intended trace direction (I got it working fine in your example by adding only 1cm / Unreal unit).
3. Even though you didn’t check for a hit, we should have cleared the hit result to indicate an invalid hit. I have fixed that CL 2506971 for 4.8. Your project can still work fine though if you just fix #2 and #3, this engine fix is for the case where you don’t check the return result.

[VidemusOKC]

Oh my god I thought I was going insane with the dysfunctional second line trace problem. I’ve been trying to figure out what I have been doing wrong for two days straight, finally decided that the 2nd line trace is stopping just short of the first line trace’s Impact Point (as you said, due to precision), and therefore never hitting.

Thought about trying to add a little distance to it manually but figured that was way too intelligent of a thought for me to have and hadn’t actually tried it yet.

Will try now lol.

[VidemusOKC]

LOL…dammit so much. Fixed.