Mobility MoCap Pack 1 - 136 Mobility Motion Capture Animations

[Motus_Digital]

Hi all,

Our Mobility 1 Pack is on the Marketplace! It’s a large set of animations to get your character moving around in various ways.
Includes: Standing, Crouching, Idles, Fidgets, Walks, Jogs, Runs, Jumps, Hops, Turns, Transitions, Deaths and more.
https://www.unrealengine.com/content/b5afb033c1ae4795b92fad262f10a2cb

Full motion list:
https://goo.gl/5oZvul

Video here:
https://vimeo.com/129670657

The video contains all motions in the pack. In place motions are not shown specifically.

This is the full pack, we will be offering it broken up into small packs on the Marketplace as well asap. You can see the current smaller sub-packs on the website: http://www.motioncaptureonline.com/#!mobility-01/c14i9

Please tell us what you think! We’ve got Rifle, Pistol, Boxing, and Zombie in the pipe for approval as well. We’re working on porting our whole library to UE4, so please check out our site http://www.motioncaptureonline.com/ and give us some feedback. We are still working on breaking up Ninja and Zombie into smaller packs.

[Allar]

Can’t wait for the rifle/pistol packs. Am very curious to try out root motion with my Generic Shooter project.

[anonymous_user_d0996dd8]

I just purchased these and am very disappointed. The description says “locomotions are included as travelling root motion and in-place loops”. However the root bone does not move! I expected the root bone to translate along the floor as per Kubold’s animation packs (Movement Animset Pro - [Submitted] - Marketplace - Epic Developer Community Forums). Unless I am mistaken this makes these animations useless for UE4 when doing root motion animation. I just wrote Motus Digital an email informing them of this problem.

Warm Regards,

[Motus_Digital]

@;324274

I just purchased these and am very disappointed. The description says “locomotions are included as travelling root motion and in-place loops”. However the root bone does not move! I expected the root bone to translate along the floor as per Kubold’s animation packs (Movement Animset Pro - [Submitted] - Marketplace - Epic Developer Community Forums). Unless I am mistaken this makes these animations useless for UE4 when doing root motion animation. I just wrote Motus Digital an email informing them of this problem.

Warm Regards,

Hey ,

You are honestly the first person I’ve ever heard make that comment/complaint or assertion.

I have always heard folks for a long time use the term “root” motion as meaning the hips/pelvis/whatever you would call it actually moves/travels in space in a normal fashion, this is what Unity calls “root” motion; versus an “in-place” motion which the hips/pelvis fundamentally stays in one place except for its secondary motion, so moving the reference/origin node (UE4 names this “root”, confusing yes) at a linear speed in the correct direction adds the travelling movement and the animation appears normal and connected to the ground. For in-place motions, scripting’programming whatever needs to tell the reference/root node to move accordingly in context, am I right? For what is called “root” motion typically, programming needs to track the location/rotation of the hips/pelvis directly to calculate movement and blending into other travelling animations etc.

I used to just call them “travelling” and “in-place” animations. The term “root motion” became common and folks would ask us about it and that’s what they always meant (We have been talking to a lot of Unity users…), normal travelling hips/pelvis motion. If UE4 has a different definition/use of these terms it’s news to me, but hey I don’t know everything, I’m not a Unity or UE4 Jedi, educate me. I’d welcome anyone chiming in about the current and correct use of the the term “root” motion in UE4 specifically.

The provided motion list has the correct 1:1 linear speed of each “in-place” motion notated, so one could key frame the reference/origin(UE4 root) node in Persona at frame zero and the end to create the root motion as you describe it I suppose.

No deception intended, I’m all ears if anyone wants to discuss/comment on the use and correctness of these overlapping terms/words/programs. If consensus is our verbiage is incorrect usage we’ll of course change it. How a bout “travelling” and “in-place”?

[anonymous_user_d0996dd8]

Motus Digital have kindly (and very quickly I might add) responded to my emails about the above issues and I am working with them to sort them out in UE4. I’ve decided to leave our discussions private for now but will post back here with any status updates as we progress through the issue.

