Unite Now - Kinematica – Democratizing Motion Matching for Character Animation

@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?

 

Wait, what?

'Announcing Kinematica: Animation meets machine learning'

Was it removed for various reasons (would be curious to know why, if so) or was there never ML?

 

The ZIP file/release doesn't contain the FBX files.

 

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.

 

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.

 

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? :/

 

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.

 

@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

 

Does this work for iOS & Android?

 

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.

 

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?

 

@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 )

 

For the most part, this is true. -- And I have. But I'm not being biased here.


See below:



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?

 

I would like to try the wolfire games method with Animation Rigging. How would I start?

 

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.

 

Thank you very much. Time to fire up google.

 

Where is the animation rigging thread anyway, we are off topic

 

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.

 

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?

 

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)​

 

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?

 

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

 

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?

 

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?

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)

 

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?

 

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?

 

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?