Hi guys,
here are some questions, please don’t hesitate to answer even if you knew only one question of them.
a. I wanna know if Root motion when enabled includes “rotating” the character and not only changing its “location”?
b. does Root motion work on Pawns and Character?
c. Does it affect the character (or pawn) in a way similar to the functions SetActorLocation and SetActorRotation i.e. kinematic effect on the “root” component of the actor?
d. If there a particular problem here with Blender, should I use Maya for instance?
Here’s addition details (not really necessary to read ): I have a pawn with a component SkeletalMeshComponent, attached to the root (in C++). I imported animation, then enabled root motion both in the animation sequences and in the AnimBlueprint root motion mode “Root Motion from Everything” applied. Then I log printed the Rotatoin of both the actor (Pawn) and the SkeletalMeshComponent itself, and both have their rotation not affected as I play the animations with root motion (rotation specifically).
Hello.
I wasn’t really sure, but checking the source code I can answer you:
a. Root motion applies movement and rotation.
b. Root motion works only with characters, the reason of this is because root motion is processed in the CharacterMovementComponent, which the character has. Pawns have PawnMovementComponent so it won’t process root motion.
c. As long as animation imports the root motion correctly, there should be no difference between Blender and Maya. I remember some time ago that when animating in blender, the Armature object had to be animated as it was exported as the “root” instead of the inner root bone. But more recently I think the blender fbx exporter strips the “armature” object and grabs the root bone animation as root. I’m not very sure about this one, but you can test it easily.
Root Motion contains the necessary data as it’s the root that determines the location, rotation, and velocity of the character relative to world space Root Motion will work on character BPs as well as pawns as the only real difference between the two is the character BP includes a movement component by default but in theory RM does not require a movement component except for the collision provided by the capsule as well as the physics of the player always being in a constant state of falling. RM is direct drive so does not require or makes us of the same controller inputs as would the movement component as it’s the capsule via the movement component that moves and the animation of the in-place character reacts to changes to the capsule.
Down side.
There is currently very little documentation as to the use of RM in a practical manner.
RM is not suitable, at the moment, for games requiring network support as it;s the capsule that provides replication as well as world position data.
Upside
RM does not require fancy ABP’s or even state machines as RM is event drive, like a QT event, that only requires the trigger event via a custom logic as to the current state of the character in world space. This will allow you to do fancy next gen animation designs like motion matching
To author animations you can use any app you wish keeping in mind that it’s the root that determines all aspects of the players placement in world space.
Root motion is not that bad for online usage. But you need to be clever about how to use it.
When you set up your AnimBP, you can set the root motion to be enabled with everything (bad) or with AnimMontages only (good). This is actually made to make it easier to use root motion only for certain things, while using capsule based locomotion for the rest of the things. The idea behind this is that you don’t need to sync the animation, just triggering the animation in clients at the same time would be enough.
I’ll look into that for sure. For the past few days I tried to make a manual alternative for Root motion. The whole idea was about some trickery in the animation itself, coupled with manually rotating the mesh simultaneously as I manually run the Animation from the same code.(I actually ran all the AnimSequences through the Gameplay code, and I found some synchronization problem between the AnimGraph state machine transitions and the code parameter changes, which is another issue, which is potentially solvable). The main “logical” challenge appeared when I decided to cut an animation before finishing and going to the next anim with other Root motion alternative manner, things started to get more complex than it should rather be.
In short, this alternative manual manner is a little bit more complex in Animation creation and the logic as well. I few hours ago I reconsidered trying root motion again, given the fact that I built my Online requirements not to include any demand for accurate synchronization between players, neither their locations, nor animations of course, all are needed as mere approximations, rough approximations even. To be honest with you, I’m not yet well informed on online programming ( I learned some basics theoretically, and outside of UE4, I’m just reading a textbook for multiplayer programming) and that’s why I don’t have the enough knowledge to discuss this issue with you or FrankieV even though it is very relevant to my game.
So I’ll reconsider all that again for sure. Thanks again for your time and effort. I appreciate it.**
Well the main problem is there is just not enough verified documentation as to the practical use of root motion, and more so if there is a need for network connectivity so at this stage animators love it but coders hate it as the movement component does a lot more than just control the animation output.
RM will work over network just like any other event drive action but more or less have to build your own controller that replicates. On the other hand the movement component capsule, bounding box, is tech that has been used since the beginning of on-line games and not only handles the animation requirements but also handles the important stuff where are the players located relative to world space and if there are errors generated will correct them.
All that stuff that the online character has to do, and done by the movement component, would have to be duplicated and is a LOT to ask your coder to do as net code is more Voodoo magic than something that you can explain in practical manner.
Why included RM in the first place? Well because it is the future and we have yet got there as far as a ways and means that you can trust to work each and every time in a game you plan to sell.
After all when money becomes involved you have only one chance to make a good first impression.
I discovered recently that to have root motion give all aspects of translation and rotation, you should set your orient rotation to movement to true, and use controller rotation yaw to false (i.e third person controls) , and set movement mode to flying. Movement mode walking allows translation, but doesnt seem to allow rotation
