I’m setting up a character’s locomotion using pose search (motion matching) with orientation warping. My character is using CharacterMovementComponent for movement.
Since the Motion Matching and Motion Warping nodes feed root motion data to the Root Motion custom attribute, I’m using AttributeBasedRootMotionComponent to apply the root motion to the CharMoveComp’s RootMotionParams field.
I’ve run into what seems to be a tick order problem: the Skeletal Mesh Component ticks after the Character Movement Component (because of Tick Prereqs), and the AttributeBasedRootMotionComponent ticks after that, in the PostUpdateWork tick group.
This seems to mean that the root motion which is generated by the SkelMeshComp’s tick is set in the CharMoveComp’s params after the CharMoveComp has ticked in the frame, so the CharMoveComp’s PerformMovement path will always be using the previous frame’s root motion data. This is creating some issues for us with the character’s trajectory calculation.
So: is this the right way to set this up? Is there a way to ensure that the root motion is generated by the SKM before the CMC performs its movement update each frame?
This is by design, the best thing to do is to use the OffsetRootBone node in the animgraph to fake one frame of root motion. There is much in the current implementation of root motion in CMC and Animbp that ends up in scenarios like this. In the future with UAF we have more control and can ensure same grame generation root motion.
No problem, there are some different modes for the offset root bone, but the main idea is that it allows you to have the capsule and animation deviate from their root position. Yes, it does allow the root bone to “catch up” to the capsule on a settle, but on a start it allows it to stay planted for a bit. This means that your trajectory data and root motion data are more “accurate” because they don’t have to exactly match what the capsule is doing.
Interpolate is the option we use in GASP most of the time, and then we use Release during actions like falling and or stopped to prevent over-interpolating during miniscule or very large movement.
Apologies for the delay, we just got back from holiday break.
That is accurate, and how we do it in GASP. Root Motion in anim blueprint can work sometimes, but you’ll run into issues like the above. We are working on a new animation framework that intends to make root motion easier to handle and allow you to intersperse root motion and capsule driven like you are mentioning.
Oh, I see, thank you. Do you have any more info about how to use OffsetRootBone to fake a frame of root motion?
I confess some confusion about the purpose of OffsetRootBone, I thought it was to reset the transform of the root bone over time in situations where previous root bone warping had moved it.
Interesting, I’m trying to wrap my head around that.
I may have been thinking about this backward: I was expecting that our (NPC) character would select the anim based on intended trajectory, and the character would use the root motion of the anim to move the capsule.
Based on this discussion (and a further review of GASP), I now think the character should be capsule-driven, but with OffsetRootBone used to allow the root motion from the anim to apply to the mesh’s transform, sometimes and somewhat disconnected from the capsule’s transform.
Is that accurate? If so, that’s a bit unfortunate because we were planning to have some loco moves on this character that would be anim-driven and hard to create using character movement logic.