Read- and write-access to /mesh/{meshIndex}/primitive/{primitiveIndex}/material

[hybridherbst]

For setting the material of an object, this path is needed; however I can't figure out how to correctly write that in the current implementation. My attempt is here – would appreciate some feedback! This is probably a lot easier for you @mattmacf98.

• needle-tools@ef60c1f

Here is a file that I believe to be correct:
ChangeColorSimple.glb.zip

[lexaknyazev]

That property is read-only. Arbitrary material switching is not possible in a general case.

[hybridherbst]

Mind elaborating why? Changing the material on an object is a very common operation in interactive scenes, and should in my opinion not require another dependency to KHR_materials_variants on the runtime.

[hybridherbst]

Example

Imagine a grid of 10x10 cubes with a matte black material. Clicking on any of them should turn them glossy red.

If material switching is not allowed:

• The file needs to contain 100 invidiual materials, which is bad for performance, and a lot of redundant data
• When a cube is clicked, that cube's individual material is adjusted

If material switching is allowed:

• The file contains 2 materials, which is good for performance.
• When a cube is clicked, the cube's material is switched to another material.

[lexaknyazev]

A Material <-> Mesh link is not trivial in glTF and has multiple restrictions. For example:

• A material may refer to texture coordinates not present in the mesh primitive.
• A material may require a defined tangent space but the mesh primitive may omit it.

Additionally, two arbitrary materials may require two different rendering pipelines (e.g., with or without transparency) one of which may not be ready to use when the switch occurs.

The short-term solution is the KHR_materials_variants but it has combinatorial issues so another extension may be proposed someday.

[mattmacf98]

as a potential work around for this specific case, I would suggest having a single glossy red cube and then when one of the matte black ones is clicked, hide it with node vis -> set the glossy red cube position to the position of the clicked cube -> show the glossy red cube.

Then you just have two materials and the idea of "active" on the board is based on the placement and visibility of nodes which is very well defined in the spec and not on a material of a node's mesh

[hybridherbst]

A material may refer to texture coordinates not present in the mesh primitive.
A material may require a defined tangent space but the mesh primitive may omit it.

I generally agree but glTF allows me to build files with these properties nonetheless (and it should!). These things are validator warnings, but all runtimes I'm aware of handle missing data gracefully anyways.

@mattmacf98 In the more general case here I have 10 colors to choose from, so that would be 1000 nodes at least, for being able to switch colors...

I would hope that "I have 100 cubes and they can have any of 10 colors" can somehow be achieved with 100 nodes and 10 materials in the spirit of a glTF goal being an efficient transmission and runtime format.

[lexaknyazev]

These things are validator warnings

Some of such cases are validation errors and there is no graceful way to handle them.

[mattmacf98]

resolving this as it was pulled in as a read point er (and non-normative write pointer) as part of #42