Reconsider negative skinning weights

[alecjacobson]

Thank you for the clear tutorials, specs and welcoming forum. I'd like to understand better why does the spec restrict skinning weights to be non-negative?

The joint weights for each vertex MUST NOT be negative.

Specifically, when specified with Component Type float?

I agree with this previous thread that most tools for manually authoring weights focus on non-negative weights. However, negative weights have been explored in more procedural contexts, e.g.:

1. compressing and baking mesh animations, see e.g., "Skinning Mesh Animations" and the long list of its descendants
2. procedural add-on skinning effects, see e.g., "Velocity Skinning for Real-time Stylized Skeletal Animation"
3. automatic skinning weight creation techniques, e.g., "Mean Value Coordinates", "Linear Subspace Design…"

It seems worthwhile for gltf to embrace these, other and any future exploitation of linear blend skinning in real-time animation.

Meanwhile, it appears that morph target weights are correspondingly unrestricted.

_FWIW, Negative weights can be emulated by adding more bones (+1 for any bone with a negative weight) and negating their transforms. Obviously, this potentially doubles the number of bones per mesh, and increases storage rather redundantly._

[fire]

Skinning is such a fundamental part of the core, that any change should be an extension unless it's for the next gltf version in my humble opinion.

I do not wish to have partial ecosystem support for features breaking the gltf runtime delivery promise.

[donmccurdy]

It's not obvious to me how widely negative weights can/would be supported. If neither authoring tools nor engines support this today then it's probably too early for glTF to ratify official extensions requiring the feature. But if the feature does appear likely to gain wide support then this could be rolled into a larger skinning update such as:

• https://github.com/KhronosGroup/glTF/pull/1747