[Bionic_Ape]

Hi, I just bought this and I thought it came with an example character with all the blend spaces etc.

Is there any place that I could download this?, or a tutorial?

Cheers,
Bullyproof

[BlackFangTech]

Did you ever fix the issues with root motion being absent? Root means the very first bone in the heirarchy, usually also named “root”. Motion on the hips is indeed totally useless to UE’s root motion system.

The animations look very good, and most of the time I would be using in-place versions, but it would be great to know that root motion was an option.

[BlackFangTech]

I bought this on flash sale and it is even worse than had been alluded to here. I am currently considering contacting EPIC for a refund as the description on the marketplace is totally inaccurate.

“All animations are on the UE4 template skeleton with IK bones. Locomotions are included as travelling root motion and in-place loops.” *******s.

Because nearly all animations in this pack are locomotion, I expected 136 unique animations, with a root-motion and in-place version of the majority.

Nope. There are 136 animation files in total.

Not only do NONE of the animations have proper root animation, instead moving the pelvis bone all about, they don’t animate the feet and hand IK roots either. They are totally useless to UE’s root-motion system. They are not viable for characters, nor NPCs, or even cutscenes as the model will snap back to where it started after each individual animation. Even if that were not the case, they would be useless due to the lack of proper translation on the IK roots, so your entire IK systems will be utterly nonviable with these.

Removing all of these useless animations leaves you with 40 in-place ones, making this an inferior and overpriced version of the Movement Animset Pro pack.

They might look nice in screenshots, but don’t be fooled. The best evidence I have points to the conclusion that Motus Digital products are rushed port-jobs done by someone without the necessary Unreal Engine experience. They are useless to game development, and are bloating the marketplace with low-quality garbage.

I am shocked this managed to get through EPIC’s testing process. I am also disheartened at the rate new packs from this author are being added, as the author has shown no sign of being willing to fix or provide proper support for this content, instead offering excuses.

[Motus_Digital]

Okay, this is really messed up and embarrassing. We’ve got some serious apologizing to do, please read all.

Our email notifications of posts are apparently not working as we totally missed the recent posts starting with Bullyproof on 8/12 and BlackRang666 on 8/22, our Zendesk is bouncing the notification emails and this needs to be ffing fixed.

If I had seen these I would have immediately responded and sent BlackRang666 the fully implemented Mobility pack with full root motion in final testing and apologized for Epic not updating the description verbiage as I was informed they did right after and I started the dialogue, and I swear I saw the change and it’s back to the old verbiage(?). Actually, I bet the listing goofed and reverted back to the old description when they put it on sale.

I have been working with constantly and other buyers/developers that contacted us directly on implementing full root motion with great success, and adding other animations such as different types of strafing 45’s, split up jumps with in-air loops, etc.
has been very busy as well and never reported back in on this thread, as neither did we as there was so much great feedback as to improvements/tweaks/additional animations to fill out the pack that we didn’t have a super clear list of updated/added motions etc. and didn’t want to speak prematurely. So I suppose this backfired as well.

Add insult to BlackRang666 when we inadvertently “ignored” his post with kind words about our animations and inquiry as to what was up with the root motion progress, and he is now irate saying we suck, are apathetic, and our stuff is “low quality garbage”. Ouch. Dude, we cannot apologize enough for missing your posts, we would have totally hooked you up and WILL totally hook you up now. We get direct support emails but the forum notifications are bouncing, we need to fix it.

Quick note about Epic submissions, I will not bad mouth Epic, but I will say that any repeated questions about default inclusion of root motion with all packs has had no reply at all, seemingly a no comment stance. I guess they want to stay out of it and let the Marketplace decide(?).

Back to the root motion topic.

We do have a root motion version of Mobility_01 which we can share with current buyers before it is 100% locked down and an official update on the Marketplace, which takes time. It has some extra motions as well to test out, as we appreciate the beta feedback we’ve been getting from others so far who have contacted us directly at our support:
mocap@motusdigital.com
Please contact us directly and we will hook you up.

