Transition Cost

[Jack-Development]

First of all, thank you so much for all your hard work. You've created some amazing research, and I enjoy reading all of your blog posts, it's taught me a lot about animating with code.

In regards to the code, within controller.cpp, Line 1633 onwards, we check the need to perform a transition, based on the difference between the new features and the current features within projector_evaluate, however, the transition_cost is set to 0 and not modified between the initialisation at the start of the function and the check, as well as this, it is never overwritten, as the projector_evaluate is only ever called once with no parameter for transition_cost.

As well as this, within my own tests, this difference is always 0 for all features, leading transition to never fire, and it leads me to consider whether there can be any optimisations made by removing these redundant checks, or whether there is an error in the implementation?

I'm currently struggle with the large changes in direction that this feature was seeming created to resolve, so any extra information would be greatly appreciated.

Jack

[orangeduck]

Hi Jack,

Yes as you guessed the purpose of this code is to prevent transitioning happening when the projected features are not very dissimilar to the current features. This avoids doing a transition when instead it would be better to just keep playing back the currently playing animation because the currently playing animation is already very close to being the best.

In the default setup for the controller, currently this feature is not used (which means it probably isn't tested and might be bugged).

Saying that I don't know why the difference might be 0 for all features. That sounds odd and like something might be wrong on your side. Certainly the Learned Motion Matching setup should function perfectly fine without this feature enabled as things are by default (like in the web demo).

Thanks,

Dan