I am trying to use Kinematic with a custom animation set.
The only thing I get so far is this error:
“Exception: Error in ReduceTask : no sequence matching the query were found in the binary”
I was building on the Biped example with a custom animation set similar to the one from the example.
I tagged all of the animations with the BipedLocomotion.Locomotion tag and the Idles additionally with the BipadLocomotion.Idle Tag.
There should be enough animations to query from although all of it is uncleaned Mocap data.
Is there any way to debug this?
Hello,
This error means there is no valid tag provided in the argument of PushConstrained() function. By valid, I mean the tag should be associated to a metric.
Can you check in the Kinematica Asset Builder window that for each LocomotionTag you can see the associated metric in the Metrics bar ? (like the metric named “Default” in the example below)

My bad. Seems like I accidentally had the wrong Locaomotion Tag selected (HelloWorld.Locomotion instead of Biped.Locomotion). So there where no metrics showing up.
It would be really handy to be able to not only bulk add but also bulk remove tags btw.
But I encountered another problem:
Animationclips added to the Asset Builder have a wrong length.
It does somehow depend on the Animation settings.
So my animation clip which is actually 38.111s ends up being cut to 29.63s when Animation compression is enabled.
As animation compression is disabled in the example files I disabled it and now the same animation is 114.33s long in the Asset builder.
Which means it is actually still only 38s of animation with no movement after that.
This does not happen with the example animations however.
Is this a bug or do I have to change a specific setting somewehere?
The animations are in 24FPS btw. I also tried to change the samplerate to 24 to try if this changes anything. It didnt help.
There is probably an issue with compressed animations in Kinematica, we will need to have a look. However, you probably should not enable compression on your animations since compression is lossy and anyway Kinematica will store uncompressed poses in the binary (Kinematica will use its own compression later).
I am still curious about why the clip duration shown in the builder is about twice as long as the real clip duration. I notice you seems to have added twice the same clip in the builder, is it true ? if yes that might explain the issue.
I added it twice to see if the same clip will get two different length depending on its import settings at the time it is added.
And yes it does:
The first one is the one without compression.
No matter how often or in which order the clip will be added it will always end up being 29s without compression and 114s with compression.
The only real difference I can find between the example animations and ours seems to be the framerate of 24FPS.
Maybe there is something wrong with resampling the animations?
Ok, would it be possible to DM me this animation (or animation that you have this issue with) by any chance (if it’s not secret material of course) ?
Ok, this is indeed an issue in our code, I will fix it in the next release of Kinematica. Meanwhile, you can fix it locally by remplacing the function ComputeAccurateClipDuration in Editor\Utilities\Utility.cs of Kinematica package by this one :
Sorry for the inconvenience !
// Unity AnimationClip can have inaccurate length when the clip is pretty long (noticeable for clip > 5 mins)
internal static float ComputeAccurateClipDuration(AnimationClip clip)
{
ModelImporter modelImporter = ModelImporter.GetAtPath(AssetDatabase.GetAssetPath(clip)) as ModelImporter;
if (modelImporter.animationCompression != ModelImporterAnimationCompression.Off)
{
Debug.Log($"Animation clip {AssetDatabase.GetAssetPath(clip)} has compression enabled, it's better to not use animation compression since it's lossy and Kinematica will uncompress animations anyway.");
return clip.length;
}
var bindings = AnimationUtility.GetCurveBindings(clip);
float frameDeltaTime = 1.0f / clip.frameRate;
int maxNumKeys = 0;
foreach (EditorCurveBinding binding in bindings)
{
AnimationCurve curve = AnimationUtility.GetEditorCurve(clip, binding);
int numKeys = curve.keys.Length;
if (numKeys > 1)
{
float firstDeltaTime = curve.keys[1].value - curve.keys[0].value;
if (!Unity.Mathematics.Missing.equalEps(firstDeltaTime, frameDeltaTime, 1e-4f))
{
continue;
}
}
maxNumKeys = Mathf.Max(numKeys, maxNumKeys);
}
int numFrames = maxNumKeys - 1;
if (numFrames <= 0)
{
return clip.length;
}
return numFrames / clip.frameRate;
}
1 Like
Great thanks for the quick fix!
I am sry to bug you again. The animation length is correct now but the character does not do anything other than idle.
I put him in the Biped example scene with the same scripts as the example character, but he does not move.
Could that be connected to the uncleaned data somehow? E.g. the offset to the characters root.
Hello, when you try to preview your animation with Kinematica Asset Builder window, can you confirm you see a correct trajectory like the example below ?
You should see past and future trajectory from character root
It does not show a trajectory indeed. The arrow is stuck at the root.
The character avatar is defined to have the hip/pelvis bone as the root though:

Do we have to edit the animations so the root transform will move with the character?
I just figured out that I may have to change the root node in the animations:
That leads to some motion in the trajectories, but still doesnt look correct:
Unfortunately the issue is due to Kinematica currently not supporting hierarchies where the first body joint (Pelvis_def) is not the first direct child of character root (HalfStep_straight_01_01).

Sorry about that, we should have made it explicit, and we will remove that limitation in the near future. Meanwhile you can fix that by either changing the hierarchy of your character in your FBX by making sure Pelvis_def is the first child :

Or your can change bodyJointIndex to 3 in AnimationRig.cs line 27
Sorry for the inconvenience !
We changed the hierarchy and reexported the animations.
Unfortunately it turned out to be more complicated than that.
We tried to mimik the example files as closely as possible:
Although the root is not the parent of the hierarchy it still has to have rootmotion.
It seems like Kinematica takes the rootmotion from the bone marked as root on the animation files (Root)
We tried to use the hip bone. This turns the character on his face though as the bone is not aligned with world space.

So we projected the hips to the ground plane in order to get a root bone the mimiks the behaviour of the example root.
Interestingly the root motion seems to be applied twice to the root bone which causes it to move around erratically in the examples. I guess this can just be ignored if the root bone is not part of the skeleton hierarchy.
Even though we tried to copy the example setup as closely as possible it still doesnt work correctly.
The trajactory is now calculated and displayed correctly but in contrast to the example character our character seems to be attached to the root node and thus has the same erritacal behaviour as the root:

Hello, sorry for the trouble you have, would mind sending me in DM you newly configured rig please ?
Just got your latest rig, it’s better but an issue remains actually :

The Pelvis joint is the second child whereas it should be the first (maybe you can rename LibraryDude_mesh as I think joints are sorted by alphabetical order)
Sorry for the inconvenience

We will fix that for next drop of Kinematica which will be released soon. This drop should be able to pick the right root joint you setup in your Avatar without needing any specific organisation of your joints. I tried it with your rig and it seems to works as expected :

1 Like
It finally works.
I misunderstood it the first time and thought the pelvis just needs to be a direct child of the character root.
Maybe it was just from my experience that the order of child objects usually doesnt matter in Unity.
We changed the order in the fbx file.
The alphanumerical sorting is weird but fortunately it can be disabled in the import settings.
Thanks for your patience!
Looking forward to the Kinematica update.
Hello FYI we just released the 0.7.0-preview which contains the fix I mentionned : [Unite Now - Kinematica – Democratizing Motion Matching for Character Animation]( Unite Now - Kinematica – Democratizing Motion Matching for Character Animation page-2#post-6038738)
Please don’t hesitate to post a message if you have any other issue 