Rifle_01 is also about done with root and other added animations, Pistol_01 is partially done. All these moving forward will be free updates pushed to the Marketplace. All our packs will be getting root motion updates as well at the very least.
Honestly I have been working relentlessly with and these other fine folks to implement these updates since Steve’s first comments, as to be more complete when compared to another animation seller on the Marketplace whose work and packs are very good indeed. It is a lot of work, so the official updates will happen as soon as practical. We pulled any mention of “root motion” from all packs so we could figure out our update strategy, and of course we missed Mobility, damage control and hara-kiri again.

PMBullyproof, no it doesn’t come with any setup blendspaces and only the UE4 SK_Mannequin. There are lots of tutorials online about UE4 setup and retargeting. We are looking at including an example blendspace and blueprint.

Generally we respond quickly and really like to work with those who contact us, others will hopefully testify to this at some point, and other than growing into UE4 specific tech specs all have commented our motions look great and we just need to fill in some blanks and add root motion etc. Hopefully BlackRang666 will forgive and give us a chance to make it right, and revise his scathing review. We are accustomed to working one on one with developers and delivering to their desired specs in all sorts of engines, catering to one Marketplace with generic animations for all users is a new paradigm for us, constructive feedback is essential. This has been a real black eye, please contact us directly and we’ll make sure current buyers get the updated pack now if they want it.

Best,
Cris

[thankstipscom]

@Motus Digital;372760

Okay, this is really messed up and embarrassing. We’ve got some serious apologizing to do, please read all.

Our email notifications of posts are apparently not working as we totally missed the recent posts starting with Bullyproof on 8/12 and BlackRang666 on 8/22, our Zendesk is bouncing the notification emails and this needs to be ffing fixed.

If I had seen these I would have immediately responded and sent BlackRang666 the fully implemented Mobility pack with full root motion in final testing and apologized for Epic not updating the description verbiage as I was informed they did right after and I started the dialogue, and I swear I saw the change and it’s back to the old verbiage(?). Actually, I bet the listing goofed and rev…
Cris

I only have one pack by these guys and its not this one. I haven’t posted any feedback yet as I haven’t used it the way I want to at the moment. I tried a few anims out and they work fine. I believe I also noticed that some root anims dont work right. I chalked it up to me not knowing how to implement root anims properly. Ive had that problem since day 1. I’ve tried following epic guides but my char always snaps back to original position after the anim plays. I donno if its me or the anim so I don’t comment on it yet. Slight issues with my pack though is that some are “in place” anims yet they do slowly move even so. I can remove the keys in 3d software to change this and re-export but its annoying.

That aside, the animations are pretty good and I like that they go for themed packs and try to add some uniqueness but like I said I haven’t played with them enough yet, just used the few that I needed for a specific scene so far. One thing I an definitely attest to 100% is that the support is really quick. IF you email them directly, you’ll get a response that day or the next. The first reply often comes with the solution instructions but also with example files or help, providing your issue allows for it. Maybe other people tried contacting them and they didnt get their messages through. I’d hope everyone would attempt to at least contact the seller first before posting frustrations publicly, it’s only fair. I sent an email from my personal domain and it seemed to get through no problem so while I can’t speak for the root motion issues, I can say for sure the support from these guys is here, at least it was for me.

[anonymous_user_e9317a3b]

@Motus Digital;372760

If I had seen these I would have immediately responded and sent BlackRang666 the fully implemented Mobility pack with full root motion in final testing and apologized for Epic not updating the description verbiage as I was informed they did right after and I started the dialogue, and I swear I saw the change and it’s back to the old verbiage(?). Actually, I bet the listing goofed and reverted back to the old description when they put it on sale.

In this case yes, it appears that when the content was put on sale, it reverted to the old description. We’ve found the error in our process and corrected it. To confirm that we have the latest, can you email us at marketplace-support@unrealengine.com with the latest information and any updates you have so we can publish it? Apologies for the inconvenience.

Quick note about Epic submissions, I will not bad mouth Epic, but I will say that any repeated questions about default inclusion of root motion with all packs has had no reply at all, seemingly a no comment stance. I guess they want to stay out of it and let the Marketplace decide(?).

I apologize, I thought we’d resolved this quite some time back. Was this handled through marketplace-support@unrealengine.com or a direct email? We don’t do “no comment” or deliberately allow open questions like that to go unanswered.

The official stance is that it’s either-or. Neither approach is better or the other, and different projects use different approaches. I’m hesitant to require the inclusion of both because of the additional labor involved, but I think one way to help minimize issues like this is to modify the Marketplace catalog entry to indicate clearly at the top and in the technical specifications whether it’s root motion, in-place motion, or both. I’d be curious to hear the group’s thoughts on that. Ultimately all we want is to set clear expectations of what you’re getting when you make a purchase.

[Motus_Digital]

@;373149

In this case yes, it appears that when the content was put on sale, it reverted to the old description. We’ve found the error in our process and corrected it. To confirm that we have the latest, can you email us at marketplace-support@unrealengine.com with the latest information and any updates you have so we can publish it? Apologies for the inconvenience.

Hey, thanks so much for chiming in and clarifying that. At least I know now I wasn’t mistaken when I did see and confirm the changes way back. I will send you guys the updated info again to follow up.

@;373149

I apologize, I thought we’d resolved this quite some time back. Was this handled through marketplace-support@unrealengine.com or a direct email? We don’t do “no comment” or deliberately allow open questions like that to go unanswered.

The official stance is that it’s either-or. Neither approach is better or the other, and different projects use different approaches. I’m hesitant to require the inclusion of both because of the additional labor involved, but I think one way to help minimize issues like this is to modify the Marketplace catalog entry to indicate clearly at the top and in the technical specifications whether it’s root motion, in-place motion, or both. I’d be curious to hear the group’s thoughts on that. Ultimately all we want is to set clear expectations of what you’re getting when you make a purchase.

, I checked and it was direct email, not the help desk, I know they can get really busy and thought I would put such a novel question past you. You did get back to me immediately, suggested that was a question for the animation team and would get back to me when you had an answer. I followed up a few days later and got no further reply, so I figured you were busy and/or I asked a question with no clear answer. No finger pointing here, I know we all get busy and things slip through the cracks, just look at the mess I’m cleaning up now by missing the forum posts.

Yes I agree, at this point it is best to state clearly whether a pack contains root motion or does not contain root motion etc. in the tech description. This is painfully obvious from our current situation. Official updates with root motion are close to completion, but I will revise the current descriptions and update them asap.

On the subject of root or not root…
The buyers/users of our packs that got in touch with feedback and became invaluable beta testers, some are established developers, had widely varying opinions on root motion. Some assumed root motion was included even if it wasn’t stated, simply because it was for UE4. Others said they didn’t care about root motion, never liked using it, don’t want it. So a definite split of opinion. Since the users asking about it were contacting us directly and all was quiet for weeks on the forum, we decided to not post about it while we worked out the details and update schedule, and then had something definitive to post. Once again, this tact has apparently backfired and we are mopping up.

We will regroup next week and likely post about what’s in the works and where we are at. As stated before, current users can contact us directly and get the beta pack if they want it. mocap@motusdigital.com

Thanks again to for chiming in, he and his team have always been responsive and helpful with all our questions and issues.

[anonymous_user_d0996dd8]

Just thought I would chime in - I should have posted earlier. If I wasn’t so busy working with Motus Digital I would have!

Like some here I was disappointed when I purchased the mobility set as it did not have root motion. I told Motus Digital about the problem (see my earlier post in this thread) and I had a response the next day. Since that day I have been working with Motus to make all of their animation sets suitable for UE4 and their response has been nothing short of awesome. We’ve shared in excess of 60 emails, many videos, and every one of my requests has been met. Making a controller and resolving the issues does take time though.

I’ve made a video of my progress - all using root motion and some of the Motus Digital animation sets. Check it out.

[pax_invictus]

@thankstipscom;373142

One thing I an definitely attest to 100% is that the support is really quick. IF you email them directly, you’ll get a response that day or the next. The first reply often comes with the solution instructions but also with example files or help, providing your issue allows for it. Maybe other people tried contacting them and they didn’t get their messages through. I’d hope everyone would attempt to at least contact the seller first before posting frustrations publicly, it’s only fair. I sent an email from my personal domain and it seemed to get through no problem so while I can’t speak for the root motion issues, I can say for sure the support from these guys is here, at least it was for me.

I can confirm that. I emailed them yesterday and got a super thorough and courteous response that same day! They provided me with a fixed version in which root motion works very nicely. I quickly whipped up a blend space and tested it myself last night. I’ve been informed that the fixed version is going to be pushed out to the Marketplace very soon. Seriously good quality and awesome support!

[Motus_Digital]

Mobility 01 Version 2 with ROOT Motion - This Week

Hey everyone,

Long overdue update, Mobility 01 is getting a new free version 2 release this week with root motion.
It will also be in Friday’s flash sale!

Unreal Egine 4.9

Root motion!

30 additional animations; the stopping motions split up into Left and Right foot up for better looking integration into a
controller.

All stationary to moving animations end right foot up, to match the right foot up phasing of all locomotions.

All Circle (CIR) motions now correctly start right foot up.

Miscellaneous minor fixes.

Updated v2 motion list with descriptions of each animation.
https://goo.gl/5oZvul

Many thanks to and all others that contacted us with feedback and helped test them.

Sorry for the long drawn out delay getting these released, we’ve been working on so many ideas and improvements wanting to put out
the “ultimate” update all at once. Decided it best to release what we had ready, especially the root motion which users were
unhappy about being missing.

In the works:

• 45 and 135 degree strafes
• Stand/Crouch turns to walk/jog/run in all directions
• Jumps split up into takeoff/air loop/landing
• Other things…

We are planning a shoot end of the month to capture and fill in a lot of these additions and others, so please stay tuned. If there
are any more ideas for additions please let us know! Discussing it openly on the forum is cool, but emailing us directly also
helps as it gets into our help desk system and we can start an official dialogue.

An included controller is still in the works with , after we capture more motions to fill in some blanks we’ll be working on getting that out as well.

UE4@motusdigital.com

We are also updating to v2 the Zombie and Boxing packs with Root motion this week, and they will also be on sale Friday!

We also have been working hard on the Rifle, Pistol and Ninja packs. Rifle has the added complexity of a two-handed weapon, and
we’ve been trying out forward and back pedal strafing, I will go into more detail in a separate post about all packs.

Ninja is an interesting puzzle for root motion, as he flips/spins/turns/jumps/climbs in so many different and combined ways, it is
hard to decide the best orientation and/or placement of the root in practice. Feedback and advice on the subject are welcome, I’ll
go into it in more detail in a separate post as well. Feel free to contact us directly if you have experience programming or
setting up a controller with such complex animations.

Thanks again! Please watch for the updates and the flash sale tells us will be on Friday.

Cris

[FrankieV]

@Motus Digital;394479

Ninja is an interesting puzzle for root motion, as he flips/spins/turns/jumps/climbs in so many different and combined ways, it is
hard to decide the best orientation and/or placement of the root in practice. Feedback and advice on the subject are welcome, I’ll
go into it in more detail in a separate post as well. Feel free to contact us directly if you have experience programming or
setting up a controller with such complex animations.

Thanks again! Please watch for the updates and the flash sale tells us will be on Friday.

Cris

At it’s root root motion is the combination of two required components. Speed and direction. Speed is controlled by the hips effector relative to the ground as well as the orientation to the root which controls direction as well acts as the reference marker as to motion clips that will blend into and out of the current movement state.

Best practice and how I usually convert in place in MotionBuilder is to always have both the hips transform and the root at 000 for the root and 00Y for the hips (in MB Y is up) and use a parent constraint to link the root to the hips which will travel in the same direction. Once done I then plot the root as a character extension and delete the XY keys (in MB Z is forward) and the start will begin at 000 and at the end of the travel will be 00Z (A straight line). The next cycle that is played then uses the current root location to blend in the next cycle.

Best practice once again is the root should always travel in a straight line based on the origin of 000 first frame reference and if it loops the next cycle should then begin at the current location of the roots Z position and so on and so on.

Turning in place gets a bit tricky as forward, and backwards movements should always be pointing relative to the forward direction of the movement so from idle the full turn cycle should be a 360 turn to either the left or right so at any point in the turn the player can come out straight relative to it’s forward movement.

So overall the actual root is a point of reference as to actions coming into and going out of the current primary action as a starting point and used as to where the feet should line up relative to the ground and the hips translation determining the ground speed of the player.

Just saying.

[SaOk]

Superb root news, have been checking zombieanim storepage near daily. Cant wait for the friday.

[BlackFangTech]

Glad to see this update coming soon.

Root motions on flips and the like is complicated, but very important for their usefulness in a game. My best advice is for the root to always be a set distance bellow the hips in world space, and to have the same yaw as the hips, but no roll or pitch. So, in a flip, the hips would do a full spin in the pitch axis, but the root would not rotate on that axis. If the hips are 100 units above the root, and rise 50, the root should also rise 50, maintaining that distance. I hope that makes sense and helps.

[Motus_Digital]

@FrankieV;394705

At it’s root root motion is the combination of two required components. Speed and direction. Speed is controlled by the hips effector relative to the ground as well as the orientation to the root which controls direction as well acts as the reference marker as to motion clips that will blend into and out of the current movement state.

Best practice and how I usually convert in place in MotionBuilder is to always have both the hips transform and the root at 000 for the root and 00Y for the hips (in MB Y is up) and use a parent constraint to link the root to the hips which will travel in the same direction. Once done I then plot the root as a character extension and delete the XY keys (in MB Z is forward) and the start will begin at 000 and at the end of the travel will be 00Z (A straight line). The next cycle that is played then uses the current root location to blend in the next cycle.

Best practice once again is the root should always travel in a straight line based on the origin of 000 first frame reference and if it loops the next cycle should then begin at the current location of the roots Z position and so on and so on.

Turning in place gets a bit tricky as forward, and backwards movements should always be pointing relative to the forward direction of the movement so from idle the full turn cycle should be a 360 turn to either the left or right so at any point in the turn the player can come out straight relative to it’s forward movement.

So overall the actual root is a point of reference as to actions coming into and going out of the current primary action as a starting point and used as to where the feet should line up relative to the ground and the hips translation determining the ground speed of the player.

Just saying.

Hey Frankie_V,

Thanks for laying out the quick primer, I’ve gotten the fundamentals down and have a number of tricks and rigs in MoBu to animate the root automatically or by hand when more exact control is appropriate. I’ve done similar for other engines in the past. Mobility Pack is pretty straight forward as it is always clear what direction he is facing or traveling, and when he jumps it is ground to ground in a consistent direction.

For Ninja Pack things get a little cloudy and open to interpretation. For starters his default idle pose is sideways left foot forward, no prob and no mystery forward is still forward. It does get interesting from there…
Scenario 1: He turns his upper body slightly, his head backwards for a behind him elbow punch, but keeps his feet planted “forward”, then turns back to idle. I considered that root forward all the way through.
Scenario 2: He turns his upper body slightly, his head backwards for a behind him kick, but also pivots his feet a bit sideways, so he is sort of facing right now but really his body angle hasn’t changed much from the forward idle just like scenario 1. He then continues to turn 180 to the idle pose again facing backward. So the root could stay 0 deg through the kick then rotate R180 deg for the turn to backwards idle, or rotate R90 deg for the kick then rotate 90 more deg for the turn to backwards, which looks more like the body is turning a full 180 deg from that point not 90. Or…? It’s a matter of interpretation and what would look/function best in-game if for instance he we’re interrupted during the punch by a hit, so he would react/fall the correct relative direction playing the appropriate animation.

These two are just a simple tip of the iceberg and far less complex than other combination moves…

@BlackRang666;394833

Glad to see this update coming soon.

