Hey guys,
Earlier in the year a number of expert in the area said that root motion is prob not a good candidate for player characters in a multiplayer game since you lose the prediction logic in the movement component. Secondary question though: What about using root motion for NPC characters? I would image prediction is less important in that scenario since the engine is already controlling the direction etc vs a person.
Any thoughts on this?
C
Is it worth it? Whats the benefit of root motion apart from removed foot sliding? Or whats the reason you want to go through the hassle of setting up root motion in a multiplayer game?
The movement through animation makes a big difference from a quality perspective in my mind. It looks much different to me, however maybe I need to focus on tuning the inplace animations more.
Historically speaking in-place animation in video games has always been used as a puppet in a box, as in being hot glued to a bounding box aka movement component, and it’s this movement component that controls all aspects of player mechanics regardless of what animation action is being preformed with in the box.
It’s a case of “this is how it’s always been done” and in the process has developed a reputation of dependency that coders love as it’s one last thing to worry about as far as networked replication goes. It’s the “movement” component and not the type of animation being used that has become the preference of choice that at the moment would require a HUGE amount of additional work to duplicate the network compatibility and reliability of a function in favor of high resolution animation data sets like root motion.
Being an animator the befits are obvious to me as in video games is really the only place where in-place animation is being used in favor of root motion being used for “everything” else like animated features films where being bound to a moment component would hinder the complicated requirement of more realistic movement behavior. Imagine a Pixar flic being driven by mouse and keyboard input and the difference between the two becomes obvious.
This is the reason why animators hate movement components as being restrictive as to the need to create smooth accurate and more human like animations as to timing, ease in and ease out requirements , that is not easy to accomplish in a video game due to the constant state at which the movement component moves that requires the movement to be back keyed to off set forward movement and velocity.
If you really look close at what I would consider game ready in-place animation you can see that something like a simple walk cycle usually involves the leading foot sliding back to origin to counter the constant forward velocity. A simple jump in the air requires the character to be pulled below origin and then play catch up as to the current capsule (bounding box) location and something like a simple ladder climb is a nightmare of getting he proper wight between a 250 pound character and a 100 pound skinny mini.
So
Root motion makes life easier for the animator and can see in their mind how it will look once done
In-Place makes life easier for the coder and solves the problem of it has to work and be done today.
However.
In my mind it’s just a question of time the root motion will become the preference based on provided solutions I would expect to come from Epic by doing what they are already doing of having features additions working together in combination with one another that combines the movement component features and benefits along with the non-linear human movement behaviors of root motion.
The reality it’s not a problem of just proper replication but a solution needed where whatever movement component is being use respects the data applied to the root as an offset , when needed, and until that time the only true answer is to find out what will or will not work via discovery.
P.S. Yes Root Motion makes a huge difference if your looking at going AAA
Thats some huge insight mate, thanks for that.
So yeah, if you want your game to look like an AAA production root motion is a big impact, I get that. But that obviously makes sense if you have those animators that can make all the root motion animations you need.
From what you said, In a one-man-production or a very small team of indie devs, going with root motion would be really hard if you dont have dedicated good animator(s) and a coder who knows how to implement that all correctly so that your character controller doesnt feel limited and dampened by its own set of animations. Im projecting that from/onto my own experience tho, being completely new to the whole game dev thing I tried to set up a root motion controller with kubolds movement pack. And even tho all the main movement animations worked, I found it wasnt responsive enough and my jumps didnt work out of the box since I didnt have any root motion animation to cover that. I couldve made my own clips ( experienced with maya and animation) but I was more eager to do more stuff within the engine, so I sacrificed that quality aspect and disabled root motion on all clips for the sake of simplicity. I have only been fiddling with the engine for a few weeks now in the evenings after work, but I think once I have more experience in all that character controller stuff, Ill be going back at root motion eventually.
Anyway coming back to the OP:
If you are working on a game completely on your own, Id maybe go with in-place animation as it will drag far less of your time and allow you to invest in more efficient ways to improve quality. But if you have people dealing with the animation side of things, that would make the root motion setup more approachable.
Sorry I couldnt be of help for your actual technical problem.
I can see how the need for animations as being art can create an ideology that “video game” animation is difficult to do, more so say 10 years ago, but with a power app like Motion Builder, along with someone who knows how to use it, could handle the work load that would normally require a dozen animators to preform the same tasks. The reasoning is simple that over time an indie animator already has the kit collected over the years necessary to fill in the holes as far as typical movement systems goes and can quickly retask matched sets reconfigured as to need. As you mentioned though implementation is still an obstacle as to the inability to prove that RM is a worthwhile replacement for in-place but Epic was kind enough to add “Ignore Root Motion” and “No Root Motion Extraction” to the animation BP so one can author in either RM or in-place.
Real world advice. Do not even bother with root motion, especially in Unreal. You will waste increadible amount of time for zero benefit.
Navigation system in Unreal is build around physical locomotion, and trying to bend to do something else is just pointless.
In real world scenario you probably will never notice any difference, and you will have game up and running in moments instead of months.
Not really. Been talking to AAA developers. What I said above are almost exactly what they are saying. If you have time, you go for it, as last stage of production. If you don’t, screw it.
You forget to mention, that games are interactive, and you CAN’T predict where exactly will player end up. And there are very tide time constraints, as to how much content you can produce. If I was produce on project I would tell animators “Deal with it”.
I’m in favor of producing minimum amount of content and using procedural generation/adaptation whenever I can. I rather leave animations for where it really matters (mele combat, for example), rather than something like locomotion.
Depends on game, but for game like Dark Souls, locomotion from movement component, with heavy IK smoothing, and combat mixed with root motion.
PS. Yes I’m coder ;p.
PS2. Where I work, animator even though we are using root motion for enemies, hardly can imagine how it will look in game. Animations are extremly fast, and ugly when looked in Maya/Motion Builder. But they look good in game (because they fit speed of the game).
My point ? Root motion, doesn’t really mean you will have idea how it will look in game (;, and most importantly if it will fit game mechanics.
That’s another reason why I’m in favor of short looped in place animations. I can use them more flexible, and tune them with numbers expoed to excel, instead of contantly telling animators, make it faster, make it flower, make it jump higher…
Has anyone seen Battlefield 3 knifing animations where the capsule drags the character back to where the animation started, I think it would’ve been better if they added root motion to those animations.
That is not a very good advice.
If you want dark-souls or blade of darkness melee combat, you will want root motion.
However, I can confirm that Unreal engine hates root motion (when it is used for locomotion) with passion, and was not built with that in mind.
That one can be relatively easily solved by subclassing UPathFollowingComponent. Navigation system can be easily used to drive anything, which was demonstrated by Rama in his videos.
The difference is actually huge and instantly obvious, especially when game involves swords and melee weapons. Non-root motion animations tend to look cartoonish.
Can you validate your reasoning?
Personally I found the opposite by not using state machines and drive the locomotion via blend spaces and blend by nodes.
With out writing a book I found using blend spaces and blend nodes produces much faster inputs, cleaner blends, and a lot more data driven compatible.
Excluding the need for a movement component to make things easier the question is who should own the animation blueprint used to drive the animations?
Personally I’m holding off until plug-ins is added to the marketplace, or a root motion component, as be it in-place or root motion they are still both just another data set.
Or
At the very least Epic adds a RM sample. 
I actually have root-motion controlled character in my project.
Locomotion and all.
Using root motion for locomotion requires you to create custom movement component (because root motion disables non-root-motion-based rotation, and the only way to fix that is copy-pasting UCharacterMovementComponent::PerformMovement and modifying few lines, because that thing isn’t extensible. Now, network isn’t concern in my project, but I’m fairly sure that thing doesn’t replicate.
If you do that, you’ll still have to subclass UPathFollowingComponent, because AI won’t be able to walk otherwise.
As of 4.10.1, animation retargeting system has a bug that removes all root motion from animations when you retarget them to a different skeleton.
Oh, right, and original ACharacter doesn’t even consider being possibly moved by root motion, so jumping mid root motion walk won’t preserve horizontal movement. Good luck fixing anything in ACharacter, because it is few hundred kilobytes of code in on *.cpp file.
Simply put, root motion locomotion functionality is not properly built into engine. The entire thing expects moving capsule that in some rare cases plays montage, and when you wanna go beyond that, engine furiously resists. That bug with animation retargeting isn’t helping either.
Making root motion work is very painful process in UE4. In unity engine it used to just work out of the box (unity had bunch of other problems though).
The whole blendspace/statemachine thing has no connection to the issue.
I disagree, You can still run attacks from root motion (which look like intended workflow in Unreal anyway), and have locomotion from capsule.
Is it perfect ? No. But nothing is. And I rarther have very responsive character controlls, than soo awesome looking animations (in case of Witcher 3 I curse every time I play because of root motion locomotion, it looked nice for first 2h, now it’s just plain annoying).
As I said. Attacks can be done from root motion, locomotion from capsule.
Though honestly I don’t think Guild Wars 2 for example is using root motion (due to the fact that upper body can run completely different animation than lower body, as every attack can be performed while moving).
In anycase I advice against using root motion for anything that has anything to do with Navmesh it’s just not worth the pain, to get it working.
This I understand.
The number one issue is there is no white paper or information as to the limitations or problems associated using root motion as compared to in-place when the documentation is not clear as to issues relating to practical use.
Being on the content side of things a much more clear document from the code side of things would be helpful as to understanding why my stuff will not work the way I want it to.
If anything it could be a wish list of things that needs to be fixed.
I don’t share your opinion, and that’s about it. Arguments you presented were not sufficient to make me change my opinion.
You really need to play darksouls and blade of darkness.
We tested root motion vs no root motion in unity project before we migrated, and model without root motion looks like quake 3, while adding it to combat - especially when you have precise sword collision that collides with character skeleton, not just with capsule, enabling root motion gives strong feeling of realism, and makes combat more, how should I put it, gritty/deadly. “No root motion” - feels like quake 3. “Enabled root motion” - feels like dark souls or severance.
That absolutely is not going to work with capsule movement, because individual steps matter, and it is only obvious at close encounters, when you’re locked at enemy and dance around each other trying to chop each other’s head off.
Of course, none of this would matter in anything MMO-related or when character is seen from very large distance.
Basically, if you want proper fencing and sword play in your game OR if you’re making something akin to, say, tekken, then you will HAVE to use root motion for everything. With quick moving arcade game, root motion doesn’t matter and you can use the capsule.
That doesn’t work as argument.
I’d rather have root motion work out of the box without me having to jump through 50 hoops to “kinda” make it function the way I expect.
Glad to hear it.
I posted that as feature request in support forum, judging by complete lack of responses, the problem is not going to be dealt with any time soon.
It’s a shame this conversation died.
Root motion is more relevant now that Motion Matching is a thing.
And people are talking a lot about combat abilities, which you might as well be driving from montages, however, I personally am frustrated with Montages as the only answer to root motion, because they tend to be tangled in with gameplay logic that it prevents the animation system from having enough control to decide how to articulate the character.
Besides if you’re doing motion matching, then you’re definitely not going to want to drive everything with montages, unless you somehow modify montages to only represent the action and disassociate them from the actual animation assets that’re expected to play.
I can confirm that Epic knows their root motion options suck and want to fix it but it’s just on the wish list even now in nearly 2022.
It seems like full root motion capture breaks multi-threaded animation evaluation too. That’s a shame. So, if it’s possible to revive this old thread, I’d like to know what it would actually take to do this.
Technically, root motion is called root motion, because it’s USUALLY the root bone of the character. If not it might just be 1 child away, and in that case the real root is probably not animated. This is important because, the assumption is that replication for this is hard because the server might want to be able to move a character without resolving their whole animation. And since we know it’s typically at the top of the hierarchy, to compute the motion, you could evaluate the whole anim graph with pretty much just the root bone, and this wouldn’t be that much data – ignoring everything else. There’s no space conversion cost, because even in local space the root joint is the same as model (component) space.
So, am I missing something? Is there a cost to computing this motion that would be harder for the server to do?
As for prediction, we can advance time and see exactly where root motion would bring us, especially if we limit the evaluation to the root bone alone. Many nodes could even be flagged to be skipped like all the IK nodes in your character etc, or anything that does ray-casts, so there should be a fast root calculation. Motion matching would be a huge curve ball if each pose depends on knowledge of the previous frame’s actual full pose.
Typically root motion is at least converted to a velocity rather than a position in the extraction, this way you can blend it, but you could also infer and store and blend acceleration, which you could substitute in a poor prediction model, if you don’t want to sample in the future.
From a purely computational perspective, it doesn’t seem too hard.
So, what is involved in changing the motion prediction model? Is this hard-coded in a lot of engine systems right now?
Hi.
As I mentioned earlier in this thread (6 years ago? Time flies) you can drive root motion using bunch of subclassing. The process - back then - was fairly unintuitive one.
Regarding motion prediction, capsule movement is controlled by fairly simple forces that can be precomputed far ahead, while root motion is non-linear and is based on animation movement. Although to be fair dark souls 3 somehow pulled it all off.
I’d hazard guess that it might be possible to create a ARootMotionCharacter by subclassing Pawn instead of character and rebuilding the logic from ground up. That may or may not be a lot of work. I have no project that needs something like this at this moment, so I won’t be doing it any time soon and have no additional information on the matter.