Hey @FrankieV, do you think that with *AnimMontage * I can not replicate a walking / running Root Motion animation?
Well the Root (lol) of the problem is there is not enough accurate information to even recommend the use of Root Motion over network in the first place. I would assume that RM like anything else event driven will replicate. Making something move is not the problem but rather the lack of proper error correction Root Motion becomes a fire and forget event with no way of knowing where the player is located relative to world space. So yes you can replicate run and walks as a state change but there is not enough information that guarantees that all 32 clients will be located relative to one another.
The miss direction at the moment though is the general thinking that RM and in-place as far as animation goes is the same but is in fact two totally different ways for the player to interact where current information as to documentation and tutorials that does include the use of in-place does not apply if in-place is replaced by RM and to Epicās benefit itās best practice not put out āanyā information until a working design pathway as to network requirements is made available.
Sooooo
Once again sure it will work, mostly, but the back end means the coders job would become equal to what would be necessary on the netcode side of things which would be a massive undertaking.
Root Motion is never going to be good looking (or usable for that matter) in multiplayer games. I would just abandon this venue from start and focus on solving problem in a way it can be solved.
That means, driving animation trough parameters from movement (velocity/acceleration), like itās done in Paragon, For Honor, Gears Of War 4.
Root Motion animations are best used as source for Acceleration/Velocity curves.
1 Like
I agree 100% as raw RM over network is like trying to mix water and oil and the problem to correct is the timing issues created by the movement component and itās constant acceleration and velocity as to simple timing corrections for say climbing a ladder, a ledge, jumping in place and of course correct walking/running to prevent skating.
I did suggest back a bit that the need is not to use raw RM over network but for the MC to respect the data placed on the root of the animation as just another data set/input. My reason for this is it is MUCH easier to author animations using root motion than it is to try to deal with the secondary timing problems required to make in-place look good.
[Sorry for taking so long to respond.]
As far as replicating root motion over network with Unreal, it absolutely is supported and can be done.
To understand how it works, first consider the problem of just synchronizing animations.
Lets say we have a walk/run/blend animation. The blend factor is based on a variable called speed.
The AnimationBP relies on the Speed variable in the CharacterBP. It reads this every frame in UpdateAnimation.
UpdateAnimation is called, reads the speed variable, and determines the blended pose for the BlendSpace based on the value in Speed.
Now to synchronize the animations over the network, you have to synchronize the Speed variable by replicating it. This keeps all the animations relatively in sync - however, due to network latency, there will always be a few frames that dont match exactly. But in general over time, the same walk/run/idle will end up playing on the client and the server.
Now consider root motion. The root bone transform from the current pose is applied directly to the characters capsule.
Thus the animation (whether playing on client or server) will move the pawn.
A common source of confusion is that you need to replicate this motion.
You DO NOT replicate the motion.
You replicate the variables that control animation state, and let the animation (independently playing on all machines) dictate the motion.
If the animations were perfectly in sync, then the positions would perfectly match.
They are not in sync, so their is a reconciliation process used to match their position over time( just as it is used for non root-motion).
Without root motion, you typically replicate velocity or some other state and then rely on client-side prediction to determine position between network updates.
With root motion, you let the animation playing determine position between network updates.
In both scenarios, you rely on position reconciliation to update the positions based on the most recent location update.
(If you are interested in looking at the reconciliation code specifically for root motion on the CharacterMovementCompenent, it is in UCharacterMovementComponent::ClientAdjustRootMotionSourcePosition_Implementation().)
It is important to note that Root Motion may not work in your situation- it depends on what you are doing whether it makes sense for you.
Given the confusion and interest, I will try to record a short tutorial and post it here.
3 Likes
I went ahead and created a short video:
And here is the companion blog post:
http://www.casualdistractiongames.com/single-post/2017/05/09/UE4-Root-Motion
Let me know if you have any comments/suggestions/questions
2 Likes
Interesting stuff.
I think the root of the problem, pun intended, is the inability to adjust and fine tune the constant velocity of the movement component relative to the curved nature of organic movement which when adjusted for timing adds a movement latency of a decision and event that already occurred.
Something simple like a jump in place that is done correctly as to body mass and wait states feels muddy as itās already a triggered event but then has to wait until the cycle plays through to the end of the cycle. The result is poor looking animation traded in favor of game speed.
The issue as to the reason RM is desirable is there is no way to tweak the constant velocity in the movement component to find the butter zone via discovery with out either cheating the source animation or via a hack using the animation BP.
All of this chit chat has inspired me to do a bit of a rant. 
Thanks for that I just donāt see appeal of root motion. Itās not needed for games it actually doesnāt really fit into dynamic enviroments and itās slower to iterate. Designers will always tweak values to match gameplay, so it better to have system which will dynamically adjust animation for gameplay and use as few as of them as possible (and when possible dynamically generate them at run time).
I really donāt understand why people are trying so hard to have networked root motion, when it makes more trouble than it is worth, doesnāt look good, and will actually make game heavier (more bandwith needed).
Iād rather focus effort of improving animation play driven by capsule rather than driving capsule by animation.
I agree that the use of a movement component solves a lot of problems as to the demands of network multiplayer but since most critical requirements in Unreal 4 is now done client side UE4 does require a rethink of being able to have your cake and eat it to even though the cake is a lie.
To give some perspective Iām a content artist that understands the logic but not the ways of the code but thinking that animation cannot made to look good over the network is BS if itās considered as being just another event triggered between clients.
As to the appeal of Root Motion all things relating to locomotion would mean that 100% of the game speed dynamics and mechanics would be under the animators control that is triggered as an event. You want the player to move forward when pressing A then you just have to plug in moveforward from the input table and off it goes. How this behavior would effect network play who knows but the fact that it removes the coders ability to control things like velocity is probably the reason most coders hate RM.
I agree. The problem with having AAA over network animations is a right versus left brain thinking of just what is animation in the first place.
The problem is in the thinking that game speed and velocity is the same so in most cases out of the box the velocity of the capsule is a constant with in world space and is not stepped as to the animation being referenced to ground as to foot placement. Its a problem that can be fixed but has to be done at the source level and most ready made animations do not take into account the constant velocity problem.
This is what usually referred to as the animation being grounded.
That said as a reference.
Referencing the half way point (8.15) the right foots forward velocity becomes zero as to referencing the ground and itās the scale of the animation cycle that supports the illusion of speed so for the animations to look good, be it over network or local, then the velocity of the capsule should be step keyed and not a linear forward motion. This by itās very nature is what RM fixes but out of the box and someone new to the ways of UE4 and do not have the ability to edit the source then what should be a small adjustment becomes an animation blueprint hack, which is not a problem if you know what your doing in the first place.
As a guess as to what can be added as a feature is a gimble component that can be added to the capsule that can be told to reference the ground
OK for my 10ās of 10ās of YouTube fans I did up a bit of a rant as to the difference between in-place and root motion from the perspective of an animation content creator.
And yes it matters
Why would I want to give presentation layer any control over game mechanics ? There are very few geneers where it makes any sense (fighting gamesā¦ and their variations).
I want player to move forward when pressing any button, but I will never let the visual decide how to do it. Underlaying controller logic should be responsible for driving all visuals. Never other way around.
Well you would not but someone that does not know how to code working with blueprints might. Also to consider is the Unreal 4 engine can be used for other purposes like NASA simulations or to have digital people walking around a Vis environment or even giving a director a digital camera. There are 101 other uses of being able to plug-n-play both animation and control input that does not need the muss and fuss of a movement component.
But
Animation is just the changing of parameters over space and time that can be modified as to output requirements base on hard coded needs but out of the box RM fixes the constant velocity problem of grounding the animations as to where it should be.
Not to worry though itās not going to replace the responsibility of the coder, like motion capture has changed the need for animators 
, but with UE4 Best Practice would be to provided the high fidelity, or production quality, asset and then make it do less as to output requirements. After all you can flip a switch and tell UE4 to ignore Root Motion animation.
In other words if someone down streams bonks my animations then itās their fault.
P.S. Oh the the number one reason why Root Motion is the future as to video game production is MoCap, done as RM, can go directly from the mocap lab directly into the game engine bypassing the need for processing as to in-place requirements. HUGE cost savings to be had.
Hey guys, I have been reading all the posts hereā¦ It seems that people want to achieve basic movement with Root Motion which is really not what itās meant for. Root Motion will cause things like walking in place when walking against an obstacleā¦ And having animation driven by capsule velocity really gives great results. That being said, I find myself having to use Root Motion (unfortunately over the network too) for things such as ledge climbing. Epic forces Root Motion to function over the network on montages only which makes perfect sense since the latter are used mainly for one-shot animations.
My main problem is making complex moves that need to move capsule from point A to point B without Root Motion (cause point B can be at different distances from point A) and have that working over the net without causing dozens of corrections. An example of this is when a player jumps and ALMOST lands on a platform and you assist him with a capsule adjustment.
I have been using Move Component To but this is obviously hacky since I need to switch corrections off and turn them on once the movement has been accomplished.
Does anyone know how to achieve good results with these kinds of problems?