Animation integration is also being expanded: the plugin now better supports the Unreal Animation Framework,root motion-based movement*, and complex character setups — allowing animation-driven movement to influence simulation directly, regardless of thread execution order.*
Mostly regarding the Animation Sample (motion matching) which I’m trying to convert to Mover - root motion isn’t working out of the box and I don’t think you guys added 500 notifies to use MotionWarping.
Couple of questions here:
What’s the state of Root Motion and Mover @ 5.7?
Any plans of supporting root motion like in Animation Sample (motion matching) for Mover?
What’s the best way of converting Animation Sample (motion matching) to work with Mover in your opinion? (for locomotion and custom montage launching - which the second one is simpler I think using the Layered Move)
Mover in is still experimental in 5.7, but everything the Witcher demo was using was mover and all of the features are in the engine. That includes generating trajectory data from root motion and playing root-motion animations from animbp through mover. Note: You will need to look into the trajectory tools as well to generate trajectory data.
Any plans of supporting root motion like in Animation Sample (motion matching) for Mover?
For the update that we will be showing in the animation sample with mover, we use capsule-driven characters, but the animation itself is built to be used as both capsule or root motion driven. The traversal animations are triggered in root-motion-driven montages, as shown in the animation sample update.
What’s the best way of converting Animation Sample (motion matching) to work with Mover in your opinion? (for locomotion and custom montage launching - which the second one is simpler I think using the Layered Move)
For this, it would require quite a long explanation, and so I would recommend looking out for the update to GASP in very near future. We will also be doing a live stream about the addition of a mover example and the details of how it’s built.
If this is time-sensitive, I can give you a rough overview.
Thanks [mention removed] ! I can wait for the new examples.
One question about the layered moves at this time which I want to clarify.
I’m using FLayeredMove_AnimRootMotion - which is configured to OverrideAll. I want to turn the character during this move to specific direction (input for example) so I have created another LayeredMove (FLayeredMove_TurnToInput) which is configured to be Additive with higher priority.
What I’m seeing is:
Priorities are not working?
We are not able to override only the angular velocity?
If one of the layered move has overrideall - it will override any other layered move that comes in.
My goal is to have an player action that is using root motion, but in the first part of the action player can turn his Pawn to the input direction. How I understand Mover the proper way of doing this is to use Layered Move. Or should I do it differently in 5.7 Mover state?
And second question is about replication on clients when using GAS UPlayMoverMontageCallbackProxy - from what I can see the animation is playing only on the server, and owning client - not for simulated proxies. When we can expect more work on the GAS and PlayMontage (Mover)?
I need to verify a couple of things with a dev who is away until Wednesday next week, but I wanted to give you a cursory answer based on what I know of the code.
Priorities are not working?
They do, the issue is more that OverrideAll takes precedence. If there is a OverrideVelocity or OverrideAll on the stack or will placed on the stack, those will overwrite that data.
We are not able to override only the angular velocity?
Angular velocity overrides can be made with using Mixmode::OverrideVelocity
If one of the layered move has overrideall - it will override any other layered move that comes in.
Correct, unless there is another override example that is higher priority. It’s the additive case that basically can be squashed.
How I understand Mover the proper way of doing this is to use Layered Move. Or should I do it differently in 5.7 Mover state?
I believe you have the right of it, this is going to be the clarification I will need to make with the dev. In the meantime, I would recommend try working with OverrideVelocity instead of additive, cumulating the velocities if you can, and then using priority. Not ideal, but could work as a workaround at the moment.
Everything I mentioned is correct, but it looks like an unintended for some future work. I’ll log an issue and post it here for you to follow later this week.