KhronosGroup / KhronosGroup/glTF

Skinned meshes should not be discouraged from being non-root nodes

Open
#2,625 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
HTML
Stars
7.8k
Forks
1.2k
Avg merge
17h 26m
Merged PRs (30d)
5

Description

*Alternative title: Skinned meshes should be encouraged to be placed as children of the skeleton controlling them.*

---

In the glTF ecosystem, we currently encourage placing skinned mesh nodes only at the root level.

The glTF Validator contains these warnings:

- `NODE_SKINNED_MESH_NON_ROOT`: Node with a skinned mesh is not root. Parent transforms will not affect a skinned mesh.
- `NODE_SKINNED_MESH_LOCAL_TRANSFORMS`: Local transforms will not affect a skinned mesh.

The intent of these warnings is to avoid confusion if a user transforms a mesh and does not see anything change in the scene. glTF skinned meshes have their mesh controlled entirely by the skinning, so its vertices only follow along with the joint nodes, and the vertices do not consider the transform of the mesh node at all.

Due to this nature, I proposed a PR that relaxes the existing non-root warning to "Information" severity level. But there is also a new warning that only shows up for transformed parent/ancestor nodes. This was merged, so now skinned meshes with identity-transform ancestors can exist without a "Warning", but the validator still complains. PR: https://github.com/KhronosGroup/glTF-Validator/pull/247

- `NODE_SKINNED_MESH_PARENT_TRANSFORMS`: Node with a skinned mesh has parent nodes with transforms. Parent transforms will not affect a skinned mesh.

See also this discussion: https://github.com/KhronosGroup/glTF-Validator/issues/133

---

I have always found this to be a strange recommendation. Unity, Godot, and Blender do not force a specific structure, but all of them encourage users to place skinned mesh nodes as children of the armature/skeleton. In Godot, we re-parent skinned mesh nodes on import, moving them to be direct children of the skeleton.

It's one thing if this is an implementation detail in some engines. However, **glTF 2.1** brings these challenges into the glTF ecosystem itself, and we need to have answers to these things before glTF 2.1 launches.

1. **Bounding volumes**: The use cases for these are purposefully left open-ended. An encouraged use case of bounding volumes is culling, deciding if the mesh should be rendered or not. A bounding volume placed on a node is defined relative to that node's transform. Therefore, while a skinned mesh node has its vertices not controlled by its transform, this should NOT be confused with the transform doing nothing, because with glTF 2.1 bounding volumes, it is explicitly meaningful.
- For example: If a character walks away from the origin, only moving the armature/skeleton/etc but not the skinned mesh nodes, and the camera tracks along, then as soon as the camera loses sight of the origin, the character will disappear, because the skinned mesh node's bounding volume is no longer in the camera, and gets culled. There is nothing out-of-spec with such an implementation doing that, the problem would be with the asset, or more specifically, the way the glTF ecosystem encourages the asset to be structured.

2. **External assets**: The default behavior of the glTF 2.1 external assets feature states "Once loaded, the root nodes defined by the external asset's default scene and their node hierarchies are treated as being attached as children". This means that skinned mesh nodes in an external asset would be added as children of the node using that external asset. This means that regardless of any intent for skinned mesh nodes to be standalone with their transforms, they won't be in a complex scene. Since the nodes are attached in the hierarchy anyway, it would be better to give the child asset explicit control over this, so that the skinned mesh nodes can be explicitly attached as a child of the armature/skeleton/etc.

See issue #2587 for glTF 2.1 bounding volumes and issue #2586 for glTF 2.1 external assets.

---

As a result, I think we need to do a complete 180, and take the opposite stance from the historical one. For skinned mesh nodes, instead of encouraging them to be root, we should encourage them to be non-root, and specifically a child of the skeleton.

I am not sure what should be changed besides the validator. I am also not sure if we should do more than just a removal of those warnings from the validator. Should we add a warning for the opposite case as previously, a skinned mesh node at the root? Or going further, a skinned mesh node whose parent does not match [the `skin.skeleton` property](https://github.com/KhronosGroup/glTF/blob/main/specification/2.0/schema/skin.schema.json#L14), when that property is present? Or, either of these but only show the warning for files that declare themselves as glTF 2.1, to avoid unnecessary warnings for glTF 2.0 files?

I would be interested in hearing from stakeholders in this area. Is anyone still around with the context for why the decision was originally made to discourage non-root skinned mesh nodes? Are there are any disadvantages to removing these warnings from the validator? Are there any disadvantages to encouraging non-root skinned mesh nodes, besides the possible confusion about the control of mesh vertices?

Changing this is not a hard breakage, so we could even make this change within glTF 2.0 ecosystem if we wanted to. As @lexaknyazev states below, the "stance" is not formal, it's not something stated in the spec itself.

Contributor guide

Open the contributing guide

Research direction

Start with the glTF Validator warnings named in the issue, PR #247, and discussion in issue #133; review the linked skin.schema.json and the related glTF 2.1 issues #2587 and #2586. Done means the project has an agreed position on skinned-mesh hierarchy guidance and the affected validator or specification changes are identified and addressed.

Written by the indexing model from the issue text.

Assessment

Domain
computer-graphics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.