Allow for extension-defined attribute names

[javagl]

Right now, the validator is checking whether an attribute name starts with _ (underscore) and performs a strict validation of the "known" attribute names if this is not the case. In the future, attribute names can also be prefixed with an extension name. The specification update is still pending via KhronosGroup/glTF#2514 . But there already is an extension that uses the new semantics structure (and it is currently declared as "Release Candidate"), namely, KHR_gaussian_splatting.

The following is a supposedly valid asset that is using this extension (in embedded representation):

{
  "extensionsUsed" : [ "KHR_gaussian_splatting" ],
  "accessors" : [ {
    "bufferView" : 0,
    "byteOffset" : 0,
    "componentType" : 5126,
    "count" : 8,
    "type" : "VEC3",
    "max" : [ 100.0, 100.0, 100.0 ],
    "min" : [ 0.0, 0.0, 0.0 ]
  }, {
    "bufferView" : 0,
    "byteOffset" : 128,
    "componentType" : 5126,
    "count" : 8,
    "type" : "VEC3",
    "max" : [ 1.0, 1.0, 1.0 ],
    "min" : [ 1.0, 1.0, 1.0 ]
  }, {
    "bufferView" : 0,
    "byteOffset" : 256,
    "componentType" : 5126,
    "count" : 8,
    "type" : "VEC4",
    "max" : [ 0.0, 0.0, 0.0, 1.0 ],
    "min" : [ 0.0, 0.0, 0.0, 1.0 ]
  }, {
    "bufferView" : 0,
    "byteOffset" : 384,
    "componentType" : 5126,
    "count" : 8,
    "type" : "SCALAR",
    "max" : [ 20.0 ],
    "min" : [ 20.0 ]
  }, {
    "bufferView" : 0,
    "byteOffset" : 512,
    "componentType" : 5126,
    "count" : 8,
    "type" : "VEC3",
    "max" : [ 1.7724539, 1.7724539, 1.7724539 ],
    "min" : [ 1.7724539, 1.7724539, 1.7724539 ]
  } ],
  "asset" : {
    "generator" : "JglTF from https://github.com/javagl/JglTF",
    "version" : "2.0"
  },
  "buffers" : [ {
    "uri" : "data:application/gltf-buffer;base64,AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIQgAAAAAAAAAAAADIQgAAAAAAAAAAAAAAAAAAyEIAAMhCAAAAAAAAyEIAAAAAAAAAAAAAAAAAAMhCAAAAAAAAyEIAAAAAAADIQgAAyEIAAAAAAAAAAAAAyEIAAMhCAADIQgAAAAAAAIA/AACAPwAAgD8AAAAAAACAPwAAgD8AAIA/AAAAAAAAgD8AAIA/AACAPwAAAAAAAIA/AACAPwAAgD8AAAAAAACAPwAAgD8AAIA/AAAAAAAAgD8AAIA/AACAPwAAAAAAAIA/AACAPwAAgD8AAAAAAACAPwAAgD8AAIA/AAAAAAAAAAAAAAAAAAAAAAAAgD8AAAAAAAAAAAAAAAAAAIA/AAAAAAAAAAAAAAAAAACAPwAAAAAAAAAAAAAAAAAAgD8AAAAAAAAAAAAAAAAAAIA/AAAAAAAAAAAAAAAAAACAPwAAAAAAAAAAAAAAAAAAgD8AAAAAAAAAAAAAAAAAAIA/AACgQQAAAAAAAAAAAAAAAAAAoEEAAAAAAAAAAAAAAAAAAKBBAAAAAAAAAAAAAAAAAACgQQAAAAAAAAAAAAAAAAAAoEEAAAAAAAAAAAAAAAAAAKBBAAAAAAAAAAAAAAAAAACgQQAAAAAAAAAAAAAAAAAAoEEAAAAAAAAAAAAAAADF3+I/xd/iP8Xf4j8AAAAAxd/iP8Xf4j/F3+I/AAAAAMXf4j/F3+I/xd/iPwAAAADF3+I/xd/iP8Xf4j8AAAAAxd/iP8Xf4j/F3+I/AAAAAMXf4j/F3+I/xd/iPwAAAADF3+I/xd/iP8Xf4j8AAAAAxd/iP8Xf4j/F3+I/AAAAAA==",
    "byteLength" : 640
  } ],
  "bufferViews" : [ {
    "buffer" : 0,
    "byteOffset" : 0,
    "byteLength" : 640,
    "byteStride" : 16,
    "target" : 34962
  } ],
  "meshes" : [ {
    "primitives" : [ {
      "extensions" : {
        "KHR_gaussian_splatting" : {
          "kernel" : "ellipse",
          "colorSpace" : "BT.709-sRGB",
          "sortingMethod" : "cameraDistance",
          "projection" : "perspective"
        }
      },
      "attributes" : {
        "POSITION" : 0,
        "KHR_gaussian_splatting:SCALE" : 1,
        "KHR_gaussian_splatting:ROTATION" : 2,
        "KHR_gaussian_splatting:OPACITY" : 3,
        "KHR_gaussian_splatting:SH_DEGREE_0_COEF_0" : 4
      },
      "mode" : 0
    } ]
  } ],
  "nodes" : [ {
    "mesh" : 0
  } ],
  "scene" : 0,
  "scenes" : [ {
    "nodes" : [ 0 ]
  } ]
}

It is currently generating multiple errors of the form

          {
                "code": "MESH_PRIMITIVE_INVALID_ATTRIBUTE",
                "message": "Invalid attribute name.",
                "severity": 0,
                "pointer": "/meshes/0/primitives/0/attributes/KHR_gaussian_splatting:SCALE"
            },

[lexaknyazev]

I think there are three issues here:

1. It seems too strict to call any unknown attribute an error. The spec does not say that the attributes JSON object MUST NOT contain unknown attributes; so this should likely be demoted to a warning.
2. The validator should know about the extension:attribute syntax and treat it appropriately.
3. The validator should implement support for the splats extension.

[javagl]

About 1:

I know that you know, but I'm still mentioning that the spec currently says

Application-specific attribute semantics MUST start with an underscore, e.g., _TEMPERATURE.

Given the vagueness of the term "application-specific", I have no strong opinion here. But reducing that to a 'warning' sounds reasonable. (Somehow akin to additionalProperties:true). Until now, KhronosGroup/glTF#2514 only affects the extension description. Are there plans to update the actual spec accordingly? (And how?)

---

About 2:

That's the most important one. Regardless of the role of _, philosophical considerations, and the support of the actual extension: When the rule is that this naming pattern should/must be used, and it already is used, then it may not cause an error.

---

About 3:

This is a large task. Some points are trivial, like the presence and naming of the attributes, or checking that some SH_n is present when some SH_(n-1) is present and such. Other aspects may be trickier. This is revolving around some SPLAT_SCALE_NEGATIVE or SPLAT_ROTATION_NOT_UNIT_QUTERNION and such (including possible quantizations and the corresponding epsilons that should be allowed).

(In any case, this is something to be tracked in a dedicated issue)

[lexaknyazev]

I think we could update the spec someday to highlight the following similarities:

• Core schema properties — core vertex attributes
• Additional unknown properties — unknown vertex attributes (both should cause warnings)
• Properties within extension objects — attributes prefixed by extension names
• extras — attributes starting with an underscore
• extras inside extension objects — attributes prefixed with extension names and starting with an underscore (after the colon)