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

Incorrect accessor error for cubic spline rotation tangents #70

Closed
bghgary opened this issue Feb 23, 2018 · 5 comments
Closed

Incorrect accessor error for cubic spline rotation tangents #70

bghgary opened this issue Feb 23, 2018 · 5 comments
Assignees
Labels
Milestone

Comments

@bghgary
Copy link

bghgary commented Feb 23, 2018

Here is the model I'm using:
https://github.com/BabylonJS/Babylon.js/blob/master/Playground/scenes/Alien/Alien.gltf

The errors being reported all look like this:

Accessor element at index 3 is not of unit length: 0.12157953455436363.

These are all quaternion rotations which are tangents of a cubic spline.

@lexaknyazev lexaknyazev self-assigned this Feb 23, 2018
@lexaknyazev lexaknyazev added this to the 2.0 milestone Feb 23, 2018
@lexaknyazev
Copy link
Member

@bghgary This issue should be resolved now. Online version updated.

@lexaknyazev
Copy link
Member

@bghgary This model has non-zero first in-tangents and last out-tangents, while the spec says that they should be zeros because they aren't used. Could you verify?

@bghgary
Copy link
Author

bghgary commented Feb 26, 2018

This model has non-zero first in-tangents and last out-tangents, while the spec says that they should be zeros because they aren't used.

Yes, I can confirm. I'm just outputting whatever Unity stores. This should be a warning in my opinion as it shouldn't break anything. For the official UnityGLTF repo, we should make sure to zero them out.

@bghgary
Copy link
Author

bghgary commented Feb 26, 2018

Feel free to close. I have verified the fix with the online version.

@lexaknyazev
Copy link
Member

This should be a warning in my opinion as it shouldn't break anything.

The reason why I didn't implement it initially is that this check could be quite cumbersome for animated morph weights because the structure of data layout depends on the number of targets and in some theoretically possible edge cases the same output accessor could be used by different meshes.

Nevertheless, I'll put this on the road-map.

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

No branches or pull requests

2 participants