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

Fix bitECS loop-animation #6183

Merged
merged 1 commit into from
Aug 9, 2023
Merged

Fix bitECS loop-animation #6183

merged 1 commit into from
Aug 9, 2023

Conversation

takahirox
Copy link
Contributor

Problem

loop-animation with bitECS may not work correctly if multiple loop-animation components use the same animation name to refer to glTF.animation(s).

Root issue

Mozilla Hubs loop-animation component has a problem in the spec. A loop-animation component can refer to glTF.animations with animation names but the glTF specification allows non-unique names in glTF.animations so if there are multiple glTF.animations that have the same name no one can know what glTF.animations a loop-animation component using that names refers to.

Refer to #6153 for details.

Solution

Preprocesses glTF content before parsing to avoid the problem by adding a glTF loader plugin that converts name based animation reference in loop-animation component to index based.

Note

The old loop-animation component handler (without bitECS) seems to assume that multiple glTF.animations that have the same name have the same animation data and loop-animation refers to the first glTF.animation of the ones having the same name. The plugin follows the assumption for the compatibility, not sure if it is the best approach.

With this commit we may remove name based animation reference processing codes from the loop-animation handlers but until we are confident for the change we may keep them.

Change

  • Add a glTF loader plugin to convert name based animation reference in loop-animation component to index based.

Another approach: #6153

Copy link
Contributor

@keianhzo keianhzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think this approach is better. Ideally we should migrate this in the Blender Add-on so we hit this as little as possible.

**Problem**

loop-animation with bitECS may not work correctly if multiple
loop-animation components use the same animation name to refer
to glTF.animation(s).

**Root issue**

Mozilla Hubs loop-animation component has a problem in the spec.
A loop-animation component can refer to glTF.animations with
animation names but the glTF specification allows non-unique names
in glTF.animations so if there are multiple glTF.animations that
have the same name no one can know what glTF.animations a
loop-animation using that names refers to.

Refer to #6153 for details.

**Solution**

Preprocesses glTF content before parsing to avoid the problem by
adding a glTF loader plugin that converts name based animation
reference in loop-animation component to index based.

**Note**

The old loop-animation component handler (without bitECS) seems
to assume that multiple glTF.animations that have the same name
have the same animation data and loop-animation refers to the
first glTF.animation of the ones having the same name. The
plugin follows the assumption for the compatibility, not sure
if it is the best approach.

With this commit we may remove name based animation reference
processing codes from the loop-animation handlers but until we
are confident for the change we may keep them.

**Change**

- Add a glTF loader plugin to convert name based animation
  reference in loop-animation component to index based.
@takahirox takahirox temporarily deployed to smoke August 8, 2023 23:37 — with GitHub Actions Inactive
@takahirox takahirox merged commit 6537bb9 into master Aug 9, 2023
11 of 12 checks passed
@takahirox takahirox deleted the CompatibleLoopAnimation branch August 9, 2023 00:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-loader P1 Address as quickly as possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants