Using glTF for Compact Transportation of Colored Geometry

[mlimper]

I'm currently trying to figure out how a valid glTF scene would look like for our default use case, which is shipping colored geometry. With X3D, we can do this easily by using the following:

<Shape>
  <Appearance>
    <Material diffuseColor='1 0 0'></Material>
  </Appearance>
  <X3DGeometryNode>
    ...
  </X3DGeometryNode>
</Shape>

(Here, X3DGeometryNode is just an abstract placeholder for some concrete X3D Geometry, such as IndexedTriangleSet)
The nice thing is that the Material node will use default values for everything and implement a simple phong material - here, we only changed the gray, default diffuse color to red.

With SRC, the idea was to use something like this instead inside the X3D scene:

<ExternalShape url="my-Binary_glTF-file.glb"></ExternalShape>

This assumes we would use the EXT_binary_glTF extension.

However, it seems quite hard to use only a subset of glTF for this purpose, especially because of the technique system. Concretely speaking, it would be nice if one could just use a default blinn/phong material, like in X3D.

Here is a stripped down version of the collada duck, which I validated against the most recent schema from the spec-1.0 branch (using the HTML validator):

{
    "accessors": {
        ...
    },    
    "bufferViews": {
        ...
    },
    "buffers": {
        ...
    },   
    "materials": {
        "blinn3-fx": {
            "instanceTechnique": {
                "technique": "my-implicit-blinn-phong-technique",
                "values": {
                    "ambient": [0,0,0,1],
                    "diffuse": [0.7,0.7,0.7,1],
                    "emission": [0,0,0,1],
                    "shininess": 38.4,
                    "specular": [0.2,0.2,0.2,1]
                }
            },
            "name": "blinn3"
        }
    },
    "meshes": {
        "LOD3spShape-lib": {
            "name": "LOD3spShape",
            "primitives": [
                {
                    "attributes": {
                        "NORMAL": "accessor_25",
                        "POSITION": "accessor_23"
                    },
                    "indices"  : "accessor_21",
                    "material" : "blinn3-fx",
                    "mode": 4
                }
            ]
        }
    }
}

full version

Although this passes validation, it is not exactly valid because of the cheap trick of using "my-implicit-blinn-phong-technique"... but what could be the solution here? I found this older thread in issue #288, the problem there seemed to similar.

The technique in the COLLADA duck example file does not seem to be minimalistic at all, but maybe there's already a valid way to get a more compact solution?

Also, note that this file passed validation although there is no scene, no nodes, etc. - not a problem for my use case, just wanted to ask if it is intended to be like this.

[mlimper]

just checked for COLLADA examples, there is at least a version in the Assimp test suite that uses a standard blinn material - not super simple, but simpler than specifying shaders etc.:
https://github.com/assimp/assimp/blob/master/test/models/Collada/duck.dae

[pjcozzi]

I think there's a couple of ways we can approach this:

• glTF profiles, e.g., geometry, material, and animation. So, for example, here you would just use the geometry profile and then the X3D appearance.
• The built-in/extenion (?) glTF materials, which are being discussed in fallbacks for techniques #84 (comment) and details property should be removed in favor of an extension #361.

Please let us know your thoughts.

Also, note that this file passed validation although there is no scene, no nodes, etc. - not a problem for my use case, just wanted to ask if it is intended to be like this.

JSON Schema doesn't have very robust validation compared to, for example, XML. We can improve this a bit by upgrading from JSON Schema 3 to 4, but we need to evaluate the tools for 4 first (#252).

[mlimper]

Thanks, I added some comment on the material stuff in #84.

Also, note that this file passed validation although there is no scene, no nodes, etc. - not a problem for my use case, just wanted to ask if it is intended to be like this.

JSON Schema doesn't have very robust validation compared to, for example, XML. We can improve this a bit by upgrading from JSON Schema 3 to 4, but we need to evaluate the tools for 4 first (#252).

Actually, I was just curious if my usage of glTF was OK - the spec-1.0 draft talks about "one or more scenes". If it does not make sense in general to have a file without a scene, I'll add one (possibly then containing nodes etc. - which would be redundant with our external scene representation).
The above example, however, shows how we would love to use (binary) glTF right now.

[pjcozzi]

We need to think through requiring scenes, materials, etc. since I think there are at least a few use cases where users will just want materials (e.g., because it is shared for many assets), geometry (e.g., because they have their own material system), etc. As I mentioned above, glTF profiles may be the way to go here instead of having lots of dummy properties, we just need to think through if this creates too much fragmentation.

[pjcozzi]

The material description is being discussed in #84.

[pjcozzi]

@mlimper can we close this given #84 and #424?

[mlimper]

Yes, thanks.