Search Unity

  1. Unity 2019.1 is now released.
    Dismiss Notice

Assets Motion Magic (MxM) - Motion Matching Animation System for Unity

Discussion in 'Works In Progress' started by CptKen, Jan 29, 2019.

  1. kenamis

    kenamis

    Joined:
    Feb 5, 2015
    Posts:
    321
    hey, maybe a silly question, but can your system do strafing and walk/run backward (plus turning and forward)? I think all I've seen in your videos is turning and forward movement (or did I miss one?). You're calculating the direction of movement AND the direction/facing of the character to determine what animation frame to play, right? I'm guessing you just don't have the animations for the strafing in the demos?
     
  2. CptKen

    CptKen

    Joined:
    May 30, 2017
    Posts:
    46
    It can do strafing by fixing the facing direction in the future trajectory to the direction you want to strafe. Some issues can happen if you don't have enough animation coverage and transitions though.

    Alternatively, you could also tag your strafing animations with a strafe tag in the provided MxM tagging editor and basically force it to strafe by telling MxM "I'm strafing"

    The animations I've shown are pretty bad for motion matching tbh. They are the Unity Raw Mocap set. I have tested it with strafing though I can't show it because it's for an unannounced project.

    Rest assured I'll have a section on strafing in the documentation.

    P.S MxM allows you to switch between Animator Controller or even your own custom animation system through playable at runtime so if the motion matching doesn't suite a particular situation or you don't have good animation coverage for some situations you can always fall back on that.
     
  3. razzraziel

    razzraziel

    Joined:
    Sep 13, 2018
    Posts:
    68
  4. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    372
    It brings an interesting point. I guess we need to be able to search the animation more using than just "move forward" vector. For example, we should be able specify some contraints, such as crouch, prawn and whatever the extra parameters(constraints) necessary. I was assuming it's possible, otherwise, it will be very limited.
    So, what kind of search parameters can you specify?

    Of course, I assume that we have animations that does crouch, and prawn already in the db.

    Thanks.
     
  5. CptKen

    CptKen

    Joined:
    May 30, 2017
    Posts:
    46
    Unfortunately these huge mocap sets are usually not very usable. They tend to have a lot of random animations. I'm not too concerned though, I know the system works and I'll try put together better examples closer to release for both mocap and also cut clips. I'll also provide documentation on how to shoot specifically for motion matching for those going down that route.

    Currently there are 32 tag slots that you can manually set and use for whatever you want. MxM has an easy to use timeline with preview functionality where you can make tag tracks and tag up ranges within your animation. Once you have tagged up the animations like this you would simply call MxMAnimator.AddRequiredTag(ETags.Crouch) <- something like that. Without this functionality and events, Motion Matching is useless for anything but pure locomotion.

    upload_2019-4-3_14-7-55.png
     
  6. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    372
    Wow, great! It makes sense. Adding more tag can fine-tune the search. I really can't wait to try it. Are we getting close to the beta testing? within weeks instead of months? Thanks.
     
  7. CptKen

    CptKen

    Joined:
    May 30, 2017
    Posts:
    46
    Possibly. Though anything can happen. I certainly hope so.
     
  8. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    761
    Could this be combined with lots of classic animation clips as well to achieve better/automatic blending and eliminate the need for mecanim? Is there anything that makes it so mocap data is absolutely required?
    Or is there maybe a way to help the system out a bit in a situation like this by placing more tags/hints?

    I'm working on a little fun private project where I have tons of animation clips. My goal is actually not getting best quality, but reducing development overhead and simply saving time by not having to deal with mecanim (and if possible still getting "ok" / acceptable animation results)
     
  9. CptKen

    CptKen

    Joined:
    May 30, 2017
    Posts:
    46
    The answer to this is not so simple. MxM supports cut clips but that comes with some caveats. Cut clips will take more work to get working nicely than mocap data. Let me explain a few key concepts....

    Concept #1: Continuity
    The reason why mocap data is typically better for motion matching is because at each pose there is plenty of time in the future and in the past. This is important because the system needs to calculate a future and past trajectory for each pose so that it can match the desired input of the player. Typically we're talking up to 1 second in the past or future, though it is customizable.

    With cut clips you will find they are often far under 2 seconds long and even for ones that are 2 seconds, what do you do about poses near the end of the clip? It can't find a trajectory out of thin air. To remedy this, MxM can automatically string together looped clips to determine trajectory and for non-looped clips it allows you to either extrapolate the trajectory based on the motion delta of the last few frames or take the trajectory from another clip (user specified).

    So.... there is more work with cut clips because you will need to tell the system how you would like to determine future and past trajectories if they aren't looping. Either a check box for extrapolation or dragging in another animation to steal the trajectory from.

    Concept #2: Coverage
    Mocap is also good because you can have a lot of it and get good a good range of motions / coverage. With cut clips you tend to rely on a few animations with a few transitions and blend them to fill the gaps. This isn't easily done with motion matching for a number of reasons and I'll go more into detail in concept #3. An example is that you may have walking animations at 45degree intervals but you only have starts and stops in the NSWE directions (pretty common situation). The motion matching will struggle to bridge the gap between standing still and walking at 45 degrees because you don't have a walk_45_start animation.

    Why is this? Well this is the second part of motion matching. You are not just matching the player input (responsiveness), you are also matching the current pose of your character (fluidity). If you don't match pose you will get jumps in your animation and you won't have fluid movement. The whole thing is a balancing act between fluidity (pose)and responsiveness (trajectory).

    I have implemented something I call 'Discrepancy Compensation' which tries to compensate for these gaps by procedurally rotating the model to close the gap. However, what if you are strafing and don't want rotation?

    What tends to happen in situations like this is the system gets stuck in idle or chooses the walk forward and then turn in the direction you are going via the the Discrepancy Compensation.

    In the future (after initial release) I plan to implement a kind of blended animation asset that can be used with the system to cover these gaps. However, you have to consider that is still a bit more work, and you're losing some of the quality. Maybe not as much work as mechanim though.

    Concept #3: Lack of blended trees
    Blend trees and spaces are pretty bad as they approximate animations. As a result, you tend not to have full strafe sets if you want good starts stops and plants (at least you shouldn't). Instead to achieve this have to use some complex logic and restricts your blend spaces to limit poor approximations. Also to blend animations they have to be in sync and that cannot be guaranteed with motion matching as the system jumps through animation clips anywhere at any time.

    In short, motion matching only ever plays one animation at a time and the only blending occurring is to smoothly transition from animation to animation. Sometimes you can get about 10 animations fighting to be king. However, only one will be blending in and all the others will be blending out. It's used for smoothing rather than making animations that don't exist.

    Conclusion:
    With that all being said, I have been able to get some good results with cut clips, though it is more work than just throwing the animations in and smashing the 'Animate' button. Everything I've said above holds true for motion matching in general as far as I know, not just MxM. I know Unity talked up Kinematica like you can just throw in your cut clips. However, I've read the technical paper Michael Butner published at Siggraph on Kinematica and unless they change how it works, it will be even worse if you lack animation coverage. I even tried implementing it the Kinematica way and it was so brutal if you didn't have animation coverage that I reverted to a more traditional motion matching algorithm (there really wasn't much difference tbh).

    So with all that out of the way.... you have to understand that it really depends on the animations you have available and their coverage. Hopefully, based on the information above you can figure out if it will work for you. I'm going to try put out examples of both mocap and cut clips to show how it works in both situations.

    Oh and one last thing. If you have poor mocap, you're actually better to go with cut clips. I'll also include all this information and how to run mocap shoots for MxM in the release documentation for those who want to go down that path.
     
    Last edited: Apr 18, 2019 at 9:54 AM
    GuitarBro and hopeful like this.