Hi I want to know if anyone is able to get Root motion working with actor Class.
It’s been unsuccessful so far, I have read that its not fully supported, sometimes it randomly works half way and doesn’t look correct other times it doesn’t work at all.
Is this feature supported yet?
Wellll lets just say root motion is not “fully” supported depending on what it is that you are trying to do.
First I’ve never used a pawn class as to the need to have an active character that needs to move as to knowing the difference between the two.
The character BP is more or less the same as the pawn class except it contains a movement component which creates a bounding box or capsule. Using in-place animation it’s the capsule that is used that allows the player to move in world space and the animation only reacts to the current state of the capsule like a puppet in a box. The capsule also supplies three key functions of collision as well as gravity as well as the required replicated information as to where the player is located in world space during network play
To use root motion you still need to make use of the character BP rather than the pawn and in the animation BP tell the movement component that root motion is being used. This will more or less glue the capsule to the character providing both gravity and collision. The need for collision is obvious but in all cases the player should always be in a state of falling so that it can find the ground using collision to detect when the player is on the ground.
A bit of info as to the difference between in-place and root motion is in-place is reactive where RM is event driven, a QT event if you will, and contains all of the necessary data as to the purpose of having the character move based on being referenced to ground and not world space as to the behavior of the movement component.
Could you use a pawn class and not a character?
Short answer yes you could but then you would have to provided the necessary functions provided by the movement component which as a guess adds at least half of the requirements and becomes even more problematic if you have a network requirement. Using a pawn class one would have to expect strange behavior in a non-typical configuration and I have to ask why you want to use a pawn instead of a character class?
Thanks for the feedback, I am aware of most of what you wrote, however here’s my situation/questions:
1 - I don’t intend to use the PAWN class for any player controlled activity, they are being used for enemies only.
2 - I need root motion on dozens and dozens (sometimes over 40) enemies at the same time in the view all performing a predetermined and pre-made animation or action sequences (some of them even instanced many dozens of times). Using character BP has been killing off performance more than necessary. PAWN seems to work much better but couldn’t get Root motion to work properly, it seemed too random.
3 - All i need on these enemy units is Root motion support and collision capsule. Don’t need the extra stuff that Character BP comes with (which i suspect are causing the unnecessary performance losses when multiplied by that many enemies on screen). And don’t let the relatively large number put you off, the scene is well optimized and arcade like, the performance only hits hard when character BP comes into play on all of them.
4 - Don’t care about any networking issues as it will not be part of the project.
Some of these units need to follow a predetermined path while being spawned as instances, I tried horrible time consuming workarounds, by importing the animation path or spline on its own (through some weird math at first since UE doesn’t allow you to simply import splines from 3d apps) and trying to match XYZ of the PAWN class Capsule to follow the trajectory meanwhile animating everything else in place (technically acting like root motion) but its a very long process in a pipeline and not ideal as there are many types of enemy units. I don’t want to draw splines for every one of these units to follow, I just need the already animated object to simple spawn and do its thing.
Should i put in a request for this? Can we have a PAWN class that can have Root motion even if it needs to bring in some of the character BP functionality in. For those who don’t need to use it can simply ignore but for those of us who do it’s a big deal to not have it in there.
Creating a custom PAWN class is something I haven’t looked into yet and i’m not sure if i need to dig into the source code which wouldn’t be a task for me personally.
Any pointers?
Humm interesting project. With out hands on we are talking theory as I’ve yet to see any proof of concept as to how RM would function under these conditions and this is the kind of stuff I’m always on the look out for. As of this date though there is not even a sample project available that makes use of RM in place of in-place so if you get something working pleeeaaasssee follow up. 
As for can it be done and still maintain performance
40 V 40 says a lot as to setting a bench mark of what I assumed is in place but might be worth reaching out to Drix Studio for guidance Getting the player moving though should be more or less the same except converting from reactive animation to event driven.
Another consideration is functions usually used with in-place do not really work with root motion so if your using a basic controller design will give you strange results. Jumping in RM for example is totally different than using in-place.
Awesome RM motion matching system.
Since RM is 100% data driven one could more or less plug in any kind of controller they wish including an AI driver.
I think that Filmstorm is a merchant on the Epic market place so you could also reach out to them.
Another resource to check out is the shooter example which already has a functional bot system so you could use it as a sandbox to test theory on a design that already works.
But based on experience is not always in the framework but what the design inherits as to what has been applied that effects drawcalls (huge performance vampire) using a character model that has way to many material ID’s not suitable for the purpose. Toss in the fact the actor needs to be dynamically light there is really no way to save performance past x max.
Just a thought.
As to a possible reason as to random result I found the use of state machines to be unpredictable as the blending state has to be set to get out of the state as a percentage. where motion matching can figure out where it has to go and how to get there with in the event graph.
Bottom line if the animation has to wait, as it does using in-place it could mess up the animation action being provided already via the RM (Kind of like stepping on the break at the same time you stomp on the gas )
Awesome premier of using RM the proper way
Thanks for the info Frankie, The RM matching video is interesting, isn’t this similar or same as what Epic did with paragon motion warping?
And yes the 40 vs 40 sample above seems to be simple “in place” mode animations.
But I guess this doesn’t solve much of my problem.
I think I will go ahead and post a Feature request soon in the hopes that Epic implements a Pawn root motion class. (what are your thoughts?)
You know I hate to nag on problems because i believe in solutions, but I wont rule out nagging on the basics, If you don’t have water you can’t make a dam.
Coming from unity this root motion was never a problem, why can’t Epic just fix these issues before they move on to other matters. Sometimes things like these are surprising.
Well you could bring it up to Epic but they already know 
Predetermined paths do not work for the same reason state machines won’t work in that root motion already provides the necessary data and the road to success is to ignore all things that needs to be done as to using in-place animation. I was able to get root motion to work by tossing out the state machine and instead used a simple logic tree and multiplexed the keyboard input.
Why RM does not work with state machines is because the state machine requires that the current state has to exit when the state changes “but” also has to wait X amount of time until there is enough frames left in the animation to blend on the exit into the next state with in the sequences of events.It works using in-place because the speed and direction of the movement component is a constant no matter what happens in the state machine as the animation is reactive. Since movement is contained as part of the data set forcing it to wait more or less tells the forward movement to continue so you would get a strange result.
Using a tree the RM animation blend enters from the beginning and uses a weight value and not a wait state so no need for exit arguments. Binding to a path will not work as well as once again speed, location, and rotation is contained with in the animation so for it to work you would need a gimble that generates the data for the RM to follow. Long way to say that since RM is data drive it needs some type of input to work and not bound or dependent on a movement element like a movement component or path.
The thing is all of the parts are there it’s just once again the lack of documentation as to implementation that is lacking
What would be of great help is a RM version of the Shooter example
we found this from a post which has a similar problem:
https://forums.unrealengine.com/deve…rom-characters
But it means to temper with the source code and compile things…
Will give it a try perhaps.
Its totally fine to have the animation blend from one root to another and take its time especially when its enemy units in this case, because then it will be like having the intended predetermined animated sequences which is exactly what we want. So it doesn’t have to be super responsive to player actions, it just has to look right in terms of animations as well as reduce extra workarounds. should just spawn and move in space exactly as it was animated in the 3d app as a blueprint.
I’ve been browsing around and it seems that this problem comes up everywhere and people have been asking for it since 2016!
We tried the code, wont work, crashes UE…
I’m not sure if there are documentations out there to help create custom classes with root motion?
I also posted in the feedback section, not that i’m counting on it that much…
Can always slap on a sphere/capsule collider and replace the root, and add a floating movement component and get creative
I looked into it, unfortunately it’ not what i’m looking for, I need the root data from an already animated object, plug an play just like in character class, Also the title of this thread should’ve been “actor and pawn class” more so the simple actor class as that’s what i need to use with root motion.
I’ve asked nearly everywhere but no one has bothered to reply yet, I’m surprised this hasn’t come up more, it seems everyone just uses character class actor for all root motions, but this is needlessly resource intensive with almost 80% of its features being unused in case of AI or custom opponents.
Was hoping someone would point to a custom C++ root motion component creation to apply in the actor class. maybe that’s the way to go?
I know it’s an old thread, but it’s still an issue in current versions, so I’ll post a quick reply.
I use “false” root motion for my non-Character pawns. It’s not quite as automatic as real root motion, but it gets the job done. Inside the animation montage, I create separate Anim Curves for the requisite movement axes (usually ‘y’ and ‘z,’ using the pelvis as my reference bone). Then, I set the animation asset to ‘Root Motion,’ so it no longer moves off its root. Then, inside the Pawn’s event graph, I use the curve values (Skeletal Mesh → Get AnimInstance → Get Curve Value) to drive the Actor’s location while the montage plays. You can get collision by checking the ‘Sweep’ option, and if you want the montage to stop when you hit something, you can set up a STOP event from the Hit Result off of the Sweep. It’s a bit fidgety to get it working the way you want it; you’ll need to fiddle with the montage blend values most likely to get it looking right, but it does work.
This would be a nightmare setup in a production and loads of other question marks when it comes to root motion blending and animations on complex units.
We ended up modifying the class in C++ and adding root motion that way. It worked just fine for the requirements. Although we didn’t test it extensively since but if its working then its working I guess.
Why isn’t this done by default as an optional class by Epic is anyone’s guess. We wasted a week trying to sort out this solution, that is a week wasted from production!
Why is Root motion dependent on AI controller? How is that a thing? Why do you need to enable AI controller for root motion in order for it to work, further hindering performance, also why do we need to have character class (the heaviest of classes) to animate a simple pawn in root motion?
We gained so much relative performance by getting rid of character class entirely for such setups and creating our own C++ pawn class with root.
I don’t understand some of the choices Epic makes sometimes, I say this genuinely, I honestly wish a dev can jump in here and tell us why such choices are made, maybe there is a hidden catch we don’t know of?
Anyway hope this helps you.
Place this in your actor’s tick:
Thanks for posting that!
It doesn’t work for me, though. I keep getting an undeclared identifier error for ‘SkeletalMeshComp.’ Must be an engine version issue?
Anyway, my project doesn’t use enough root motion for it to be worth messing with!
Yes I remember an issue like that,
I think what is happening is that the code is trying to find a skeletal mesh component that is applied by default (similar to the character class).
I think we fixed this by force adding a skeletal mesh component inside the Actor or Pawn classes and make it a default present component so the code can find it immediately.
Unfortunately I don’t have it rigtht now to show you.
Good luck.
Okay yeah, that probably should have been obvious to me! I was taking Myxa’s instructions maybe too literally.
Yeah, so I added a skeletal mesh component named SkeletalMeshComp in the header file (and, for good measure, a call to “Components/SkeletalMeshComponent.h”) and it compiled fine, and the code does work exactly as advertised. I may need to reconsider some things on my project now. I’m not far enough along that it may not be worth it to retool how I’m handling my pawns, if nothing else because you never know what might come up later on. Hmm…
Thanks again for sharing the code! I’m sure this’ll be a big help for many frustrated programmers!
Glad to hear it!
Yes this is definetaly the way to go we saw a substantial performance increase using this method vs having all characters that require root motion to be forced with getting stuck with the heavy and very much bloated “Character class”.
We hope Epic implements this by default in the engine.
How is the character class bloated?
I think you mean the movement component…
Yes its got physics and a whole lot of things in it. If you have a dozen enemy units that need root motion and dont require the movement controller you can see how much wasted the whole thing is.
Even if you turn things off to a degree it just seems to be running something in the background that is not necessary.
There’s a lot of functions in there, that’s for sure.
But this is also because it’s network replcated.
Also, not entierly sure removing the code or disabling the ontick of it with an override would change much performance wise with 10 enemies on screen plus AIs, plus rendering.
Would CPU times change between 10 character classes and 10 Pawn classes with the exact same behaviors?
Maybe not on 10 characters but more did have a performance gain.
Being network replicated is a fair point, however what if its not being used with AI or for player control/networking, then having character class being the only class out fo the box to support root motion with all the extras in it makes little to no sense.