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

[TheCouch]

Sorry for the delay, I didn’t expect a response so quickly! As I mentioned, I really like the package.

Pretty sure I’m following you. To be clear, the non-L/R animation transitions are typically legacy originals we left in. They are “as is” captured motion of the actor naturally coming to a stop or jumping with no limit for number of steps for beginning or end in consideration of user input, exactly what was naturally acted, more appropriate for a cinema or truncating as you wish. The L/R ones are mostly truncated versions of the long ones, so they are not unique in that respect. I believe we did go through and pose/speed match the end of most of them to the cycle FWIW. I know there are some that look not as spot on as others.

Yeah, once I latched onto the lu/ru animations I didn’t use the non-lu/ru animations, except where there weren’t any. Backwards could really use them too (hint, hint).

Oops, that’s a mistake. Which ones?

There were at least two. I’ll have to check when I get home. I’m almost sure that one of them was the “idle to forward relaxed” ip animation.

Tru nuff, it was mocap and the actor did what he did. We tried to match things up pretty good.

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.

Not sure all specifically you are talking about, but yes definitely a number of specific anims are missing. The packs have grown considerably and it is still hard to include everything.

I’ll bet. As I mentioned URE4 is really(!) good at blending between different poses so I don’t even think these animations are necessary. At first I used them and thought “Hey! Some are missing!” then I realized that the URE blends looked almost exactly the same.

Dandruff problems? 3 frames (0-3) is bad/a problem? First I’ve been told but cool. Is 1 frame(0-1) what you are looking for? Honestly we initially used another very popular developers packs as an example of best practices, and 3 frames was there. No problem future updating our packs with 1 frame if that is a better universal fit. And the 45s with 90s missing were there too. No problem creating/providing the LRupdn 90s as I mentioned.

Creating an Aim Offset

Pretty much what that says. There’s really no reason to include anything other than one frame (but I don’t think it really hurts anything other than maybe some perf). Also I don’t think you need aim45l/r/u/d. I think you only really need aimLU90, aimU90, aimRU90, aimR90, aimRD90, aimD90, aimLD90, aimL90 and aimCenter as URE will do a great job of interpolation between the aim points (technically you probably don’t need aimCenter, but it feels weird without it). It’s okay if the mesh is distorted when doing lu/ru/ld/rd90 as most developers aren’t going to let that happen anyway (e.g., they’ll rotate the root). It’s the interpolation that’s important.

Yeah the current turns were captured pretty relaxed, cinema realistic but not so good for consistent crisp game play. And YES, no continuous turning! Nate brought this motion up with me, wasn’t sure exactly how it should be animated, but basically a continuous loop of them stepping an in-place circle. Definitely on the addition list.

I had to fiddle with the turns quite a bit to get them to look reasonable. Again, I know it’s mocap so it’s not reasonable or feasible to be precise (stupid humans with their stupid imprecise movements!). But cutting down on the idleness would make them easier to work with. And yeah, the continuous turn would be really helpful. (I actually stood up in my office to see how you could record that and you’re right - it’s not as easy as it sounds!).

Okay that doesn’t sound right or make sense. Unless, okay a couple of the fidgets he steps out of place and turns which incurred a moving root versus a stationary one. The IP versions of all animations were created by removing the animation on the root, another paradigm we used from another popular content creator. (the RnD in progress is using custom attributes derived from the root motion to recreate the correct movement and speed blahblah) So, yeah they are going to look weird/wrong with the root deleted, that’s my thoughts, we will check into it more…

I think the problem here is the IP animations for fidgeting end up with a lot of foot sliding. I was trying to give some sort of diagnosis for why this might be happening, but like I said, it’s tough to explain. Interestingly enough the “root” animations are (almost) exactly what you want for this since you don’t want your character’s feet sliding around.

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 and/or convo pack (one or the other, maybe both, I don’ recall) do root motion correctly (i.e., the root bones move). I think I understand what happened here. Root motion in URE is much less about foot sliding and much more about moving the skeleton mesh’s collision capsule (another mesh), specifically, keeping the collision capsule wrapped around the skeleton mesh. It just so happens that the way that Epic did this had a very happy side-effect of solving the foot sliding problem at the same time (I’m sure they intended it to do so - it’s really quite clever). Keeping that in mind, here’s what I think happened with the rifle animations. When I’ve animated characters before (I’m no animator and certainly no expert in this area BTW) one technique that I’ve seen used to prevent foot sliding, particularly with animation loops, was to have a root bone that stays in place while the rest of the mesh+bones move in the desired direction. When the cycle is complete the root bone (which has been stationary during the cycle) would be snapped into its new location in-between frames to continue with the next cycle. This prevents foot sliding. I think that’s how these animations were done. However, that’s not how URE4 works. What it does for root motion is somewhat bizarre (but quite effective). It tracks the motion of the root bone motion and applies that motion to the collision mesh. Remember that your skeleton mesh is actually parented to the collision mesh (usually a capsule). This has the same effect as moving the root bone (from an animation perspective) for foot sliding purposes while at the same time keeping the skeleton mesh wrapped in its collision mesh. I haven’t used root motion very much because of various (and rather vague) warnings about multiplayer networking issues, but I think I have a pretty good handle on how it works. Maybe someone who’s an expert can add to this (or correct anything I’ve gotten wrong).

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.

Anyway, hope that helps. I’ll still be working with these quite a bit and will keep posting what I find.

TheCouch

P.S. Moar death animations! (crouched, aim, aimcrouch)