• News

• Industries

• Learning & Support

• Community

• Marketplace

# Kind of about networked root motion, more philosophical

So here is the thing about root motion and networking: I don’t understand how it isn’t implemented already.

I understand that hard numbers are more reliable than the progress of an animation, but why can’t we separate a loop movement animation as its own type that can be baked with movement data. The main reason I’m talking about this is because I think the solution is simple and straightforward. But let’s get to the problem.

What works in networking? Movement speed, regardless of anything else. But it only looks good if you can approximate the movement speed to the steps of the animation, or it otherwise won’t matter.

Example: A drunk walking animation, or an injured leg animation. There is no way to realistically animate it on a network as things currently are, while keeping fidelity to the appearance of the character moving across the screen.

So now to the solution: being able to choose the start and end points in a loop, and then have calculations that bake and record the movement. It takes note of the starting vector of the root at the start of the loop, as well as the vector of the root at the final frame of the loop. It will also record the total amount of time it took for the whole loop. Boom. You have distance over time. Speed. Now it will also record the difference in speed between the root animation’s local vector comparatively to where they are supposed to be if approximating speed*totalDelta. That data can be stored with the animation. Now all you have to relay is the speed for the animations (which should be baked in), but the server can relay whatever replicative variables and the location of the deltas made so that a person can better approximate where they are. Granted, uneven movement is a pain because it’s uneven, but this should be a simple solution. Even if you have animations that are used in the form of 1D/2D blending animation, if you have the speeds, the time, and delta distance, and whatever variables needed for those blending animations to blend, you should approximate where they are pretty accurately.

Now a problem obviously is ping time and synchronization. That’s why keeping track of input changes becomes important. Solutions such as smoothing within a certain range, anything out of that range just snapping, etc are still valid techniques that will help tremendously. So will sending the location of the person making the delta as well as the client’s location, upon the server receiving any kind of input update that would affect the client’s velocity. Once received by the client (who will be keeping a buffer history of their locations on their own computer), it will approximate the time distance of the update with their location to find out how long ago the player was at X point in the buffer history, then calculate the difference and make the adjustments depending on whether they are close enough in synch that it can just show the changes with some smoothing but keep track of the new (approximate) acceleration/orientation/direction.

I’d like for this to be a back and forth discussion, so let me know what you guys think, including criticisms on the entire theory.

Well in theory Root Motion is nothing more than just another form of input that just like a joystick, keyboard or mouse, and could be used to reshape the output even over network but at the same time retain the original fidelity of the original. The best of both worlds as all things involving animation is based on RM… except video games.

Understandable there are issues relating to network play but is not the root of the problem, pun intended, but rather the lack of proof of concept that it’s use in both single as well as network play is a better solution over and above what has been tested over years worth of games development.

It comes down to.

Animators and content artists love RM because it maintains fidelity
Coders hate RM because it means more work to make it work as well assume that some how it takes their ability to control game speed and physics away (their version of mocap )

What it will take to get past the wall so to speak is proof of concept, as well as a RM movement component, demonstrating a full out network compatible mini game so that how it can work could be proven with out having to put in the necessary R&D over and above what has already been proven to work.

After that I could do pages of why I prefer RM over in place but the best is the player will always be grounded, which seems to be a word use that I always have to explain

Networked root motion is implemented already. And it works. http://www.casualdistractiongames.co…E4-Root-Motion

Remember, with root motion, you already have the desired movement on both the client and the server.

And in both RootMotion and non-Rootmotion you still have to reconcile position when the client receives new packets from the server.
(You can still reconcile deltas in the same way for both)

So the only difference between RootMotion and non-Rootmotion is that in between these network updates, the client either determines motion algorithmically(by running code) or via root motion.

That RM does work over network is not the issue in hand. I’ve been saying that since forever as it’s the event that has to be replicated, but rather the lack of proof of concept in playable form, as in a Shooter Example done 100% using RM. It’s about sticking with what has proven to work, just like the space shuttle still uses tech from the late 60’s.

Cool - I thought OP was unclear whether it was implemented/supported in UE. To be clear there is direct support for it in Engine Source - I have used it on several projects and played with friends - even with lag over east coast/west coast/canada.

If you are looking for a sample project let me know - I could package up a demo to share. Might be cool to have a reference and use Steam too.

Well I don’t think the OP is about it being there or not but more of a case of why is it not used as the standard even over network which seems more philosophic as to not finding solutions to whats a better tech as comparing a solution known to work. If you can make a project available to fill that hole it would go along way considering there is not a single example available that I know of.

The trouble with networked root motion becomes apparent when a root motion character needs to interact with something in the environment in some way. Since every client only has an approximation of what that interacting player sees, coupled with (in animation terms) a fairly significant delay, it’s really quite hard to get behaviour to line up nicely.

In a traditional system we can interpolate the interacting player on the client to where they need to be, and speed up / slow down the interaction animations; usually nobody will notice since the movement and behaviour drives the animation, so it still look smooth. When you do this with root motion, there’s no way to avoid that character sliding around or snapping to things, which looks pretty disjointed and is highly undesirable.

Sorry you are having troubles getting it to work with environment interactions. One idea if you are having trouble with things like grabbing a door or pushing a button, perhaps you should couple it with some IK targeting. Another thing to keep in mind is that the animations need to be split up into short re-usable generic pieces. E.g Swing left, open door, run cycle loop, etc… The longer the root motion clip, the more chance for it not to be in sync with the incoming authoritative packets.

FWIW - Networked root motion works great for me for what I have been working with. I may try to put together an example project for download…

Any chance you did set up an example project?

My answer is. Forget about root motion. Spend some time to implement proper motion technique. Like Motion Prediction, Motion Matching or maybe even some from the real of Machine Learning (like Phase Functioned neural networks for motion).

The investment time will be bigger at the begining, but in the end you will have much higher quality animations, with higher variety with far smaller content size (since lots of motion will be generated procedurally). Those animations will be always perfectly synced in multiplayer (under heavy network conditions).

Root motion might be easier to start with and might be even easier to work with at the begning, but in the end it is night mare to maintin and iterate upon. DON’T DO IT.