GLTFLoader: Allow multiple associations

[takahirox]

Related issue: #19359 (comment)

Description

This PR allows GLTFLoader to save multiple associations by changing from

{
  types: 'nodes',
  index: nodeIndex
}

to

{
  nodes: nodeIndex,
  meshes: meshIndex,
  primitives: primitiveIndex
}

and newly saves mesh and primitive indices.

Regarding adding mesh and primitive indices, from @donmccurdy comment #19359 (comment)

I'm OK with adding that if we have clear use cases to help us design it usefully.

My use case is I want to get mesh and primitive definitions for KHR_materials_variants extension from Three.js Mesh object because the extension definition is under primitive

https://github.com/KhronosGroup/glTF/blob/master/extensions/2.0/Khronos/KHR_materials_variants/README.md#example

and different variants can be selected after the loader parses glTF.

And a Three.js Mesh can be associated to both a node definition and mesh definition so I would like to suggest to allow multiple associations.

This change requires users who already use parser.associations to update their code because of associations data structure change. Is it ok? @cdata

BTW who should run npm run build-examples? Me and I should add examples/js/loaders/GLTFLoader.js change in this PR?

[Mugen87]

BTW who should run npm run build-examples?

I think it's okay to not include examples/js files in PRs. They can be generated from time to time directly on dev and right before a release.

[mrdoob]

/cc @elalish

[donmccurdy]

Sounds fine to me. We may want to have unit tests on this behavior.

The changed API may affect @drcmda as well.

[takahirox]

We may want to have unit tests on this behavior.

Sounds good to me. I added a unit test.

[takahirox]

@donmccurdy @cdata @elalish @drcmda

Do you think it's good to go with this change? I hope we can get it into r129.

[drcmda]

i see nothing that could be a blocker. 👍

[elalish]

It shouldn't be hard to update our code to match this, I think. And I too want to support variant editing, so I imagine I'd run into the same problem before long. I suppose it's natural that we might start associating with more parts of the glTF as we go along.

[elalish]

nit: I might change textures to texture and make the rest singular too, since we're only giving a single index.

[takahirox]

I guess the reason why they are plural is to easily access json data because they are plural in glTF json.

// The existing associations
const def = json[association.type][association.index];

// The new associations
for (const key in associations) {
  const def = json[key][associations[key]];
}

[ghost]

Just looking at this PR as I'm pondering the same issue. I'm actually doing a deeper integration of code you graciously added to Model-Viewer. I have not tried to tackle the issue in three.js code but my initial thought would be to just associate the Mesh with a glTF primitive instead of with a glTF node. Your suggestion is a nice work-around but it I'm not sure it helps in the case of a skinned mesh where there are multiple primitives per mesh (see BrainStem sample for example). It seems to me the because a three.js Mesh is associated with a glTF node (instead of a Primitive) the issue will keep arising as the format gets more complicated and tries to allow for more interaction, with Variants just being the first most obvious problem of the moment. I think the issue boils down to the fact that in glTF a Node represents transform and can hold Mesh which can have multiple primitives and in three.js a Mesh has all three but is limited to one primitive.

[mrdoob]

Thanks!