Mobility Pro and Rifle Pro Packs - New Updates - Mocap Online

[jtsmith]

@TheCouch;656443

The hard part was figuring that it was happening. I thought I had a bug and was adjusting speeds incorrectly. It’s easy to fix, but it took me a bit to figure out what was going on. I understand it’s mocap so it really shouldn’t have caught me, but, well, there it is.

A couple months ago when I began my current arrangement with Motus Digital (and directly) I was having issues matching speeds as well. You think it’s hard to match speeds in the rifle pack? Try the Zombie pack! As such, I asked if there was a way to extrapolate the actors velocity/speed from the mocap inside motion builder. After a couple days, was able to gather this information and put it into curves (as attributes attached directly to each animation) that can be used in code. FYI, I am currently sub-contracted with Motus to build player controllers to be distributed with the animation packs (Basic - Pro versions.) As I build these, there are several things I have been working with on to get either added, removed, or fixed within the animations. This, as you can assume, is a lengthy process but rest assured we are working on it. As the packs get updated, they will provide my example controller(s) as well as updated animations including the curves. A lot of the feedback you have provided will help out tremendously. We are currently working on updating the Mobility pack, the others will soon follow. Needless to say, the curve has been a huge saving grace to ensure no foot sliding but there are some tricks to using them, which will be evident when my controller is examined.

The turns (rotates) are difficult to work with. They are overall way too long (turn 180 is 4.5 seconds long - has 1.5 seconds of idle).

I agree, there are some lengthy animations. While building these controllers, I need to leave the animations “As Is” and try to make them look good and blend properly; not an easy task! However, as a developer, I appreciate the fact they didn’t cut everything up for us. Having the extra length in the animations can be useful depending on the type of game you are producing as well as for cinematics. It leaves the decision to the developer on when/where to trim and use the animations for their specific needs. I would rather have more than less.

Speaking of root motion, the root motion animations in the rifle pack aren’t really root motion. For URE root motion the root bone MUST move with the skeleton mesh and the root bones for these animations don’t. Interestingly your mobility pack … do root motion correctly (i.e., the root bones move).

Root motion is done correctly. I went back to the mobility pack and check some of their root animations just to confirm.

The way you can tell root motion isn’t set up correctly is to open up the URE4 editor and look at your root motion animations, both the rifle convo/mob ones. For the convo/mob ones (again, one or the other, maybe both) when the animations are occurring you’ll see a red line being drawn from the origin to the root bone of your mesh. That’s URE4 displaying the root motion. If you look at your rifle root-motion animations you can see that the root bone stays fixed (at 0, 0, 0) and there is no red line. “No red line” is a very good indicator that the animation doesn’t use root motion from URE’s perspective.

The red line you are seeing (orange when selected) is the visual display of root travel. If you look at it in Jump animations, the origin of this line is the point of jump (UE4 doesn’t do or handle root Z movements) and the mesh begins moving towards the origin and at the apex of the jump the line trails the mesh, all from the center point of the jump. One thing I noticed when moving into the mobility pack after having played with the animations in Zombie and some in the rifle, is in the mobility they ensure that “EnableRootMotion” was set to ‘True’ in (nearly) all of the root animations while in the Zombie and Rifle pack, they are not set for us. You will need to ensure that this box is checked in each of the root animations. Once you do that, the mesh will seemingly turn into an “In Place” animation and no more line is visible. However, to prove that the root is in fact moving with the animation properly, keep “EnableRootMotion” set as ‘False’, select the “root” bone from the Skeleton Tree then play the animation. You’ll see at that point that the root is in fact moving with the animation. For further clarity, go to ‘Show -> Bone -> All Heirarchy’, you’ll then see all the bones that are connected to the root bone. And for final clarification, with the root bone selected, the 3D translation widget, which is connected always to an objects origin whether static mesh or skeleton, also follows along with the animation at the root location.

In the following image, you’ll see that I got the “red line” to show using the Rifle animation W2_Jog_F_Loop. While I didn’t test all of the root motions, I feel comfortable is saying that they all (or at least nearly all) have proper root motion set on these. If you find any that truly don’t have root motion on them and they are marked root motion (as you found with some of the IP animations) then let know and he will surely take care of it.

–