Rifle Animset Pro

I know this is not Unreal, but the animations are same ones, so it doesn’t really matter.
Anyway, you can see that there are 2 critical angles (145 and -35 deg.), where feet actually intersect a little. I thought it’s not as visible, as in walking and running animations, so I left it like that. You know, there will always be some intersecting at these 2 points in a blendspace, you can only try to minimize it. Or you can make a double blend system that shifts the hips when the legs are apart, but that’s pretty complicated.

…but I’ll make the -45 and 135 anims anyway and update the package, when I have a little free time.

Fantastic!

Thanks a lot!

Also, I see you have an “Rifle Crouch and Prone Pro” pack as well - will you be moving this across to Unreal as well?

It’s integrated with Rifle Animset Pro for UE4. So you already have it, if you bought the rifle pack.

Btw. I just tried retargeting to different skeletons in UE4. So I took Movement Animset Pro and retargeted the animations to Mixamo-like skeleton. It works ok, but you need to remember to “Recursively Set Translation Retargeting Skeleton” on upper legs and upper arms. Epic Template skeleton has crazy proportions - really narrow hips, really broad shoulders and thighs way longer than shins. So it’s important you preserve the original translation of joints from your own model.

Video is for Movement Animset Pro, but it’s the same for all my animations.

Here’s how you do it: https://docs.unrealengine.com/latest/INT/Engine/Animation/RetargetingDifferentSkeletons/index.html

Hey guys, I made a quick video of how to build a movement Blendspace for Rifle Animset Pro (as an answer for an e-mail). I’ll post it here:

Also a word of explanation. The top speed (600 in this case, though it should be like 900, but whateva), should be achievable only when sprint button is pressed and the gamepad stick is forward. It’s like roadie run form Gears of War. The additional, doubled Run Strafes on the edges of the Blendspace, are for good blending with sprint animation.

One more thing: Why is there no Idle animation in the center? Becasue the Idle should be a separate State in your StateMachine, connected with Movement Blendspace through WalkStart and WalkStop States. Watch the Movement Animset Pro tutorial to get a better grasp on what I’m talking about:

Hi Kubold,
Prior to this animation pack showing up on the UE4 Marketplace we purchased it from your website and thought it was ready for UE4 but we are having issues retargeting to the UE4 standard skeletons. Were any changes made in the mean time to make them work that we may not have received?
Thanks,
Kory

Hi,

