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

GLTFLoader: Skinned meshes distorted #15319

Closed
3 of 13 tasks
Mugen87 opened this issue Nov 26, 2018 · 12 comments
Closed
3 of 13 tasks

GLTFLoader: Skinned meshes distorted #15319

Mugen87 opened this issue Nov 26, 2018 · 12 comments
Labels

Comments

@Mugen87
Copy link
Collaborator

Mugen87 commented Nov 26, 2018

Description of the problem

I've realized that certain glTF models like the small robot or the cesium man look distorted in dev. Could this be related to the latest changes to SkinnedMesh?

Check out the hands of the robot:
https://raw.githack.com/mrdoob/three.js/dev/examples/webgl_animation_skinning_morph.html

and the torso of the cesium man:
https://raw.githack.com/mrdoob/three.js/dev/examples/webgl_loader_gltf_extensions.html

The skinning example of FBXLoader and ColladaLoader looks fine. Same for the webgl_animation_skinning_blending which uses GLTFLoader.

Three.js version
  • Dev
  • r98
  • ...
Browser
  • All of them
  • Chrome
  • Firefox
  • Internet Explorer
OS
  • All of them
  • Windows
  • macOS
  • Linux
  • Android
  • iOS
Hardware Requirements (graphics card, VR Device, ...)
@Mugen87 Mugen87 added the Bug label Nov 26, 2018
@donmccurdy
Copy link
Collaborator

oh no 😅

screen shot 2018-11-26 at 10 36 13 am

@donmccurdy
Copy link
Collaborator

donmccurdy commented Nov 26, 2018

PR #15314 removed the call to normalizeSkinWeights() in the constructor. If I add that back, it fixes the issue for the robot model. Weights in these models are supposed to be normalized already, and at some point the glTF validator will warn about it if not. So, if there's a performance benefit to skipping the normalization by default we can just try to correct the models.

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Nov 26, 2018

PR #15314 removed the call to normalizeSkinWeights() in the constructor.

Um, I think I would add it back for now. We can still remove the call of this method at a later point.

@mrdoob
Copy link
Owner

mrdoob commented Nov 26, 2018

What's wrong with these models? They look correct to me 😜

Instead of adding the normalizeSkinWeights() back in SkinnedMesh, I would add the call in GLTFLoader instead.

@mrdoob
Copy link
Owner

mrdoob commented Nov 26, 2018

Sorry for the breakage but that part of the library sure needs some love 🙂

@Mugen87
Copy link
Collaborator Author

Mugen87 commented Nov 27, 2018

Instead of adding the normalizeSkinWeights() back in SkinnedMesh, I would add the call in GLTFLoader instead.

👍

@zeux
Copy link
Contributor

zeux commented May 30, 2019

GLTF spec says:

The joint weights for each vertex must be non-negative, and normalized to have a linear sum of 1.0. No joint may have more than one non-zero weight for a given vertex.

The side-effect of normalizeSkinWeights is that models with UNSIGNED_BYTE normalized=true weights are broken because the normalization divides all weights by ~255.

I'd like to fix this but I'm not 100% sure how. As far as I'm concerned, the call to normalizeSkinWeights is a hack that should be removed, because the models that render incorrectly violate the GLTF spec. But obviously if I just submit a PR that removes this, the "bug" will re-appear.

Re-normalizing 8-bit weights is a bit painful and (IMO) unnecessary, again, due to spec enforcing this. We could skip renormalizing unless the weights are floating-point? I'm happy to submit a PR that fixes the issue, but I'd like to understand what's the best solution first.

@donmccurdy
Copy link
Collaborator

Thank you @zeux!

I'd be happy to see that normalizeSkinWeights() call removed – as you say, spec-conformant models do not need it. Unfortunately we'll get bug reports from confused users if we do, and it will be difficult to help them – incorrect weights are arguably more common than UNSIGNED_BYTE weights today.

It will help for glTF validator to begin warning about incorrect skin weights (KhronosGroup/glTF-Validator#58), both so that users can diagnose this and so existing exporters will fix bugs. Once that happens, I'm OK with removing this use of normalizeSkinWeights entirely. Until then, it seems OK to only apply it when weights are floating-point.

/cc @bghgary should glTF-Asset-Generator cover skin weights with different component types?

/cc @lexaknyazev

@zeux
Copy link
Contributor

zeux commented May 30, 2019

I have a patch that only normalizes floating-point weights, will submit a PR momentarily. Seems like a reasonable compromise.

@bghgary
Copy link

bghgary commented May 30, 2019

should glTF-Asset-Generator cover skin weights with different component types?

You mean like this? 🤔

https://github.com/KhronosGroup/glTF-Asset-Generator/blob/master/Output/Positive/Animation_SkinType/README.md

@zeux
Copy link
Contributor

zeux commented May 30, 2019

@bghgary This is actually a perfect example :) It shows THREE.js not handling BYTE weights at the moment. #16611 should fix this.

@donmccurdy
Copy link
Collaborator

donmccurdy commented May 30, 2019

You mean like this? 🤔

Exactly like that, thanks! Guess I need to go through those tests more closely. 😅

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

5 participants