Proposal: wrap index values in a new node - michaliskambi/x3d-tests GitHub Wiki

The proposal is to wrap an index field, like MFInt32 coordIndex on IndexedFaceSet, into a new node.

So instead of

IndexedFaceSet {
  coordIndex [ 0 1 2 3 ]
  ...
}

you would write

IndexedFaceSet {
  coordIndex Index {
    index [ 0 1 2 3 ]
   }
  ...
}

This looks longer, but is actually consistent with what we do for normals (Normal field), coordinates (X3DCoordinateNode, in particular Coordinate and CoordinateDouble descendants).

Concrete proposal

X3DIndexNode : X3DGeometricPropertyNode {
  SFNode [in,out] metadata NULL [X3DMetadataObject]
}

Index : X3DIndexNode {
  SFNode  [in,out] metadata NULL   [X3DMetadataObject]
  MFInt32 [in,out] index    []     (-1,∞)
}

and change fields like coordIndex, index, texCoordIndex from MFInt32 -> SFNode (X3DIndexNode allowed).

I deliberately made the name Index, not Indexes or Indices, to

1. avoid the question of which English variant we prefer :), as both "indexes" and "indices" are valid plural forms of "index" AFAIK,

2. keep it simple and consistent with others. We don't have Normals or Coordinates nodes, we have just Normal and Coordinate.

We introduce abstract X3DIndexNode along the way, to account for possible future indexes with different precision. E.g. CGE, Unity, OpenGL(ES) and glTF all allow 16-bit indexes, for performance, when mesh can fit in 65k indexes. It is conceivable that in (far) future we could introduce MFInt16 and thus Index16 node. So we want to keep this door open.

What to do with backward compatibility?

TODO: Difficult decision ahead, input welcome.

1. We force authors that upgrade from X3D 3 -> X3D 4 to also "upgrade" their index fields, and wrap them in "Index".

   Disadvantage: So far, the current design of my X3D 4 stuff means that you can "just" change the file header to say "this is X3D 4" and it will continue to work as it were in X3D 3. Forcing to wrap in "Indexes" would be a departure from this, everyone upgrading would need to process their models.

   Granted, this upgrade process X3D 3 -> X3D 4 can be automated. Still, it means that we introduce the need for such automation. Previously, there was no need for it :) This automation isn't completely trivial if your model uses extensions e.g. specific to X3DOM or CGE (the automation tool must be able to preserve them; in case of classic encoding, this means that automation tool must be able to parse them) or if you hand-crafted your X3D models, and need to preserve comments/indents etc.

2. Or we preserve compatibility. Such a mechanism would mean that we introduce new fields like coordIndexNode (SFNode), and the existing coordIndex (MFInt32) is used as a fallback.

   Disadvantage: This means that we complicate the X3D 4 spec, with a mechanism designed only to account for compatibility.

   Advantage: authors can upgrade their models with 0 effort. Just change the header to "X3D v4".