Root motions on flips and the like is complicated, but very important for their usefulness in a game. My best advice is for the root to always be a set distance bellow the hips in world space, and to have the same yaw as the hips, but no roll or pitch. So, in a flip, the hips would do a full spin in the pitch axis, but the root would not rotate on that axis. If the hips are 100 units above the root, and rise 50, the root should also rise 50, maintaining that distance. I hope that makes sense and helps.

Thanks for bringing that up, flips another example. For a straight forward tucked flip I have the root facing forward the whole time, so even in the middle where he is technically upside down facing backwards, game play wise he is still considered facing and traveling forward. A hit from neg X would potentially play an animation of him falling to his Left to pos X as if he were facing forward when hit. Make sense?
For vertical movement I’ve heard the consistent distance below the hips notion, but was advised more importantly to make sure when the feet need ground contact/collision to keep it at zero, and to animate it vertically to the bottom of the feet so he clears vertical objects appropriately.

Of course following the “rules” is all well and good but what it looks and reacts like in context is what’s important, that’s where getting beta testing and input by users is essential. If I was working with a specific developer I’d be getting input and feedback from the programmers and designers, in this case the Marketplace and all you fine folks are the Developer(s).

This is great and needed conversation, but posting some videos of what I’m doing would be worth a thousand words or pics understanding exactly what I’m doing and what it looks like in action. I will make some videos to share. I am barely scratching the surface of these wildly varied animations, I think it would be best to move this conversation over to a dedicated thread on Ninja root motions and get more in depth, get more in depth feedback as well. Agreed? Would “Animation” in the Development forums be a more appropriate place?

Thanks to everyone for chiming in.

[FrankieV]

@Motus Digital;395195

For Ninja Pack things get a little cloudy and open to interpretation. For starters his default idle pose is sideways left foot forward, no prob and no mystery forward is still forward. It does get interesting from there…
Scenario 1: He turns his upper body slightly, his head backwards for a behind him elbow punch, but keeps his feet planted “forward”, then turns back to idle. I considered that root forward all the way through.
Scenario 2: He turns his upper body slightly, his head backwards for a behind him kick, but also pivots his feet a bit sideways, so he is sort of facing right now but really his body angle hasn’t changed much from the forward idle just like scenario 1. He then continues to turn 180 to the idle pose again facing backward. So the root could stay 0 deg through the kick then rotate R180 deg for the turn to backwards idle, or rotate R90 deg for the kick then rotate 90 more deg for the turn to backwards, which looks more like the body is turning a full 180 deg from that point not 90. Or…? It’s a matter of interpretation and what would look/function best in-game if for instance he we’re interrupted during the punch by a hit, so he would react/fall the correct relative direction playing the appropriate animation.

Yeah it can be tricky to try and guess the implementation of what would be a much more complicated character combat system but once again the primary action is not much of an issue as compared to what the action has to accommodate as to what has come before it as well as what it has to blend into as inputted by the player.

This though is a problem associated by the use of a state machine where the asset almost has to guess as to a change in the state so although root motion could be used it’s not an ideal design that adapts well as to scaling the player controls as required by an action added based on need or impulse.

With root motion it could be assumed that the preferred direction of the root would always be forward facing for the primary action but for a set of animations to be matched a between has to be added to make the primary action move from one direction into another. Mores or less it would be imposable to make a linear direction change with out a between.

2B for example it assumed the kick would be to the rear with the action of the player once again facing forward coming out of it but lets say the player decides to move off in the left direction you would only need a single between pose that changes the direction of the root and the new forward direction makes the new forward direction of the player coming off the kick into the left direction.

Where I figured it out was by playing around with blend spaces and realized that it’s possible to put all of ones primary actions into a single blend space and just let the software features do the proper blending for you based on a 100% pure data driven design and by layering the animations directly driven by an event or player input that excludes the need for argument based state machines that tends to limit player movement by defining what they can or can not do in a given state.

To me anyways a blend space that comes with the package, and seems to be a feature you plan to add at some point, adds value as to something that could be plug-n-play off the shelf but making the source files available, as you have done, is a must as I can always tailor to taste as the primary actions are a thing of beauty.