The pack that Epic got is the exact same pack that I sell on my page (I literally send it to them, so they could put it on the Marketplace). Nothing was changed. Also, the animations in my pack ARE baked on UE4 standard skeleton (downloaded form here: https://www.unrealengine.com/marketplace/marketplace-submission-guidelines), so you shouldn’t have to retarget anything, just import the anims using your Skeleton Asset. Can you describe what’s exactly the problem and send an e-mail to kuboldgames@gmail.com?

So: If you use Epic Template Skeleton as a skeleton for your characters, you don’t have to retarget. Just import the animations directly to your character from FBXs.

If you bought on Unreal Marketplace - Select the animations inside the engine, right click, choose “Asset Actions” and “Bulk Export…”. This will export the anims to normal FBX files. Then just import them all back, using your character’s skeleton asset.
If you bought through my www - they are already in FBX, import them all, using your character’s skeleton asset.

Hi Kubold,

Was curious as to why you don’t have any run starts & stops?

Walk starts and stops work well for running (notice, that it’s not really running, it’s more of a “tactical jogging”). Starting pose is the same, the motion is almost identical, the difference in end poses are small and disappear in the blend. In my Unity controller, I also play starting with x1.15 speed when in running mode.

Second reason is to avoid adding too much animations to the pack. It’s already 130 animations for $60. I think it’s a good compromise between usability vs. price.

Fair enough. Thanks, I’ll try that.

On a similar subject, is it true that we can’t use root motion (from everything) for multiplayer games? ie. only the ‘in place’ for all the locomotion animations?
I need to adjust all of your anims for a different weapon in maya which will take a while but not sure which set to change. I started doing the root motions then read
about the network issue and don’t want to waste time if they aren’t usable for MP.

Hmm, I’m just an animator who knows Unity’s PlayMaker visual scripting. I know absolutely nothing about network games and how it works. I didn’t learn coding from anyone, I just figure out things by myself, as I go, so it’s not a professional advice :slight_smile:

As I understand, if you are making a multiplayer game (let’s say, just 2 players), you need to create 2 instances of the same character on both machines. On both machines, both instances need to be in the same place and have the same rotation. When I move my character 1m forward and rotate him 90 degrees, my computer sends it’s position and rotation to the other computer, every frame. The other computer gets those vectors, and moves the other instance of my character, so both instances are synchronized. It also has to work the other way, because the second player could push my character on his side, and the instance on my computer should move like the instance on his computer. Now, the animations need to react to changing the position and rotation of the characters. For example, if my character translates 1m forward, the anim blueprint should play a corresponing animation, basing on rotation, movement direction and speed of the character. So, in conclusion, the position and rotation values should steer the animations.

Now, the definition of root motion is pretty much “animations steer the position and rotation of the character”, so it’s totally opposite! That’s why root motion is not quite suitable for online multiplayer games.

If you play Battlefield or Call of Duty, or even Bulletstorm and examine how the characters move, you can see that they move totally different in single player and different in multiplayer. In single player, all the AIs are using Root Motion, because it’s pretty, smooth and natural looking. It all works on just 1 machine, so the computer knows exactly where everybody is, even if they are steered by animations. Now, in multiplayer - every character uses the same animations, but in in-place versions. They are the same anims, but feet slide, they jump funny, sometimes do really strange things, because the position and rotation is steered by code, not by animations.

There are root motion and in-place animations in my sets, so you can use either this or that or mix them. If you were making something like single-player campaign and multiplayer mode, I suggest to do same thing call of duty does. Root motion for single player and in-place in multi.

P.S. Remember that in game dev, there’s never “it can’t be done, period”. I bet you could use root motion in online, but you would need to transfer a lot of data. In in-place animations, you just need to send position and rotation to the other instance of the character. In root motion, you would need to send the names of the animations that play right now and fine tweak the position and rotation of the character, on top of root motion. Lot of work, but I bet it can be done. But would it be worth it? Sending lot’s of data, thet produces lag, so the fast paced online shooter would have less feet sliding…? I’m not sure.

Thanks for the excellent and informative answer Kubold. This should be cut and paste directly into the intro of the root motion documentation. :slight_smile:

My game is MP only so I’ll stick with the in-place anims. But yes hopefully in future the tech will be able to handle full root motion online. I wait for that day.

Sorry I have one more question - I’m just doing the crouch for my character and noticed there are no 45’s or 135’s for either left or right. It’s looks so good in walk and run mode but crouch is not so great without those anims. I know it’s blowing out the amount of anims in the pack but it would super awesome if you could add even just the two in an update.

Thanks again for the detailed response.

How do you guys get the angles for the aim offset? I’ve tried every thing that I can think of but I never get the gun pointed where I want. My crosshairs are always drawn at the center of the screen, so I want to get the player’s weapon aimed in that direction. I tried using the delta between the actor rotation and the control rotation, delta between weapon rotation and control rotation, I’ve tried getting the look at rotation from the weapon to a point 5000 units forward on the camera’s forward vector (checked this with a ray trance, my dest vector is correct), etc. Nothing returns what I want, I frequently get angles off by huge margins and the weapon is pointed in the entirely wrong direction. It’s got me stumped. Thanks for any help.

EDIT: I was missing the obvious.

This is really awesome stuff, Kubold! Very helpful. Keep it up.

Are there plans to support first person sets for this too? We’re using your pack on our third person skeletons, and it would be great to use some of this on a first person skeleton too (I’m not sure if re-targeting would work for that)

I have some expirience with using this anumations for first person. But it is requires some work:

  1. attach camera to neck (set it to ignore rotation)
  2. use animations sources to change hands position for nice camera view
  3. use animations sources to create constraints between camera (neck) and hands (to make nice-looking hands movement while moving)

Hi, I’m having an issue with the aim offset blend space. When I try to blend from CC to D (straight ahead to straight down), the left hand moves away from center. The hand position at CC and D are fine but when it interprets between the two, the hand position is off. Hopefully these pictures explain it a bit better. Any ideas on how to fix?



[QUOTE=ToxinGaming;463475]
Hi, I’m having an issue with the aim offset blend space. When I try to blend from CC to D (straight ahead to straight down), the left hand moves away from center. The hand position at CC and D are fine but when it interprets between the two, the hand position is off. Hopefully these pictures explain it a bit better. Any ideas on how to fix?

This comes from the fact that Blendspaces use FK animation. This kind of stuff is usually solved by using IK on left hand.

Check out the skeleton structure:

ef61e814e4c7fc089d9bcd52d8e715a738380c58.jpeg

The white lines coming from the root, going to right hand and ending on left hand is an Unreal IK rig. Find the bone called “ik_hand_l” and snap the left hand IK effector to it. The hand now will always grab the gun barrel correctly.

I also recommend using IK on the right hand too. Both IK bones are parented to ik_hand_gun bone. If you snap both hands IK effectors to their apropriate IK bones, you can now very precisely aim the gun by rotating the ik_hand_gun bone by code. You should do that on top of AimOffset Blendspace, not instead.

Thank you so much! I haven’t dealt with the IK stuff before and was wondering how the snapping worked.

I will try this tonight after work.

Sounds exactly what I’m trying to do. Tried with FABRIK before or after the aimoffset in anim-bp … but it seems it always ignores anything and just uses FK - even with the UE mannequin and even if I use some pretty strange effector transforms values that should show at least something (so I think it does not apply anything). Somebody have a BP-screenshot or knows a tutorial regarding that?

In your animation BP, you will need to break down your animation pose into its component and then apply the Two Bone IK node

What I actually did was set the IK bone to the left hand bone and then change the Effector Location Space to BCS_BoneName and then set the Effector Space Bone Name to the right hand bone. Then I was able to just place the left hand where it properly needs to go and it will always be in the correct position. The reason I do this is to make sure the left hand doesn’t drag a frame behind when it needs to be updated. I read up a lot about how people would use the Two Bone IK but then the bone movement would lag and look bad.