You are browsing as a guest. Sign up (or log in) to start making projects!

Open comments for this post

6h 31m 34s logged

DataSet Baker V1 Alpha - HIP is in the works!!!!!

Now you might be asking why it’s named HIP, and unless you are from Canada you will most likely not know who I am going to talk about, but the motion matching editor versions are going to be named after Tragically Hip album names (the first one is self titled so HIP).

Anyways, in the last week I have gotten a lot done. I started work on actually figuring out the logic to get the trajectory out of the animation (and I don’t remember if I talked about this before but there were 2 ideas I had. 1 is I put the animation’s root motion through a lot more math to get a proper predicted trajectory just like how the input trajectory works. Or just sample the actual future, but then you would get problems like a 90 degree turn where the animation isn’t even anticipating it yet but the trajectory says it should be.)

I actually got really confused and stuck so I emailed someone. That someone is Daniel Holden, the creator of Learned Motion Matching (and he runs the website where I learned the first input trajectory math).

And WOW!!!! HE RESPONDED:

Hi Asher,

Sorry for the late reply, I have been travelling the last couple of days.

First of all I just wanted to say that it is awesome that you are looking into advanced animation techniques like these already.

(email removed for space) (i might put it in the comments if you want to read it)

I hope that helps!

All the best,

Dan

LIKE HOLY COW!!! I am talking to a LEGEND!!!!

Normal motion matching works as such: you got 2 trajectories, a predicted one from the input then a true trajectory from the animation, then you load all that animation into RAM and use a matcher to play the correct frame.

But what he made was use a neural network instead of the matcher and database WHICH SHRUNK RAM USAGE LIKE CRAZY (and I might have to get working on something like that sometime soon because RAM prices don’t appear to be dropping anytime soon).

Anyways, in the email he said that my second idea was actually right. The idea that I thought was wrong, but he says is just a sad limitation of it and nobody has figured it out yet (yet…).

So that will make life easier because I WILL BE ABLE TO FINISH THE DATASET STUFF HOPEFULLY IN A WEEK!!!!!!!

And to make that dataset I started messing around with Unity’s UI Toolkit and custom editors. So now I have several custom drop downs and then you can open the MOTION MATCHING DATASET EDITOR where you can define all of your animation clips and once I write the rest, be able to press the bake button. It will process every frame and then spit out a Scriptable Object or database.

Now hopefully writing the rest will be easier than writing the UI code because the UI stuff is powerful but not like normal runtime coding.

0
28

Comments 1

@NintedoAsh12

HERE IS THE EMAIL IF YOU WANT TO READ IT:

Hi Asher,

Sorry for the late reply, I have been travelling the last couple of days.

First of all I just wanted to say that it is awesome that you are
looking into advanced animation techniques like these already.

The short answer to your question is that we take the future trajectory
for the animation data from the true future positions of the animation.
You can see my C++ code that is doing that here:

https://github.com/orangeduck/Motion-Matching/blob/main/database.h#L444

However you make a really good observation that this isn’t really
correct, and that in an ideal world we would somehow have the goal
velocity from the original motion capture data and use this to run the
same spring-based trajectory prediction system. That is something I
discussed for a long time with my colleagues but we never really came to
a conclusion as to if there was some way to extract this goal intent
from the motion capture data (or if there was some way of capturing it
at the time of the motion capture).

Using the true future positions in the animation data means that the
shapes we get for the future trajectory in the motion capture data, and
those that are produced by the spring system at runtime never really
match exactly, and some parts of the animation database are, as a
result, very hard to match into (for example, the apprehension before a
90 degree turn).

However if your motion capture data and spring are tuned to be “close
enough” it generally works well. It’s something I discussed in this blog
post:

https://theorangeduck.com/page/code-vs-data-driven-displacement

I hope that helps!

All the best,

Dan