URootMotionModifier_SkewWarp::WarpTranslation() uses InverseFast() within a block of code that is only executed if DeltaTranslation is *not* nearly zero. The ToRootSyncSpace transform the code builds, however, is apparently NIL because the InverseTransformVector() call on Line 57 causes an ensure in extremely rare circumstances. The math taking place here is presumably weaseling out a tiny edge case. Apparently, InverseFast() isn’t actually any faster than Inverse(), so I’m wondering if the fix is to just call Inverse() instead as the ensure indicates. If that’s not a good fix, what can I do on my end to prevent this from happening? This is all occurring long after the request to perform the warp was made, so it’s unclear if there’s any recourse here but an engine mod.
We’re using the Motion Warping plugin for our ambient character animations. Very rarely (twice since we started using it ~6 months ago), we get an ensure() call related to trying to invert a NIL matrix. This is a simple root motion warp to get characters into and out of ambient animations more smoothly. The warp is being handled in native code rather than blueprint, simply by calling MotionWarpingComponent->AddOrUpdateWarpTargetFromTransform(). Outside of our subclass of CharacterMovementComponent calling Super::TickComponent(), there’s really nothing project-specific in the callstack.
Thanks for raising this. There is a bug here, and therefore, there is little recourse other than an engine modification. You’re change seems fine, but yes, inverseFast doesn’t calculate scalar data. It is faster for something that is calculated on a tick, like a motion warp. In the case of your change, NIL basically won’t be “checked” and you won’t hit the ensure, and it will return identity.
It’s worth noting that calling InverseTransformVector() multiple times in a row is kind of inefficient since it’s recalculating the same inverse matrix each time before transforming it by the Vector.