Incorrect 'Location' returned by 'OnTraceHit_Event'

[Soliax]

Hello,

Firstly, I'd like to acknowledge that while I'm not an expert in UE5, I've encountered a peculiar issue with your plugin. Here's a breakdown of the problem:

• The location returned is accurate when using the LINE shape.
• However, the location returned is inaccurate when using either the SPHERE or CUBE shapes.
• With the CAPSULE shape, the returned location yields inconsistent results. It seems correct when the hit occurs on the line between capsules, but incorrect when the capsule itself is the source of the hit.

Here are the configurations for the Melee Trace:

And for the Animation montage:

Additionally, here's the Blueprint AI code:

Regarding the location issue, here's an example:

As illustrated, the returned location vector in such cases is completely incorrect. Conversely, when using a line, the hit location returned is accurate.

Could you kindly advise if I've overlooked something, or if the issue lies within your plugin?

Note: In the example, I'd expect only one sphere to be drawn, but as observed, multiple spheres are drawn (although this doesn't seem to be the root cause of the incorrect location behavior).

Aside from this issue, I'd like to express my gratitude for your plugin; it's truly amazing and remarkably easy to use.

[Soliax]

Engine version : 5.3.2

[rlewicki]

Hi @Soliax, first of all, thank you for reaching out and posting very detailed description of a potential issue.

Note: In the example, I'd expect only one sphere to be drawn, but as observed, multiple spheres are drawn (although this doesn't seem to be the root cause of the incorrect location behavior).

Looking at the Melee Trace anim notify state definition in the montage you posted in seems it's duration is one frame only so it indeed should only draw 1 sphere rather than multiple spheres. I do not have such case covered in my testing playground so I will add it and inspect if there is anything weird happening.

For the first part regarding all shapes other than line being drawn incorrectly, I haven't really noticed anything strange in my testing. I'm using all of the shapes with a melee sword animations and them seem to be acting alright:

This however brings lack of information in the debug drawings. To be able to tell whether these shape are drawn correctly the debug drawing should also include: a. sockets it's using as start and end location b. center location of each interpolated point instead just shape (not relevant in case of the line trace)

I will also try get the debug drawings inside the animation editor so it's much easier to setup without going into PIE.

Let me know if you have any further questions!

[Soliax]

Hi @rlewicki,

Perhaps I wasn't sufficiently clear, but the primary concern does not pertain to the traces being drawn incorrectly. Throughout my testing, all shapes drawn appear to align perfectly with the animation. The problem lies with the returned 'Location' value upon a hit. For some inexplicable reason, it provided me with this weird value:

X=1649267701760.000 Y=8192.002 Z=0.008

As I previously elucidated, when employing a line shape, the computed value for the 'Location' output variable in the event 'On Trace Hit' is accurate, whereas for other shapes, it proves to be incorrect.

[rlewicki]

Ah, this make much more sense now! Sorry about the confusion. I'll take a look at it now

[rlewicki]

Okay, I've prepared a gym where I h ave animation with each shape hitting a target in front and then drawing magenta spheres in the hit locations. Here is a video of the test:

https://github.com/rlewicki/MeleeTrace/assets/10658394/0b4baa84-48f5-4ea9-8c65-0695583e397c

And here is the blueprint for the above test:

Honestly it seems that the HitLocation for all the shapes is correct. Can you think of any other test I could prepare to try to reproduce your case?

[Soliax]

Concerned about potential issues affecting my project's test results, I opted for the simplest testing approach:

1. Initialized a project using the Third Person template.
2. Enabled the Melee Trace plugin.
3. Imported the Kick.FBX file using SK_Mannequin

Kick.zip

4. Created an Animation Montage for the Kick Animation Sequence.
5. Configured the Kick_Montage according to the provided specifications.

6. Added MeleeTrace to BP_ThirdPersonCharacter
7. Integrated the provided code into BP_ThirdPersonCharacter.

8. Launched the editor.
9. Triggered the kick action by pressing K on the keyboard.

Results:

• Multiple spheres were generated by the Melee Trace.
• No debug sphere was drawn on the floor.
• Received a hit location value of X=0.000, Y=0.000, Z=0.000.

Note: The character did not execute the animation as it is not fully set up for such actions by default. However, I aimed to maintain simplicity throughout the testing process.

Hope this test is legit, as I might have made it too simple, but I wasn't able to track anything wrong on my project.

[rlewicki]

This is great, thank you very much for detailed steps. I'm setting it up now and will let you know what I find.

[rlewicki]

@Soliax I'm happy to confirm that I have found the issue and it is legit indeed! Turns out the problem was that in OnTraceHit event I am passing HitResult.ImpactPoint which for some reason sometimes has incorrect values, like in your test, it's equal to (0,0,0). But if I instead use HitResult.Location it works just fine.

I'll submit a fix in a minute and publish new version of the plugin sometime today.

Thanks for help, really appreciate it!

[rlewicki]

Fix submitted in 063d57a in case you would like to inspect it yourself.

[rlewicki]

Actually I kept investigating this one and it turns out this is an issue with the physics engine implementation (Chaos). If you perform a sweep with start and end location being almost identical the engine doesn't properly recognize the impact point.

To mitigate this issue I'm checking whether sweep start and end are equals and if yes, I'm adding a KINDA_SMALL_NUMBER to the previous frame sample. This shouldn't have any meaningful impact on the precision of the trace but solves the issue in the example you presented above.

[rlewicki]

Closing the issue as this has been now submitted in release v1.4.0

Thanks once again :)