specifying extensions

[fabrobinet]

Strawman proposal:

1. A root property like this:
   "extensions": ["extensionNameA","extensionNameB"]
2. And within a property where a extension is used something like just like for extras:
   a "extension" property.

Why not using extras for extensions ? because extras are for application specific datas, and extensions expose fonctionalities that enhances existing concepts (compressed textures etc...).

Having 1. is not strictly needed, but would be really convenient for developers. Normally a glTF asset shouldn't be generated with extensions if the target platform does not support them, but still, it is a check that is better done sooner than later.

[tparisi]

I like it.

[pjcozzi]

Why not using extras for extensions ? because extras are for application specific datas...

Agreed.

Here's an example based on your proposal, which pretends that the names match the WebGL extensions (a separate discussion):

{
    "extensions" : ["OES_standard_derivatives", "OES_element_index_uint"],
    "shaders": {
        "technique1Fs": {
            "extension" : ["OES_standard_derivatives"],
            "path": "technique1Fs.glsl"
        },
    },
    "bufferViews": {
        "bufferView_25": {
            "extension" : ["OES_element_index_uint"],
            "buffer": "duck.bin",
            "byteLength": 25272,
            "byteOffset": 76768,
            "target": "ELEMENT_ARRAY_BUFFER"
        }
    },
    // ...
}

Comments:

• By making extensions an array, we make it hard for an implementation to search for a specific extension. However, I don't think that's a problem; the most common use case will be for users to loop over them and call getExtension or cross-reference each with the return from getSupportedExtensions. Having the root extensions solves this nicely.
• Do we need (2)? I assume the use case is that an application could know what parts of the model require what extension, then could ignore them if the platform doesn't support them, but this shouldn't happen in the first place. I suppose another use case is that if part of a model is never drawn (LOD, culling, etc.), the app may never need to call getExtension, which I suspect (but never tested) has trivial overhead. It's also a bit hard to know what object to put the extension on. For example, does OES_standard_derivatives go on the shader or program? We can certainly work questions out like this if there is a need for (2).

[fabrobinet]

Actually what I was suggesting was slightly different (and it explains why you think 2. might have been useless).

On 1. i.e the array we agree.

For 2. I proposed the extension property to hold specific properties for that extension, so in your example extension would be empty, but it is was for texture compression we might get something like

[pjcozzi]

OK, I was thinking something along those lines too. For example, for EXT_texture_filter_anisotropic, is this in line with your thinking?

{
    "extensions" : ["EXT_texture_filter_anisotropic"],
    "materials": {
        "material.0": {
            "techniques": {
                "technique1": {
                    "parameters": {
                        "diffuse": {
                            "image": "image_0",
                            "magFilter": "LINEAR",
                            "minFilter": "LINEAR_MIPMAP_LINEAR",
                            "type": "SAMPLER_2D",
                            "wrapS": "REPEAT",
                            "wrapT": "REPEAT"
                            "extension" : {
                                "EXT_texture_filter_anisotropic" : {
                                    "maximumAnisotropy" : 8
                                }
                            }
                        },
// ...

If so, I'll update the spec.

[fabrobinet]

exactly !

[pjcozzi]

CC #59

[pjcozzi]

I suggest that extension be renamed extensions since it may contain more than one extension and this is consistent with extras.

[pjcozzi]

There's one issue with the current design: we can't assign extension-specific properties to the top-level glTF object.

To solve this, we could have extensions and extension as originally proposed:

"extensions" : ["one", "two"],
"extension" : {
    "one" : {
        // properties specific to "one"
    }
}

Or we could change the root-level extensions to be an object like extensions for all the sub-objects, e.g.:

"extensions" : {
    "one" : {
        // properties specific to "one"
    },
    "two" // no explicit properties defined here for "two"
}

This makes it slightly harder to validate and for the client since each property is now either a string or an object instead of always being an object, but this is what we will want in cases where extensions don't have any properties, e.g., like EXT_frag_depth. Also, this makes extensions consistent throughout glTF, e.g., it is not an array of strings at the root, and an object in sub-objects.

I suggest we make the root-level extensions an object.

[fabrobinet]

In my understanding, the value of extensions at the root level was to know upfront about all the extensions used in the asset (an overview..). So that you don't wait to parse textures or meshes to figure out if you're viewer may or not display an asset. But I understand this makes a particular case...

Note: The second example of JSON with "no explicit properties defined here for "two"" is invalid because there is no value.

I agree with you to also use extensions inside properties other than root (instead of extension) and I would use always an object and thus just {} when the extension has no parameter.

Or... as an alternative, to handle the case where an extension has no parameter would be like

"extensions" : {
    "requirements": ["one", "two"],
    "one" : {
        // properties specific to "one"
    }
}

no entry for two as it has no parameters. I am not sure about the name requirements, I just didn't want to repeat extensions...

[pjcozzi]

Instead of including the requirements property, it would be cleaner to just have an empty property, e.g.,

"extensions" : {
    "one" : {
        // properties specific to "one"
    },
    "two" : {
    }
}

Especially since many extensions will have properties specified, which makes requirements redundant.

Given this discussion, are you OK with the top-level extensions being an object at the glTF root-level just like extensions in all other glTF properties?

[fabrobinet]

@pjcozzi would the object at root be just for extensions at the root level, or would it be a special object that sums up all the extensions used in this asset (in which case an array for root would make more sense).

[pjcozzi]

would the object at root be just for extensions at the root level, or would it be a special object that sums up all the extensions used in this asset

Both. It would contain all extensions used by the asset, and properties with non-empty objects would be used at the root-level.

For example, here two extensions are defined at the root-level and used by other glTF properties (not shown).

"extensions" : {
    "one" : {
    },
    "two" : {
    }
}

Below, "one" is a root-level extension and "two" is used by other glTF properties (not shown).

"extensions" : {
    "one" : {
        // properties specific to "one" and apply to the entire asset
    },
    "two" : {
    }
}

Alternatively, we could use separate allExtensions (array) and extensions (object for root-level extensions) properties, e.g.,

"allExtensions" : ["one", "two"],
"extensions" : {
    "one" : {
        // properties specific to "one" and apply to the entire asset
    }
}

Perhaps this is cleaner?

[fabrobinet]

I like the second proposal with allExtensions better.
An alternative name could be usesExtensions or useExtensions not sure...
Anyhow, I strongly prefer that way.

[pjcozzi]

Agreed. Schema is updated. 0e7499e