KHR_materials_clearcoat_anisotropy

[MiiBond]

This extension duplicates the anisotropy of the base layer but for the clearcoat layer.

[zeux]

I've seen the nested extensions in the prior EXT_ proposal but this one is the first KHR_ one so I'll comment here. I was very surprised to see the nesting - I didn't even realize it's supported, but I will assume it is. As far as I know nesting is not used by any extension proposals that have been merged to date - this sets a new precedent.

I'm not entirely sure why this precedent is necessary to set - as far as I can tell these extensions can just live side by side with other extensions.

This changes the parsing structure for some parsing libraries in ways that I'm really not looking forward to supporting (e.g. cgltf has generic extension support via "unknown" extensions present for materials, but that will not work for sub extensions).

This introduces modeling questions for extensions that have cross-talk - what if there's some sort of physical property that is relevant for two existing material extensions that enhances this in some way?

Overall there used to be a simple rule, that a material comes with a set of extensions that each specify additional properties and textures. This rule is now less simple, and I wish this wasn't the case.

[lexaknyazev]

I didn't even realize it's supported, but I will assume it is

Every JSON object implementing glTFProperty has the extensions object.

nesting is not used

It is used with every texture slot in material extensions because of KHR_texture_transform.

[zeux]

I think the texture slots are not quite the same situation - these are nested objects with each individual object being extended, vs nested extensions that are being proposed here. That said, cgltf doesn't support unknown extensions on texture slots (it supports KHR_texture_transform as a first class but nothing else), so perhaps in some sense these are more similar.

Is there a specific reason for why these are specified as sub-extension? Following the logic, should extensions like SPZ 3DGS be a sub-extension of the base extension, should KHR_materials_volume be a sub-extension of KHR_materials_transmission, should KHR_materials_dispersion be a sub-extension of KHR_materials_volume?

What bothers me is that with textureInfo, the extension had to be specified on each individual textureInfo object. A very concrete use case was solved by adding extensions to the underlying info object - this makes material specification more complex but for a very specific reason. Here, it feels like we could easily say "extension has no effect if material doesn't carry KHR_materials_clearcoat" (which is also implied through default factor=0) and the material-level extension would have just worked, and all material extensions would be the same again. The difference is perhaps in purity of specification, but I don't see why that purity warrants making some material extensions specified differently from others.

[lexaknyazev]

There's a fine line between dependency and composition here and it might be possible to argue both ways sometimes.

For example, KHR_materials_volume needs a material that "allows light to transmit through the surface" but it does not extend the KHR_materials_transmission extension directly and can work with KHR_materials_diffuse_transmission instead.

On the other hand, this extension explicitly depends on the KHR_materials_clearcoat and its definitions as it provides additional properties of the coating layer, which does not exist without the corresponding extension.

I'd say that sub-extension design implies that dependency is so strict that breaking it would make no sense, in this case:

• an engine can't support clearcoat anisotropy without supporting base clearcoat;
• an engine supporting both extensions can't render clearcoat anisotropy properties if base clearcoat properties are not provided.

[javagl]

Only a minor aside @zeux about the nesting:

Following the logic, should extensions like SPZ 3DGS be a sub-extension of the base extension,

It is, as of the current state at https://github.com/KhronosGroup/glTF/pull/2490/files#diff-a8204f6812f8d61d54a7bee76d189bbd9ea7de2a2cbdd565d829075815554499R81 , following up from the comment at #2490 (comment)