In the screenshots below you can see how I apply the very minimal animation that's on the root bone to the pelvis bone. But when I do, it causes sudden spikes / value changes over 1 frame that cause horrible glitches in the character animation. There must be an error with the additive math here and this needs to be fixed.

Here we see the result of the external motion import - there is minimal animation on the root bone. If I leave this animation here, then the character's feet slide when importing into Unreal and the character appears to rotate about the y-axis (Unreal coordinate system)
33% of original size (was 1521x478) - Click to enlarge

The solution should be therefore to apply the root motion to the Pelvis. Here is a screenshot of the Pelvis curves BEFORE root motion is applied:

33% of original size (was 1521x478) - Click to enlarge

This is already pretty bad but I think that's coming from the mocap tool. We'll need to smooth this out under any circumstance. I should point out that these curves are kind of ridiculous because the character animation is an Idle animation - the character barely moves at all. I have no idea where these giant curves are coming from, but I blame Rokoko.

Here's the smoothed hip curves:
33% of original size (was 1521x478) - Click to enlarge

Now we're going to apply Sample Root to Hip. I should point out this is on the unlocked Base Motion layer for simplicity.

33% of original size (was 1521x478) - Click to enlarge

The zoomed-in screenshot below shows the result of applying this function. Note the sudden jump from frame 3029 to 3030 and 3048 to 3049.
33% of original size (was 1521x478) - Click to enlarge

This cause visible "glitches" in what should otherwise be smooth motion.

there's no good reason for it. In the final screenshot below you can see the root and pelvis curves BEFORE applying the root-to-hip function and none of the curves have any dramatic change that could account for these new "glitches"

33% of original size (was 1521x478) - Click to enlarge

So it's a bug and needs to get fixed. Obviously running smoothing AGAIN will clean this up but it shouldn't be necessary and is just an kludge to cover up an algorithmic error.

Unless I'm missing something obvious, in which case I'm dying to learn the solution.