Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AnimationOptimizer too eager to early out ? #176

Open
jankrassnigg opened this issue Mar 19, 2024 · 1 comment
Open

AnimationOptimizer too eager to early out ? #176

jankrassnigg opened this issue Mar 19, 2024 · 1 comment

Comments

@jankrassnigg
Copy link
Contributor

I quickly gave AnimationOptimizer a try to see how it would optimize my animation clips, but it doesn't do anything.

It does an early out here:

  // Validates the skeleton matches the animation.
  if (num_tracks != _skeleton.num_joints()) {
    return false;
  }

My skeleton has 20 joints. The animation clip only has 18 tracks. All my animation playback etc works fine, so this data shouldn't be a problem, could it be that the AnimationOptimizer has an invalid assumption that these numbers must match?

I've attached the file that I use for testing.

Pete.zip

@guillaumeblanc
Copy link
Owner

Hi,

From ozz pipeline point a view, the number of tracks of an animation must be the same as the number of joints of the skeleton. The number of joints and tracks is the only thing allowing to "validate" that the animation matches with the skeleton.

Let's consider number of joints differs (less animation tracks than skeleton joint):

  • How do you know which track is missing, which joint isn't animated ? Little finger or leg ? The animation optimizer needs to know that because a joint close to the root isn't optimized the same way as one at the end of the chain.
  • How do you convert from local space to model space if you don't have a clear binding track <-> joint ?

The reason you don't see playback or other operations failing is that runtime operations check "soa" numbers of joints, aka multiple of 4. It seems I need to reinforce these tests.

In your case, the 2 missing tracks are set to identity by the animation sampler. So you have 2 arbitrary non-animated joints.
I'd recommend investigating how/why you end up with this 2 more tracks.

ozz import pipeline does not let this happen (unless there's a bug):

Hope it helps,
Guillaume

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants