Search Unity

  1. Unity 2020.2 has been released.
    Dismiss Notice
  2. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Unite Now - Kinematica – Democratizing Motion Matching for Character Animation

Discussion in 'Animation Previews' started by AskCarol, Apr 28, 2020.

  1. DavidGeoffroy

    DavidGeoffroy

    Unity Technologies

    Joined:
    Sep 9, 2014
    Posts:
    366
    Kinematica is really a semantic pose database. You ask for a pose, of a type (e.g.: Locomotion), and you can supply constraints: bones to match on, trajectory to match on, but you can totally just ask for "Jump2Meters, frame 0". (The code is a bit more complicated than that, but not that much).

    Responsiveness can be adjusted by lowering the bar for pose/trajectory matching, or by directly asking for a specific segment. All of this can be done at Runtime.

    We also provide code that generates a trajectory based on inputs, but you're totally free to build your own.
    Since it goes through the Animator, you can also adjust the root motion in OnAnimatorMove to cheat a bit.

    As for ML: there is none at the moment in Kinematica.
     
    GliderGuy and florianhanke like this.
  2. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,246
    @DavidGeoffroy

    I was trying to understand what is necessary to give the skeleton a sense of "weight" between frames besides straight animation frames. Do you guys have plans for this?

    If you look at my previous posts in this thread, I supplied a concept for how to quickly "weight" a skeleton via bone chains and how to interpolate based on these "weights" to get a more believable overall motion using the pose-to-pose thing that Kinematica is going for.

    I am hoping there's a way to dynamically handle skeleton / limb / appendage weight transfer (independent of pose) during animation interpolation. Yes/no/maybe?
     
    GliderGuy likes this.
  3. vorokoi

    vorokoi

    Joined:
    Oct 18, 2019
    Posts:
    39
  4. DavidGeoffroy

    DavidGeoffroy

    Unity Technologies

    Joined:
    Sep 9, 2014
    Posts:
    366
    We did explore ML in different ways.
    • PFNN: We were not very happy with the results. Mainly the feet were slipping a lot, and the animation personality was lost. Iteration times were also very slow (more than ten hours).
    • Generating trajectories based on inputs using ML. This gave great results, but the training times were also on the scale of hours. These need to be redone anytime your game mechanics change, or the animations change, which happens essentially everyday in game development.
    Ultimately, iteration times and maintaining animation personality are so important for game animation that we decided to refocus our efforts on making motion matching more approachable while keeping iteration times manageable. Even our current build times are a bit too long for proper iteration, and they are orders of magnitude faster than training a neural net. (We're working on it).

    We would like to come back to trajectory generation using neural networks, as an optional workflow, once the base tools are available to all and released.
     
    awesomedata, GliderGuy and vorokoi like this.
  5. DavidGeoffroy

    DavidGeoffroy

    Unity Technologies

    Joined:
    Sep 9, 2014
    Posts:
    366
    @Gabriel_SG
    @chusmaverde

    In case you missed it:

    Update (May 29th)
    The demo is now available! We've made the GitHub repository public as well.
    The repo address is - https://github.com/Unity-Technologies/Kinematica_Demo

    The release can be downloaded here.

    There's also a new version of Kinematica (0.6.0) with some fixes to bugs we've discovered while fixing the demo. The project is already configured with the proper Kinematica version.

    Thank you for your patience.
     
    GliderGuy and florianhanke like this.
  6. Lecks

    Lecks

    Joined:
    May 13, 2013
    Posts:
    15
    The ZIP file/release doesn't contain the FBX files.
     
  7. grahamsaulnier

    grahamsaulnier

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    7
    I just downloaded the Demo release zip have the fbx files under `Animations\Biped` and `Animations\Quadruped`. I'll reimport the project to be sure we aren't missing anything.

    Which files are missing for you?

    EDIT : Just saw that all those files are just references. It's because we're using git-lfs in our repository. We'll get that fixed ASAP.
     
    Last edited: Jun 4, 2020
    GliderGuy and Lecks like this.
  8. grahamsaulnier

    grahamsaulnier

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    7
    @Lecks

    I've just published a new release of the Kinematica Demo, 0.6.1-preview. I generated the archive manually and it contains the actual data files. It's considerably larger than the previous release (about 824MB) and can take quite some time to import.

    I apologize for the delay and inconvenience. I hope you're able to enjoy the demo project now!
     
    GliderGuy, AskCarol and florianhanke like this.
  9. Lecks

    Lecks

    Joined:
    May 13, 2013
    Posts:
    15
    Thanks, I cloned it from github while I was waiting. It looks interesting... I'm looking forward to better workflow for small premade clips (like the ones from the asset store, or ones I make myself in Blender). Having something that you could feed packs from Kobold or Mocap Online to generate animation would be amazing.
     
  10. CodeKiwi

    CodeKiwi

    Joined:
    Oct 27, 2016
    Posts:
    78
    Wow, that looks cool. I was wondering if the following example can be done with this system and some custom game logic.

    I have a baseball player in a fielding position. This character has basic locomotion animations and different catch animations (jump in air, slide etc). The catch animations have markers for when the ball is caught.
    1. Does this mean I can give this system the position of the ball 1 second in the future and it could give me an animation sequence that allows the player to catch the ball (or get as close as possible) at that time?
    2. Is it possible to give costs to animations? E.g. a sliding catch should only be used as a last resort.
    3. Is it possible to predict the future of world objects or other characters e.g. follow the trajectory of the ball, could make the character move to a location to catch the ball (larger number of valid animations).
    Thanks for releasing the demo. I'll have to try it out soon.
     
  11. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    @CodeKiwi There is code in the demo that use Kinematica motion matching for climbing and parkour, it's explained a bit by Michael Buttner in the Unite video. In the upcoming weeks, we plan to rework a bit this piece of code and integrate it into the Kinematica API so that it can easily be used for any contextual action (climbing, melee attack, baseball catch, pressing button...). Meanwhile you can copy paste the code from the demo to give it a try.

    1. Yes absolutely this system is designed exactly for that
    2. I think the easiest way to impement that would be to use a sequence in the Kinematica task graph. A sequence will try to execute its first child, if it succeed it stops here, otherwise it will try to execute its second child and so on.
      So you could have a sequence with a first child task that only consider A animations for motion matching, then a second child task that only considers slide animations. (this second child will only executes if first child didn't find a suitable candidate among A animations)
    3. This one would require a bit more work : the contextual action motion matching relies on a fixed position in the future as point of reference. From this point in space Kinematica "unwraps" all candidate animations from their final frame, and look in the created trajectory for a good transition.
      You could probably achieve what you want by embedding a different delay time inside the catch markers of your candidate animations. Then when unwrapping every candidate animation, you would do it from the predicted ball position along the trajectory with delay time inside the candidate marker. For example if delay time is 3 seconds for the marker of one candidate, you will actually consider the position of the ball 3 seconds in the future instead of 1, for this specific candidate animation only.
     
    Last edited: Jun 7, 2020
    GliderGuy, CodeKiwi and florianhanke like this.
  12. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    @awesomedata There isn't one animation technology that has been designed to solve all animation issues as they can be vastly different. This is why we combine several technologies to achieve the best possible result.

    For instance, Kinematica isn't designed to solve foot colliding into the ground, and you will need to combine it with Foot IK to achieve that result (Fortunately, Unity comes with a vast set of animation tools that can be combined with Kinematica when necessary).

    This is the exact same principle for the issue you raise : motion matching is not designed to "give the skeleton a sense of "weight" between frames", it is designed to find the best possible transition from one frame to the next without altering animation data. If at some point gameplay ask a trajectory for which there is not a single transition animation in the data that give a sense a weight, motion matching won't be able to create any sense of weight, as per design.

    And the opposite is true as well, most of the AAA game's animated characters using motion matching have a great sense of weight in every situation without using any dynamic weight transfer, as they did a tremendeous amount of work to provide a suitable weighted animation for every possible situation in the game.

    Now, don't get me wrong : technologies like the dynamic weight transfer you propose are always interesting, but
    1. It is quite experimental, there is no paper/talk that proves the effectiveness and scalability of this approach I believe (please correct me if I am wrong)
    2. It is not specific in any way to motion matching as it could be used as well with traditional animation graphs, so there is no point in asking for such a feature in the Kinematica forum. Perhaps you can try to propose this feature in general animation forums, but I believe 1. will probably prevent it from being considered in the near future.
    P.S. : the samples in Kinematica are mostly proofs of concept, they are not polished yet and therefore can still produce bad results (like stuttering characters that actually kills sense of weight...) from time to time.
     
    GliderGuy and neoshaman like this.
  13. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,246
    Fair enough. I can understand your position, but at the end of the day, the resulting workflow seems disconnected from the final result. For example, what is the point of Kinematica when the following is required for "weighted" animation:

    Animation is already a tremendous amount of work -- but then, instead of doing that work to simply be productive, instead you have to do that for a tool to be productive??

    Sorry, but I thought tools were supposed to help me?? -- I didn't know it was my job to help a tool?


    Besides that -- not only is this level of engineering not accessible to most indies, this enormous effort is also seemingly pointless, not to mention incompatible with existing tools for the purposes of secondary animation (like Animation Rigging), whereas my proposed solution could be taken into account there and here both so it would be able to solve BOTH weighting and foot sliding issues for both pose-to-pose and dynamic procedural poses (including pose-matching) -- at once. Either approach would require its own individual (and heavily dependent) solution otherwise if taken into the workflow described by Dave Hunt in his recent GDC talk (which is where I'm assuming Kinematica is supposed to "fit in". The need for secondary animation is not going to just "go away" regardless of what your goals are with your animation pipeline -- or even which tools you consider to be a part of that.

    Sorry if I sound hostile, but it deeply bothers me that this is the "official explanation" from Unity.

    Kinematica either implements secondary animation itself, or it cannot be strictly at the end of the pipeline for animation / pose-matching in Unity.

    I will explain my reasoning below.





    1: A fair point -- but please remember, Kinematica itself is also experimental, so I'd think this fits right in. After all, the effectiveness and scalability of Kinematica itself has yet to be proven -- unless you can link me to some documentation or videos showing that scalability and effectiveness (particularly for indies?)

    Though, as per your request to "correct you" if you were wrong -- a talk/presentation on pose-matching + a skeletal weighting solution exists as far back as 2014. If you want to see how pose-matching / skeletal-weighting exists alongside a procedural approach to animation scaled effectively to a legit (proven) game, see the popular GDC talk here:


    Sadly, Unity can't copy/paste code for it like you can with a paper, but the approach is self-explanatory (assuming you get back to basics with animation and pay attention to the physics portion and how it "drives" pose-matching for things like walk/run interpolation.) Honestly, this is the kind of "prediction" I had expected when Unity announced Kinematica in the first place, and particularly, in how it might have integrated Machine Learning into that "prediction" algorithm. Basing it entirely on a huge library of poses and animation data just seemed ludicrous to me from the outset. But apparently it really was what you guys went with -- then subsequently tossed-out. D:

    Nobody knows everything, but I've spent a lot of my life studying proceduralism in animation (and modeling/art), so I could be a big help here in helping you refine your direction.

    Maybe it's time to listen to (and receive input from) someone else?


    2: I ask for it here because (first of all) there is no Animation Rigging forum to speak of, and (more importantly) it could be very specific to the _implementation_ of motion matching in Kinematica (as rigging constraints deal with PART of the skeleton, while pose-matching in Kinematica deals with the ENTIRE skeleton, especially in how it "finds" the next pose -- and most importantly -- it does that AFTER all constraints are done being solved for via Animation Rigging), and this "secondary motion" solver is fully-dependent on how things are written under the hood with Kinematica. At the very least, some sort of data bridge would need to be considered if Animation Rigging were to be considered to author this data for Kinematica.

    The way Kinematica is currently designed (as a straight pose-matching "solution") is probably fine for larger studios (with less experienced teams of animators) who have the time/money to throw at producing enormous amounts of animations data for it (but this is FAR from "Democratizing" Game Development, which, supposedly, is still Unity's goal?) However, true "pose-to-pose" graphs are being moved away from by almost all 3d game development studios in favor of procedural motion (for very obvious reasons, including immersion, ease-of-authoring, etc.) all in an effort to keep pace with the industry. This means that a solution to handle real-time, changing, data (especially during the pose-matching process itself) should start being considered as part of Kinematica anyways at some point.
    I, like a lot of others here, had been looking forward to Kinematica as a "bridge solution" to do this kind of procedural motion, alongside Animation Rigging / DOTS Animation's constraints to get a better-looking animation at the end of the posing process / pipeline (which is where secondary animation is usually applied -- see traditional 2d animation for the step where the "floppy bits" are added). I don't understand why the approach I suggested was not part of the design of Kinematica to begin with, rather than a focus on making frame-based animations (even procedurally-driven ones) a result of one's "secondary motion" (as Kinematica is doing) rather than the more common-sense approach of making the pose-matching be the driver for one's "secondary motion" -- What Kinematica is doing makes no sense to the animation process, no matter what you're animating -- but please, correct me if I'm wrong if I am misinterpreting the clear avoidance of changing anything in Kinematica, as was previously stated because, as it stands right now, "making a frame based animation result" with Kinematica seems to be the sole purpose of the tool -- which itself "can be done with any other animation graph and is not specific to Kinematica" -- and if this is the case, I cannot fathom how this is considered any "easier" or "more productive" than simply making the same thing using existing tools, with the added love of modular rigging).

    I may sound like a naysayer, but I promise this is all meant to be constructive.

    Please don't take this personally.

    Unity has historically missed the mark on Animation, but it's good to see you guys are trying hard despite this.

    What I am proposing is that you not mindlessly defend Unity's current approach, and consider new / better avenues of approach to a historically-stagnant technology. Animation is terribly outdated and it embarrasses me (as both an animator and as a tool designer) that Animation in Unity is still so "stilted" by the tools it involves. Unity clings so hard to its tools' "designs" that they can not -- and will not -- consider any other approach (or reasoning!) to the contrary.

    This is true across Unity's Technology as a whole.


    Just the fact that a paper or talk doesn't exist shouldn't keep you from addressing valid points in the current approach. Yes, animation approaches can be varied (but this "variation" is mostly based around the limitations of the tools that are used to author the animations -- and not by any artistic "choice" in the matter). However, despite this, at the end of the day, over-complicated tools exist to "fix" the over-complicated approach that other over-complicated tools (Maya) fail to address in their complexity.
    Animation is still the translation of a value (or group of values) over a period of time, referencing and changing certain parameters. When you add the "game" layer to it, the number of these "certain parameters" simply increases. The complexity shouldn't, however.

    The beauty of procedural animation is that this "period of time" doesn't have to be specified beforehand, nor do "certain parameters". The fact that Kinematica relies on frame-based data (even from modularly-rigged skeletons) is great for "straight-ahead" animations. However, the problem with a stilted approach, again, is "secondary animation" -- Or, in other words, the little bits and bobs that provide a sense of the "material" and "weight" of a subject. These help define a sense of "anticipation" and "recoil" as I described in an earlier post. While that explanation mentions "frames" -- it only does this to refer to the resulting "frames" rendered by Kinematica -- not "frame-based animation" as a whole. This is a very important distinction, as the whole idea of 2d animation is that you can animate ANYTHING you want. 3d lags way behind in that regard, and it is precisely BECAUSE of these "stilted" animation tools and their "design" approach. :/

    A cloth system isn't enough to trick the brain into true secondary animation (think of the clipping of capes into player geometry -- kinda breaks the immersion, yeah?) -- There is a point where the forward-animation in something like Kinematica's frame-based references should be able to influence secondary "weight" characteristics from bones or constraints from something like Animation Rigging. Kind of like "root motion" is an option, I think "secondary animation" should probably be an option too, when pose-matching, as it could go both ways.

    Is this in the pipeline for Kinematica? -- If not, I don't see the usefulness of Kinematica without tons and tons of hand-authored data that indies (like myself) are simply not going to be able (or willing) to provide. Not to mention the difficulties in modifying the data after it has been created/generated by the user. Dave Hunt in his recent GDC talk went over these issues nicely. There are very few instances where relying on frame-based data is not tedious (at the very least) or simply not feasible (at the most common), at least for indies.
    So why even create it??
    Kinematica does very little to help indies without assistance in the authoring process for animations. I get that this is not the purpose for which it was "designed" -- but, as already implied, I think the current "design" mandates are wrong.



    For the reasons of no procedural approach to secondary animation (_after_ pose-selection for the new "frame" has occurred) and due to heavy user-data requirements (beyond just "poses" like we were originally led to believe -- since extra motion data made sense to help "Machine Learn" poses -- but now that it's gone, I don't see any point to it), unless Kinematica has some transfer mechanism to/from Animation Rigging data to source its pose-weighting from (as an easy way to handle secondary "weight" animation post-Kinematica pose-selection), Kinematica cannot truly be useful to indies. Secondary animation is critical -- and procedural animation is a simple, easy-to-author, approach to making that secondary-animation data appear lifelike.

    There is a reason animation is called "the illusion of life" by Disney. This is because, even with crappy pixel art in some games, as long as the motions are believable and fluid and follow the laws of motion in a fluid, predictable (rhythmic) way -- your brain sees a living, breathing, entity. And computers are great at this sort of thing. Humans -- not so much.

    And if you really just need a paper describing this -- I can write one for you. After all, I do enough of it lately to help Unity have all the "data" it needs to make a badass tool. This post included.

    However, I'm just a dude on a forum. Why listen to me? :/
     
    Last edited: Jun 9, 2020
    FlavioIT and GliderGuy like this.
  14. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    @awesomedata

    That's another rather long post! I appreciate the passion you put in your message, but there are lot of misconceptions I need to answer :
    • Kinematica is based on motion matching, which is not experimental at all, numerous games shipped with it, which proves its effectiveness and scalability (even if it has challenge, scaling down is obviously always easier)
    • Motion matching was never meant to help animators produce less animations, as I already explained above. You will still need to produce lot of animations to reach a high level quality, if AAA studios were able to stop spending lot of money in mocap by using procedural generation of motion like dynamic weight transfer, they would do it in a heartbeat.
    • The goal of motion matching is to replace parts or all work needed to setup complex animation graphs while still using the same animation data, by automating a lof of the process, whether you have a couple of animations or hours of mocap data.
    • The well known technique from Wolfire you posted is not a dynamic weight transfer technique, it's merely hand crafted blending curves, leaning and IKs
    • More importantly, you can see in the video that Wolfire dev used this technique without motion matching, and it's actually used in many games that only relies on anim graphs and don't use motion matching. So, again, there is no point in developing specifically this feature for Kinematica.
    We are always opened to feedback, and I appreciate you took the time to express and develop yours. However, we also took the time to listen to it and explain to you on several occasions why we don't intend to implement it in Kinematica. Therefore I am politely asking you to stop insisting on adding this feature, we will ignore all future discussion specifically about this request.

    Thanks !
     
    Last edited: Jun 10, 2020
    AndrewKaninchen and SenseEater like this.
  15. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,246
    Except when the feedback is particularly hard to address. So...

    Which I assume, since you didn't address any of my points (despite me making them very clear), just means you have thrown all you have at me to get me to "go away" and don't want to be bothered thinking of anything else to avoid more discourse.


    Sorry for making your job harder, but this type of "open to feedback" is clearly a way to say "sorry, but your feedback is too difficult/painful to address, so we're not going to bother -- we'd much prefer blind praise and bug reports instead."

    :(


    No worries, you don't have to "ignore" me further -- you've already done so.



    But before I stop bothering you, I have some things to say regarding the "misconceptions" you've pointed out:


    Kinematica itself (and its specific implementation) is experimental -- and motion-matching is definitely still in its infancy technology-wise. Ubisoft is the leader on animation technology innovations and experimentation, and even they haven't perfected motion-matching into a perfectly-designed "end-to-end" procedural pipeline solution yet, so I'm not expecting miracles from Unity on this front. Though, this isn't the point. As far as I know, exactly ZERO games have been shipped using Kinematica. But, again, you may correct me if I'm wrong. Kinematica was what I was referring to as an "experimental" product -- not motion-matching. And Kinematica was what I was referring to as not having been proven as efficient or scalable yet.

    Nice attempt at a dodge, however. Props to you. :)


    Sure, just like everyone would take up meditation if could relieve their stress. Or go to the hospital if it could cure them.

    Sorry, but this simplistic logic just doesn't cut it in real game studios. Game development is a very complex set of variables, and what one AAA pays for a mocap session is much less than what the same AAA pays for an animator to do a similar set of animations. The same isn't true for indies, who often have to do animations themselves. This means a scalable animation graph is definitely handy to an indie, but when it costs more time/money to actually make the graph? -- I don't see how this is possible to condone as not being part of the scope of pose-matching in Kinematica. You say it's easier to "scale down" than up -- I'd like to see that, but combined with procedural motion. :/

    You're (almost) completely wrong there. -- While it does use blending curves and IK, the physics are what informs the "leaning" you speak of, meaning physics also informs the final skeleton position, which means it has particular weights associated with portions of the skeleton itself. In other words -- it's procedural (i.e. dynamic) skeletal weighting being transferred from skeletal weighting data (probably another curve) resulting in pose-matched frames that simply take on that weighting information from the skeleton and the previous frame's pose result.

    Pay closer attention to the video -- He doesn't show it, but he explicitly states this weighting is done using a skeleton-based weighting technique when he describes the "softness" of the arms moving with the bunny as it moves around. He goes quickly, but it's definitely there (and worth a second look). It's around the first time you can see the slight delay in the arms as he moves the bunny around. I've watched this talk carefully a number of times and successfully reverse-engineered the process. Trust me, I know how he does it. Sure, he uses IK, but only in certain special cases -- not as the driver for his entire animation.

    To describe this in Unity's world:

    The pose-matching part of Wolfire's technique (the hand-crafted curve-blending, which is a metaphor to Kinematica's pose-matching) is simply done before the Animation Rigging's pose-blending part (in Unity) so the previous pose can be blended toward invisible constraints based on physical velocity (meaning Kinematica has produced and stored a pose-result for a previous frame to use as the base of blending for Animation Rigging in the next frame), allowing for the Animation Rigging constraints to be shifted according to this velocity, allowing for a final pose to be blended toward (i.e. using Animation Rigging), which is then used by Kinematica to "pick" the next pose based on Animation data (and in Wolfire's case, this is simply when a character controller says the next state), letting Animation Rigging store the new constraint positions as the "old" constraint data to be used for blending in the next frame. The actual velocity of the constraint is determined by the "weight" applied to the individual joints / chains when combined with the distance from one "frame" position to the new one, meaning Kinematica must know about the new Animation Rigging positioning to store it for the next frame to be properly processed by Animation Rigging in the "next" frame.




    Just to clarify -- it's not any "feature" in particular I'm advocating for -- I'm advocating for a workflow.

    "Dynamic weight transfer" is what you took from my suggestion on how to handle weight "post-Kinematica" but it was not a "feature request" to begin with -- only a suggestion on how you guys _could_ handle weight transfer (from within Kinematica itself) to prevent an extra (required) Animation Rigging blending step after Kinematica is done with pose-matching its frame). This request for a better workflow to handle weight transfer was made according to Dave Hunt's graph, which implies that once Unity is done with Kinematica pose-matching, its animation processing is done -- and this is a BIG problem when you want to have one last Animation Rigging blend one frame before (and immediately after) Kinematica (but before the current animation frame is "complete"), which means you're immediately doing another Animation Rigging blending step in the same frame as the frame you've already blended the weighting (meaning the "workaround" is likely to require either a rewrite [or at least a reworking] of either the Animation Rigging or Kinematica systems -- and most animators have no skills/knowhow of the code to handle this kind of complex task).


    Maybe you know something I dont on a good way to get around this issue, but I've yet to hear any point you've mentioned address procedural weighting for "post-Kinematica" frame processing and blending with constraints (which is what my previous post went over, in great detail), and therefore I don't feel like this "discussion" is quite over.


    Fine, but why just actively refuse a (potentially tiny!) change to help those who can use the tool that way?

    It doesn't make sense.


    This is okay by me, but I bet, with the help of being able to do blending between different Kinematica pose-matched poses across a particular number of frames, some cool dynamic skeletal weight stuff (similar to what Wolfire did) would be possible (indirectly) with Kinematica as a base -- and by providing a small number of animations too -- By using Animation Rigging as the backbone for blending, and using Kinematica as the animation pose-graph, there's some amazing workflows possible with Kinematica -- yet it seems you'd rather keep it stagnant.

    I (and many others) still need a complex graph when I want to do pose grabbing / referencing after Kinematica (and before Animation Rigging) right now, so something between Kinematica and the next frame, Kinematica simply won't work for me as a final step in my workflow when I use procedural animation. :/


    Just my thoughts. Take them or leave them.
     
    Last edited: Jun 11, 2020
    GliderGuy likes this.
  16. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Just to clarify my precedent (and still very valid) post :

    The Kinematica team is focusing all its efforts on delivering and improving motion matching technology for Unity (in terms of possibilities, performance, usability...) and is therefore only implementing features specific to motion matching because :
    1. Obviously, making a powerful and accessible motion matching technology is a huge amount of work already consuming all our bandwidth
    2. If a feature is not specific to motion matching (for example foot IK), we don't want to constrain the user to use it only with Kinematica and deprive them from combining the tools to best fit their needs (for example, anim graphs + foot IK)
    3. Kinematica is already a Playable (https://docs.unity3d.com/Manual/Playables.html). So the output pose from Kinematica can already be combined with any other Playable, including blending, foot IK or any procedural pass the user might want to implement like the features shown in the Wolfire GDC video for example.
    4. As already explained before, Kinematica is aimed to fully support a maximum of other Unity tools & technologies in its workflow like Animation Rigging & Timeline in the future, it will also be compatible with DOTS.
    Have all a great day !
     
    Last edited: Jun 13, 2020
  17. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    5,571
    @FrancoisFournel @awesomedata
    I think it's a mere miscommunication and I think Awesome data misunderstood how motion matching actually work, the key is that motion matching is presented as "animation blending" which is true, but it's more of a search engine. And Francois don't understand where awesomedata comes from and can't answer properly.

    @awesomedata
    The motion matching don't work like that wolfire video, trust me, I like animation and procedural too.
    - in the wolfire video, there is 2 things, pose to pose blending, where the pose are known in advance and given by code, then secondary animation driven by physics. You can do the second thing with any animation engine of unity as lateupdate() additives, kinematica would provide an animation frame output, like other animation engine, THEN you adjust, like we already do.
    - What kinematica intend to solve is the authoring of blend tree, that is the part where you have to hand given (by code or data) all the transition to any animation. It does so by searching the closest match over multiple frame. As such the main difference is that it doesn't know in advance which pose are best, and thus search it. As such we can't add weight data, because that's not how it works, it doesn't know handle the animation curve per see, it just find the pose on that curve, that is, in order to add weight you need more data to match. It's just that a pose matching engine, it's a workflow improvement, you still to have mastery over it.

    What is experimental on kinematica?

    Well the problem as stated is well understood:
    - there was an academic paper with an over engineer solution.
    - then ubisoft figure out a brute force approach was good enough for production
    - then paper start appearing with DNN
    - Then unity announce a ML solution, which there is no mention now (probably because you can get the product out and just deal with that in the backend transparently)

    Regarding production, it's ready as an algorithm, it's been in use and easy to implement, the only experimental aspect is in optimizing the matching algorithm, which is transparent regarding use, it's a back end problem, it change nothing for animator. So if my speculation is true, and they drop ML, they are probably still experimenting with it in back end to stay on top of the state of the art, and that can be done concurrently with a production version, and more importantly deployed silently as an optimization, without impacting workflow.

    What may have confused you is that unity also presented "animation rigging" which seems to do EXACTLY what you are asking for is basically the evolution of the wolfire's pcg animation and ubisoft Ik rig experiment.
    https://blogs.unity3d.com/2019/05/1...ion-rigging-preview-package-for-unity-2019-1/
    They were presented together in the animation segment of teh engine, so it probably blurred for you too. It's a kind of lateupdate-y additive animation and constrain, that seems to work both in engine and at run time to create animation.
    see this video for a editor level workflow:


    and here is the unite presentation


    I hope I help clarified the situation and resolve the tension brewing between you guys
     
  18. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Kinematica 0.7.0-preview released

    Hello folks, we released a new version of Kinematica, here are the major changes :
    • Asynchronous Burst Build Process
      The entire build process is now done in Burst jobs, taking about 10 seconds instead of 3 minutes for the project demo character. It's also asynchronous, so you can continue to use Unity while building Kinematica asset, and it is also cancellable at any point in time
      asyncbuild.png

    • Debugging motion matching cost
      When debugging a character with Kinematica Task Graph, you can click on the Match Fragment node to display more advanced options. You can display 3 motion fragments :
      - The current fragment (yellow)
      - The best fragment found by motion matching (blue)
      - A fragment chosen by user in the builder timeline
      The node displays the trajectory and pose cost of best fragment and user-chosen fragment relative to the current fragment. It's very useful in order to understand why Kinematica choose a specific fragment and not the one you intended in a given situation, you can compare and see how much trajectory and pose impacted the decision
      debugging.png

    • Multiple UX improvements in the Builder Timeline window,
      like displaying overlapping markers markerOverlap.gif

    Feedbacks are always welcome! In the upcoming weeks we will work on improving debugging workflow and converting the climbing code from the demo into a generic matching event API in the package.

    Here is the complete changelog :

    [0.7.0-preview] - 2020-06-25
    Fixed
    • Fixed possible NaN in ScalarTransition
    • Fixed borders of metric visualization so it is now possible to differentiate between adjacent metrics
    • The Asset Builder will now properly update when changes are made in the inspector window
    Added
    • Added fragment comparison debug info (including pose & trajectory cost) in task graph for match fragment task
    • Added SynthesizerHolder to regroup all memory allocators related to the synthesizer and add required methods to forward to the synthesizer
    • The Kinematica Job write the root motion into the AnimationStream in order to be able to use the normal deltaPosition and deltaRotation in the OnAnimatorMove()
    • Added procedural notations to allow for example converting AnimationEvents to Marker or Tag Annotations at build time or as a right-click option in the Asset Builder.
    • Added limited debug draw lines in the TaskGraph for HDRP
    • Added version control checks prior to build to ensure that the binary and debug file can be written to
    • Context menu options to add new Markers on the marker track
    • Body joint index automatically computed from avatar import options
    Changed
    • Renamed task creation functions for clarity and gather them into a single place inside TaskReference struct
    • Kinematica Job made public and independent from the Kinematica component (deltatime propery handle)
    • The TaskGraph and Asset Builder uses the ISynthesizerProvider interface and no longer refer to the Kinematica component
    • When initilizing the MotionSynthesizer we use the world transform instead of local tranform to support nested animator component in the hierarchy and because the root motion is applied in world in the Kinematica component
    • Removing unused parameter from TaggedAnimationClip.Create
    • Animation clips are loaded only when necessary and a progress bar is displayed
    • Kinematica Asset build process is asynchronous, cancellable and done in burst jobs
    • Improved selection of overlaping Marker elements to include markers that are very close to each other in the timeline
     
  19. SenseEater

    SenseEater

    Joined:
    Nov 28, 2014
    Posts:
    77
    Does this work for iOS & Android?
     
  20. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Yes Kinematica is supposed to work on any platform supported by Unity.
    However we didn't intensively test Kinematica on mobile platforms yet, therefore some issues we are not aware of might happen.
     
    Last edited: Jun 30, 2020
  21. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    691
    Hi, I would like to use Kinematica for my project but last time when I checked, Kinematica was quite heavy on CPU (compared to other MotionMatching asset)
    Can you please add StressTest scene to the examples? It would be nice to see how performance is improving over time.

    Thanks.
     
  22. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Hello, did you try to Kinematica with Burst enabled out of curiosity ? It's very slow without Burst.

    Using Kinematica in editor might be a bit slow in some situations because of debugging (we will work on that in the future). Standalone build using Kinematica should be pretty fast according to our tests.

    You are absolutely right, we need to add stress tests to watch performance, we'll try to do it soon.
     
    Last edited: Jun 30, 2020
  23. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,246
    Thanks for that explanation -- I've been following Kinematica for quite some time now, and it's been unclear to me what Unity's goal with Kinematica was from the start, much less _what_ the ML part actually _did_ for how "pose-matching" really worked under the hood. On top of this, I really didn't fully understand why frame-based animations seemed to be required when you've already got Animation Rigging to handle transitioning to different poses.

    To me, it was _not_ clear that Kinematica did nothing with the animation "frame" itself (aside from searching for one that best matched the current one), and therefore I assumed it handled transitioning the "frames" too (as if it were a simple animation). It didn't make sense, but I figured it was just trying to do a very similar thing to what the standard "animation graph" was _already_ doing -- except in a more incompatible (and oddly more-limited) way.

    Sorry for the confusion, @FrancoisFournel.

    I clearly had no idea what the hell Kinematica was for (and especially the scope of it) since ML was dropped, and so I got a bit antsy about not seeing the purpose for the tool despite this one (and not Animation Rigging) being mentioned early-on, being touted for being "the awesome new way to do animation in Unity!"
    This bothered me because support for Unity tools tend to disappear not long after the tool is dropped, and it leaves many of us still using it scratching our heads as to the reason for the design decisions (and poor API) we struggle with every day. Ever since Mecanim, I have been plagued by Unity's inability to do animation well, leading me to fight with a terrible API and a rabbit-hole of mysteries and/or bugs, with little clue of how you guys (not _you_ specifically) ever intended us lowly developers to understand how to properly progress with such poor and unclear documentation / guidelines for using the tool and/or its API. So I was a bit shell-shocked when I saw that yet another very basic thing had been overlooked on yet another heavily-touted tool for animation.

    That being said -- Sorry for jumping to conclusions. This is looking great for pose-matching so far.


    Thanks, @neoshaman, for clearing that up for me!



    PS: I was wondering how the tool-flow path would look for doing something like the Wolfire process in Unity, across its new animation tools and possibly utilizing Kinematica?
    If that's too complicated to explain/draw out -- how about the tool-flow for some simple (physics-weighted) hinge-joint animations with Kinematica pose-matching, assuming the developer is using DOTS Physics?
    What's the tool-flow path to setup and process that kind of an end-result?

    In other words: Use external animation package to author basic sample animations -> Animation Rigging to handle special aiming of the arm -> Kinematica to pick the proper arm angle, elbow bend pose for forearm/shoulder/wrist twisting -> DOTS Physics to grab "weight" from colliders -> Animation Rigging to "correct" pose based on weight? -- Or am I way off?
     
    GliderGuy likes this.
  24. SenseEater

    SenseEater

    Joined:
    Nov 28, 2014
    Posts:
    77
    @awesomedata
    i believe you can avoid confusion if you just objectively look at entire animation pipeline.

    - You have Playables API for flow control ; Animator Controller Graph & Animancer like API use this for decision making of what & when to play ( Kinematica aims to reduce the manual effort spent here )
    - Then you have Mecanim ; the animation engine that evaluates the bone translation and applies skinning to models.
    - Finally we have post process ( OnAnimatorMove ); this is where you generally do IK ( FinalIK , Animation Rigging , these packages might not be using this callback but are still Post Process systems )
     
    florianhanke likes this.
  25. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,246
    For the most part, this is true. -- And I have. But I'm not being biased here.


    See below:

    upload_2020-7-1_14-51-11.png

    There is a blatantly-obvious "missing step" here, just beyond Kinematica and just _before_ runtime rigging's "world interactions / rig deformations". This "missing step" is obvious because, technically, inertia doesn't care about your pose (whether it was matched or not), and any "world interactions / rig deformations" (i.e. IK or hand-positioning on world-space controls/target placement) should be separate to ragdoll/active-ragdoll scenarios (and be handled prior to final IK posing and target placement) because IK posing / target placement _should_ already respect any physically-based world offsets or other kinds of interpolation applied by inertia.

    This would clearly mean post-Kinematica processing while also being processed pre-Runtime-Rigging.

    In such a case, with Kinematica being the "last-stop pose-shop", I feel like it should either pass the buck to someone else (i.e. DOTS Physics + Active Ragdoll System + Standalone Pose Output System that can be ingested by Kinematica or Runtime Rigging), or handle things itself by outputting the final pose back to Runtime Rigging or back to Kinematica itself.

    What is the plan for handling this workflow situation?



    Being able to set per-frame interpolation as well as other kinds of rig pose interpolation (e.g. stop motion animation or something like the Wolfire system), without having to go through a complex playable graph setup (and forcing animators to learn yet _another_ API just to have actual control over said graph for basic/common functionality such as producing active-ragdolls or pre-corrected IK target positioning). Honestly, with something like this to let us better-control graphs (in a visual way), Unity would literally be an end-to-end, intuitive, animation solution -- for _any_ kind of game animation.

    Is Kinematica in the cards for this _at ALL_, or is there something else Unity plans to do for Active Ragdoll interpolation pre-IK/FK and pre-worldspace-target-positioning at runtime?
     
    Last edited: Jul 1, 2020
    GliderGuy likes this.
  26. sinjinn

    sinjinn

    Joined:
    Mar 31, 2019
    Posts:
    133
    I would like to try the wolfire games method with Animation Rigging. How would I start?
     
  27. SenseEater

    SenseEater

    Joined:
    Nov 28, 2014
    Posts:
    77
    Animation Rigging is primarily Constraints & IK Package. Wolfire covers IK along with some other simple blending methods for procedural output.

    You could be using Animation Rigging package for something as simple as Grounding the character dynamically on uneven surfaces to get going in that direction.

    Packages from store like FinalIK already comes with such utilities out of the box from what i know but shouldn't be that much effort to write a Grounder for AnimRig package if it doesn't exist already.

    The pose blending that is shown early on in Wolfire talk is simple blending between two poses that is done at runtime. you have your input poses and the curves and then do Lerp for positions & Slerp for rotations to interpolate to targets.

    When deep diving , you need to look more into advanced procedural techniques like Inertial Blending , Foot Phase Synchronization , Frame Delta Correction to achieved truly procedural and high fidelity realistic humanoid animations. These are not covered in Wolfire videos but you can learn about them in other GDC talks.
     
    FlavioIT and sinjinn like this.
  28. sinjinn

    sinjinn

    Joined:
    Mar 31, 2019
    Posts:
    133
    Thank you very much. Time to fire up google.
     
  29. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    5,571
    Where is the animation rigging thread anyway, we are off topic
     
  30. omgchar

    omgchar

    Joined:
    Oct 26, 2019
    Posts:
    1
    Hi:

    I have a question about the Query.Where. I know how to search for tags without types. But don't know how to deal with those have types. (like Wall, Ledge, etc.)

    For example, I have a Tag with 4 types, and I want to use the query (probably use "And<>") to find out:
    1. All types in that tag (the tag itself)
    2. Only one type in that tag (a specific type)

    Can anyone tell me that how to write the Trait, the Tag, and the Query? An example would be appreciated.
     
  31. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Hello,

    Actually, currently, the API only provide query functions to search for a specific trait value and for a global tag type. Example taken from the demo project https://github.com/Unity-Technologies/Kinematica_Demo :

    Definition of the trait :
    Code (CSharp):
    1. [Trait]
    2. public struct Climbing
    3. {
    4.     public enum Type
    5.     {
    6.         Ledge,
    7.         Wall
    8.     }
    9.  
    10.     public Type type;
    11.  
    12.     public static Climbing Create(Type type)
    13.     {
    14.         return new Climbing
    15.         {
    16.             type = type
    17.         };
    18.     }
    19. }
    Definition of the tag (only used in Editor):
    Code (CSharp):
    1. [Serializable]
    2. [Tag("Climbing", "#d25048")]
    3. public struct ClimbingTag : Payload<Climbing>
    4. {
    5.     public Climbing.Type type;
    6.  
    7.     public Climbing Build(PayloadBuilder builder)
    8.     {
    9.         return Climbing.Create(type);
    10.     }
    11.  
    12.     public static ClimbingTag Create(Climbing.Type type)
    13.     {
    14.         return new ClimbingTag
    15.         {
    16.             type = type
    17.         };
    18.     }
    19. }
    20.  
    Then in code, you cannot currently query for any
    Climbing
    trait, you must specificy the trait value you want to query :

    Code (CSharp):
    1. Climbing climbingTrait = Climbing.Create(Climbing.Type.Wall);
    2. var climbingPoses = synthesizer.Query.Where(climbingTrait);
    This is by design in the sense that if designer introduce trait value, that means they want to separate the traits inside the queries. We will still add query functions to query for the whole tag type, but currently you can do it this way

    Code (CSharp):
    1. Climbing wallTrait = Climbing.Create(Climbing.Type.Wall);
    2. Climbing ledgeTrait = Climbing.Create(Climbing.Type.Ledge);
    3. var allClimbingPoses = synthesizer.Query.Where(wallTrait).Or(ledgeTrait);
     
    omgchar and florianhanke like this.
  32. Kybernetik

    Kybernetik

    Joined:
    Jan 3, 2013
    Posts:
    1,364
    Why are you using Create methods like that instead of just regular constructors?

    And wouldn't it be way more convenient if you could just put the [Trait] attribute on the ClimbingType enum so you don't need to waste time and performance on the wrapper?
     
  33. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    This is a code convention we use in the Kinematica code base for consistency reason : C# struct doesn't support parameterless constructor, so we need static Create function without parameter anyway in a lot of places (because we often want to initialize struct with specific value by default). Therefore, we just decided to be consistent and use those static Create functions as the universal way to initialize structs to avoid confusion. Of course, you're not forced in any way to follow that convention in your project.

    There is no substantial performance cost, but indeed it's less elegant. This is necessary because trait type must be a struct to be supported by our underlying serialization system.
     
  34. beatdesign

    beatdesign

    Joined:
    Apr 3, 2015
    Posts:
    94
    I can't play the Hello world demo. Tried Kinematica 0.0.0 both with Unity 2019.4 and with 2020.1. I get this error:
    Cannot play Kinematica asset on target Biped : Binary 'D:/Projects/AIV/UnityProjects/KinematicaTest_00/Assets/StreamingAssets/KinematicaBinary_ba3871522913c8744a6ab0c114cf005d.bin' does not exist. Did you forget to buid the corresponding Kinematica asset, Assets/Samples/Kinematica/0.7.0-preview/Hello World/HelloWorld.asset ?
    UnityEngine.Debug:LogError(Object)
    Unity.Kinematica.Kinematica:OnEnable() (at Library/PackageCache/com.unity.kinematica@0.7.0-preview/Runtime/Kinematica.cs:142)​
     

    Attached Files:

  35. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Hello, the error is informing you that you need to build the Kinematica asset (HelloWorld.asset) before using it in playmode. You need to open the Kinematica Asset Builder window, open HelloWorld.asset from that window, and click on the Build button to build the asset.

    More info here : https://docs.unity3d.com/Packages/com.unity.kinematica@0.6/manual/Builder.html
     
    beatdesign likes this.
  36. grahamsaulnier

    grahamsaulnier

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    7
    Kinematica 0.8.0-preview released

    Hello everyone, this week we released a new version of Kinematica.

    The full documentation for this release is available here : https://docs.unity3d.com/Packages/com.unity.kinematica@0.8/manual/index.html (the documentation may take some time to appear in the main documentation index, they're only updated once a week).

    This release includes a number of new features but does introduce a number of API breaking changes. Users are no longer required to build a task graph in code. Instead they can directly call Kinematica API functions, simplifying the user code and offering the full feature-set of C#. The resulting execution graph can still be visualized during debugging. For more information, please see the Getting Started guide (https://docs.unity3d.com/Packages/com.unity.kinematica@0.8/manual/Getting-Started.html).

    Users of the Kinematica Demo project will need to update to the 0.8.0-preview release of the demo (available here : https://github.com/Unity-Technologies/Kinematica_Demo/releases/tag/0.8.0-preview).


    Below is the full changelog :

    ## [0.8.0-preview] - 2020-07-31


    ### Added

    - Experimental motion matching cost timeline added to the snapshot recorder


    ### Changed

    - Kinematica requires Unity 2019.4

    - Completely removed Kinematica task graph. Now, using Kinematica requires to call query functions, ideally inside jobs for performance, instead of instantiating graph in code.

    Execution graph window is still present (Window -> Analysis -> Kinematica Execution Window) and only shows debug graph related to motion matching queries.

    - Kinematica debug draw info is now mainly displayed in game & scene views, and can manipulated from the snapshot debugger. Execution graph nodes can still be selected to display specific information

    on screen, otherwise the first motion matching query happening during last frame is displayed on screen.

    - Snapshot recorder is now autoscrolled when recording

    - Execution graph and snapshot debugger UI layout and colors improved

    - Snapshot recorder can now be activated and deactivated in playmode by clicking on "Start/Stop recording" buttons.

    It's now possible to resume play from any point in the debugger timeline.

    - Kinematica doesn't requires a task graph anymore, query API is directly usable from code. Execution graph still exists for debugging

    - Added snapping to marker and tag manipulations in the timeline. Manipulating markers and tags will snap to other annotations in the timeline and to the start and end of the AnimationClip

    - Manipulating tags and markers in the timeline with previewing enabled will update the in-scene preview

    - Annotation inspectors will display start and duration times in seconds or frames depending on display setting of the timeline


    ### Fixed

    - When switching asset while previewing, target rig wasn't updated resulting in garbage pose. Target rig is now updated.

    - Fixed command and ctrl modifiers when using macos
     
    TerraUnity likes this.
  37. beatdesign

    beatdesign

    Joined:
    Apr 3, 2015
    Posts:
    94
    Thank you for your help, now everything works.
    I've another problem: I'm trying to run the parkout kinematica demo, but it doesn't work. Please help me with this.
    I used this approach:
    1. download the 0.8.0 preview from here: https://github.com/Unity-Technologies/Kinematica_Demo/releases
    2. open it with Unity 2019.4.7f1
    3. use kinematica asset builder to build Quadruped and Unit assets
    4. open Biped scene and run it
    5. I got errors (see the attachement)
    Where am I wrong?
     

    Attached Files:

  38. grahamsaulnier

    grahamsaulnier

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    7

    Hi @beatdesign,

    The error you see "Binary ... is outdated, its version.." means the .bin file in your StreamingAssets folder doesn't match what Kinematica expects. I can't see from your screenshot but can you send the full error message? Should look like this

    its version is X whereas Kinematica version is 4. Rebuild the asset to update the binary.


    Did you download the demo release into a clean folder or did you overwrite a previous download? If you overwrote a previous download it could be that the GameObjects in scene are pointing to the previous Kinematica Assets which are out of date. If you haven't created any new Kinematica assets in the project, there should only be 2 .bin files in your StreaminAssets folder (plus their meta files).
     
  39. beatdesign

    beatdesign

    Joined:
    Apr 3, 2015
    Posts:
    94
    Here are all the error I got:
    • ArgumentException: Binary 'D:/Projects/Unity/Kinematica_Demo-0.8-release/Assets/StreamingAssets/KinematicaBinary_0975eb442f465404aa2683f36f9f2d99.bin' is outdated, its version is 1936876918 whereas Kinematica version is 4. Rebuild the asset to update the binary.
      Unity.Kinematica.BinaryReference.LoadBinary () (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Binary/BinaryReference.cs:59)
      Unity.Kinematica.MotionSynthesizer.Create (Unity.Kinematica.BinaryReference binaryRef, Unity.Mathematics.AffineTransform worldRootTransform, System.Single blendDuration, Unity.Collections.Allocator allocator) (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Synthesizer/Synthesizer.cs:53)
      Unity.Kinematica.Kinematica.get_Synthesizer () (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Kinematica.cs:105)
      LocomotionAbility.OnEnable () (at Assets/Scripts/Abilities/LocomotionAbility.cs:125)
    • Cannot play Kinematica asset on target Unit : Binary 'D:/Projects/Unity/Kinematica_Demo-0.8-release/Assets/StreamingAssets/KinematicaBinary_0975eb442f465404aa2683f36f9f2d99.bin' is outdated, its version is 1936876918 whereas Kinematica version is 4. Rebuild the asset to update the binary.
      UnityEngine.Debug:LogError(Object)
      Unity.Kinematica.Kinematica:OnEnable() (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Kinematica.cs:144)
      Unit.Unit:OnEnable() (at Assets/Scripts/Unit/Unit.cs:30)
    • ArgumentException: Binary 'D:/Projects/Unity/Kinematica_Demo-0.8-release/Assets/StreamingAssets/KinematicaBinary_0975eb442f465404aa2683f36f9f2d99.bin' is outdated, its version is 1936876918 whereas Kinematica version is 4. Rebuild the asset to update the binary.
      Unity.Kinematica.BinaryReference.LoadBinary () (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Binary/BinaryReference.cs:59)
      Unity.Kinematica.MotionSynthesizer.Create (Unity.Kinematica.BinaryReference binaryRef, Unity.Mathematics.AffineTransform worldRootTransform, System.Single blendDuration, Unity.Collections.Allocator allocator) (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Synthesizer/Synthesizer.cs:53)
      Unity.Kinematica.Kinematica.get_Synthesizer () (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Kinematica.cs:105)
      Unit.Unit.OnEnable () (at Assets/Scripts/Unit/Unit.cs:36)
    • Cannot play Kinematica asset on target Quadruped_Prefab : Binary 'D:/Projects/Unity/Kinematica_Demo-0.8-release/Assets/StreamingAssets/KinematicaBinary_62504ea0b0fb2c74a872e8ccf8b7d7c2.bin' is outdated, its version is 1936876918 whereas Kinematica version is 4. Rebuild the asset to update the binary.
      UnityEngine.Debug:LogError(Object)
      Unity.Kinematica.Kinematica:OnEnable() (at Library/PackageCache/com.unity.kinematica@0.8.0-preview/Runtime/Kinematica.cs:144)

    I downloaded the demo into a clean folder, and opened it with Unity 2019.4.7f1.
    In my StreamingAssets foder there are only 2 files (see the attached img)

    Thank you for your help
     

    Attached Files:

  40. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Hello, it seems the Kinematica binaries are out of date, you need to the same thing than for the Hello World sample :

    • Open the Kinematica Asset Window
    • Select Unit.asset
    • Click on build button to build the asset
    • Do the same thing with Quadruped.asset
    Let us know if you encounter other issue !
     
  41. grahamsaulnier

    grahamsaulnier

    Unity Technologies

    Joined:
    Apr 10, 2018
    Posts:
    7
    @beatdesign I've sent you a direct message on the forum, we'll try to debug this together and I'll update the thread when we have a resolution.
     
  42. haoxiner

    haoxiner

    Joined:
    Mar 13, 2018
    Posts:
    6
    I notice the Kinematica_Demo uses BipedAvatar created from Biped.fbx, but BipedAvatar does not contains some joints like fingers (Index0_L/Index1_L... under Hand_L) in the Unit.fbx.
    If my clips have curves to animate both main joints and hand fingers, should I include these finger joints in the avatar or animate them in some other ways?
     
  43. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Hello, indeed if you want Kinematica to consider fingers curves, the destination avatar should have finger joints (Kinematica only animate the joints defined in the target avatar)
     
  44. pau1o-hs

    pau1o-hs

    Joined:
    May 16, 2017
    Posts:
    5
    Hey guys, I'm having trouble configuring my character using Short Animation sample.

    My Walk.Forward animation is restarting in the first frames, could you explain what happens and how can I fix?
    upload_2020-8-12_17-55-33.png
    I tried a lot of different values in the Kinematica asset, AssetBuilder, Biped Short, sometimes better, but with the same problem.

    The boundary clips reset, It keeps the pre and post boundary to my Idle clip, even I trying to change it

    Another thing, when I do some change in the character asset and apply, the Walk.Forward in Kinematica AssetBuilder automatically changes to the Idle clip

    Help please
    (Sorry any English errors, from Brazil)
     
  45. calpolican

    calpolican

    Joined:
    Feb 2, 2015
    Posts:
    302
    1) Since the package has reachead preview, I'd like to ask again if it has now been tested for mobile and if there are any known issues.
    2) How performant is this system compared with the current system? for what i understand, there is more processing since it has to look for the best pose match, but how much will it impact my game? and how expensive is the index in terms of memory?
    3) What would I need to change to my non-Dots project to make a migration that runs efficiently? Will I need some requirements I may not thiniking of?
    4) In the lecture it's said that the the systema is pretty much done, and that most future changes refer to how the user interacts with it. How safe is to use this system in a current project?
    5) Previously in this thread it was said that clips shorter than 1 second, like 2 frame poses would give trouble. Is that true in the present version? is there a solution for that? will it give bad results or would it just blend it linearly or what?
    6) Can this system interact with Unity's path finding navigation system?
    7) Can it add two animations, like may character walking, and my character holding a gun? Are there still masks in this system?
    8) Is this now compatible with the animation rigging package (IKs) also in preview? or will it be any time soon?
     
    Last edited: Aug 13, 2020
  46. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    The debug window shows that pose cost between current (frame 2) and best (frame 0) is zero (meaning the fragments are identical), it shouldn't be the case in order to avoid endlessly jumping back to frame 0 (pose cost should be not-null, meaning their would be a cost jumping back from frame 2 to frame 0, Kinematica would minimize cost and just keep playing animation from frame 2).

    This degenerate state happens because there is an issue with segment boundaries most of the time. Would you mind posting a screenshot of the Kinematica Asset Builder showing the locomotion segment for the Walk.Forward animation please ?

    (You can also send me your project by DM, I can have a look)
     
  47. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Hello

    1) Kinematica hasn't been yet tested on mobile, but it doesn't use any platform-specific code, so there is no reason it shouldn't work on mobile. We are now focusing on implementing all core features, we will test Kinematica on mobile and make more performance tests in the upcoming weeks after our feature set is complete. Meanwhile, should a user have an issue making Kinematica work on mobile, we would help them fix that ASAP

    2) Kinematica execution time grows linearly with the number of animation frames (and not the number of animation clips). Unless there are dozens of hours of animations to be processed for the same metric (for example locomotion), performance should be good and not much slower than animation graph of same complexity.

    Currently, Kinematica animation data is not compressed so it can indeed consumes a consequent amount of memory. For example the Kinematica binary of the humanoid (~60 bones) in the character demo contains 1 hour of animation data and takes 34 Mbytes in memory. We plan to add compression in the future.

    3) Kinematica is pure Game Object (no DOTS) for now so migration should not requires any work, Kinematica will be ported to DOTS later.

    4) We did some important changes since the lecture, but core features will be pretty much done for the next release in a few weeks. In the current release (0.8), locomotion is pretty much done, we will add the matching of events for the next release, which is the big missing piece of the puzzle.

    Kinematica is still in preview so using it right now in development might imply a few changes/minor fixes here and there (for which we would obviously provide support), but as of now the system is pretty functional (no big issues have been spotted for a while) and the tools are pretty matures, so I believe it's quite safe to use it now in development.

    5) Indeed, Kinematica discards the first and the last second of every clip (for example, Kinematica will only consider 4 seconds from a clip of 6 seconds) because for every frame, Kinematica needs to have a future trajectory of 1 second and joints transforms for the past second.

    Currently the only way to deal with that (besides having long clips) is to concatenate short animation clips one after the other in the Kinematica Asset Builder window to make longer clips (you can have a look at Short animation clips sample in the package ton get an idea). It's especially useful for loop animations, from which you use all frames with that technique.

    In the near future (next version or the one after), we will add a tool to extrapolate past joints and future trajectory, so Kinematica will be able to consider every frame from any animation clips (to the price of having an approximate future trajectory/past velocities for boundary frames, but those approximation should be pretty good for most cases).

    6) Yes absolutely, you can have a look at Navigation Sample in the package that shows a character moving along the navmesh while being animated by Kinematica.

    7) Kinematica outputs an pose and a root motion in a playable, which can therefore be combined with any other playable, including masking animations with a gun for example.

    8) We currently don't have workflow defined between Kinematica and Animation Rigging package, but we plan to look at that in the future.
     
    calpolican likes this.
  48. pau1o-hs

    pau1o-hs

    Joined:
    May 16, 2017
    Posts:
    5
    Hi, thank you so much for answering! There goes a gif

    I figured out somethings
    • I solved my problem setting Velocity Percentage to 0.5 and Desired Speed Slow to 3, but I don't get it, the description of velocity percentage says "How fast or slow the target velocity is supposed to be reached.", but it looks more like "If 0, use Speed Slow. If 1, Speed Fast".
    • The boundary clips seems to work in the BoundaryClips Selection window, but resets to Idle when I play (I'm building before, of course haha). How the boundary clips work and what clip should I put there?

    There is a new clip (Walk.Backward), but it just works if I have one of then (Idle and Walk.Forward or Idle and Walk.Backward). Could you help, please?

    upload_2020-8-13_13-26-44.png
     

    Attached Files:

  49. FrancoisFournel

    FrancoisFournel

    Unity Technologies

    Joined:
    Feb 12, 2020
    Posts:
    62
    Speed Fast is the target speed used if you pressing action button to accelerate (a kind of sprint), Speed Slow if the target speed by default.

    Your settings means that the character is meant to go from 0 to 3 m/s in 0.3 seconds, those settings should match as much as possible the animation data for Kinematica to work correctly (you can compare green and blue trajectories on screen when debugging to check if they actually match).

    The change you've made to the settings is probably closer to your animation data, which is probably the reason why it fixed your issue, but the boundaries need to be properly setup otherwise the problem might reappear.

    In your case, Walk.Forward being a loop (I assume ?) you should set Walk.Forward as its own pre and post boundary clips, same thing for Walk.Backward and Idle if they both loop. Pre and post boundary act as if you were concatenating the clip before or after the current clip. So setting Walk.Forward as pre and post boundary of itself is equivalent to repeating Walk.Forward indefinitely (this is needed otherwise Kinematica discard the first and last second of the the clip).

    I wasn't able to reproduce your issue concerning the pre/post boundary clip that reset itself while playing, would you be kind enough to file a bug please ? https://unity3d.com/unity/qa/bug-re...ke bug reporting as,if you experience a crash.

    Don't hesitate if you have other question/problem :)
     
  50. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,246
    That's a problem for me, as pretty much _all_ of my animations are from a library of clips and looped clips that need to be concatenated. They were originally designed for Humanoid (and are likely still being used for Humanoids in the same project), which makes this an enormous pain for me to move to Kinematica (workflow-wise and resource-wise), as it not only slows down the process of dealing with animation logic, but it also bloats my project (as I still need the Humanoid clip versions.)

    Is there anything being done about this potential workflow/resource issue?




    I am glad to hear that! -- You've made my day. :)



    This is why I think the Animation Rigging needs to know about Kinematica (or vice-versa).

    The 1sec trajectory issue for clips seems like it will be approximated, judging by your next comments, but in some cases (like mine, of course) 1sec is an _eternity_.
    This is going to be a recurring problem -- especially for Anime-style movement and speeds that need blending. Like in my case.
    I can see a fast backflip/sword animation (i.e. any 3d fighting game) having trouble with this 1sec blending limit, as most strikes/attacks last MUCH less than 1-2 secs.

    'Realistic' motion speeds should not be the only speeds you guys are considering with Kinematica.
    At least I hope you guys aren't excluding these kinds of animations -- Are you?
     
    GliderGuy likes this.
unityunity