Miscellaneous spec questions

[scurest]

For Version 2.0 conformance, the glTF node hierarchy is not a directed acyclic graph (DAG) or scene graph, but a strict tree. That is, no node may be a direct or indirect descendant of more than one node.

The nodes form a forest (a disjoint union of trees), not a single tree. For example, the sample model 'Cameras' has a node graph that is a forest but not a tree. For the same reason, the term "the glTF node hierarchy" is somewhat unfortunate.

Also, saying a node cannot be the indirect descendant of multiple nodes is somewhat misleading, since in eg. a tree, a node generally does have multiple ancestors. It's the "direct descendant" part that can't happen.

---

Are the nodes referenced in scene.nodes required to be the roots of trees in the node forest? This comment suggests that they are but I'm not sure. The description for this property is

nodes | integer [1-*] | The indices of each root node.

It's not clear whether "root node" is placing a requirement that the nodes be roots in the node graph, or whether they're being called root nodes just because they're roots for this particular scene and no requirement is being imposed.

If its the former, can this be clarified, and also, this being the only occurrence of "root node" in the spec, can "root node" be defined somewhere in the text?

---

AFAICT, it is permitted for a primitive to define one but not both of the JOINTS_0 and WEIGHTS_0 attributes. Is this correct, and if so what are the semantics for skinning?

---

Implementations must use following equations to get corresponding floating-point value f from a normalized integer c and vise-versa: [table follows]

This appears in the "Animations" section. Am I correct in assuming that the spec means you must use these formulas when reading an accessor for animation data (specifically, when reading an accessor for a sampler) and not in general?

For example, when drawing a mesh, it is acceptable to use whatever glVertexAttribPointer does when its normalized parameter is true (which I believe is f = (2c + 1)/(2^b - 1) for older versions of the GL) correct? But since animation data is decoded in the implementation (rather than the GL), it's being specified what formula to use?

If so, can this be clarified?

---

According to the overview, the byteStride property is defined on an accessor, but it is actually defined in the buffer view (incidentally, the way the overview has it makes more sense to me. Why isn't it defined on an accessor?)

[javagl]

1. Forest or not

My (somewhat intuitive) understanding of all this is that each of the scenes may define a set of "root nodes", and each of these is the root of a strict tree. Most of the wording in the spec basically aims at forbidding cycles, and odd cases like this

0
+- 1
+- 2

3
+-4
+-2  // <- yuck! This was already used above, and now has two parents!

---

2. Root nodes (related to the above)

If I understood this correctly, then this referred to a case like this:

0
+- 1
|  +-2
|  +-3
|
+- 4
   +-5
   +-6

With

scenes: [{
  nodes: [ 4 ]
}]

where node 4 is not a "root node" (because it is a child node of 0), but still appears as a "root node" in the scenes.

I agree that it is not entirely clear from the spec (but I'll have to re-read the relevant parts carefully). In any case: The whole set of nodes is rather a forest, and we might consider pointing out the role of "root nodes" a bit more clearly (maybe together with rewording the part that mentions indirect descendants...)

---

3. Only one of JOINTS_0 or WEIGHTS_0

The section about nodes clearly says

When the node contains skin, all mesh.primitives must contain JOINTS_0 and WEIGHTS_0 attributes.

So I think that it is clear that if the node contains a skin, both must be present (and having only one of them is an error). When a node only has one of them, then it cannot have a skin. (I think it is safe to say that this attribute will then be ignored)

---

4. Normalized value conversion

I think what you said is correct, but this is to be confirmed by someone more involved here...

---

5. The byteStride in the accessor

This, indeed, is very unfortunate. Although the decision to move this from accessor to bufferView was made quite a while ago, I only became aware of the implications recently: #827 (comment)

(This issue in general contains some information about the reasons behind this change).

I'll probably schedule a "bugfix update" of the overview for this. In the current form, the JSON snippets shown there are basically just wrong...

[scurest]

Thanks @javagl. re. JOINTS_0 and WEIGHTS_0, nice find.

Btw, maybe I missed this too, but does a primitive require a POSITION attribute?

[lexaknyazev]

Btw, maybe I missed this too, but does a primitive require a POSITION attribute?

tl;dr
Yes for glTF 2.0 core.

Since treatment of vertex attributes could be affected by vertex shaders (e.g., think of extension with materials based on GLSL), there could be valid cases for omitting POSITION. Otherwise, there's nothing to render when POSITION isn't defined.

[lexaknyazev]

For example, when drawing a mesh, it is acceptable to use whatever glVertexAttribPointer does when its normalized parameter is true (which I believe is f = (2c + 1)/(2^b - 1) for older versions of the GL) correct? But since animation data is decoded in the implementation (rather than the GL), it's being specified what formula to use?

That's right. Note that spec-defined attribute semantics don't allow signed normalized datatypes, so their decoding isn't affected by differences in older and newer GL versions.

[lexaknyazev]

Closing this, since all questions seem to be answered and the spec has been clarified.