The reading order of EXT_structural_metadata, EXT_mesh_features, and EXT_instance_features.

[LoongZP]

I used convertB3dmToGlb to convert the b3dm file to glb, but I cannot read it with gltf-transform. The error report is as follows:

The reason is that the read function of EXT_mesh_features executes before that of EXT_structural_metadata, but the read function of EXT_mesh_features depends on the results read by EXT_structural_metadata. As shown in the image below:

donmccurdy/glTF-Transform#1659 (comment) It is recommended to use the preread function.

[LoongZP]

Sorry, I haven't looked into the code of GLTFReader in gltf-transform in detail, and it seems that preread cannot solve this problem.

[javagl]

I assume that this only happens with glTF-Transform 4.0, and you are encountering this in the context of #127 .

And coincidentally, this issue is caused by a change that was introduced because of an issue that I brought up. And in that issue, @donmccurdy already said

This will have to go into v4 rather than v3.x, as the sorting (at least) is potentially a breaking change.

And we now have such a case.

I'll have to take a closer look at how this can be resolved. If you gather any insights or options, then they can be tracked here.

---

An anside: I'm usually using the tools/contentProcessing/GltfTransform.getIO() function to obtain a glTF-Transform IO object that is conveniently preconfigured with all decoders and extensions, and this function contains a note about that issue:

    // Note: The order of these calls matters. The EXTMeshFeatures and
    // EXTInstanceFeatures depend on the EXTStructuralMetadata, because
    // they may refer to PropertyTable objects via their FeatureId.
    // So the EXTStructuralMetadata has to be read first.
    io.registerExtensions([EXTStructuralMetadata]);
    io.registerExtensions([EXTMeshFeatures]);
    io.registerExtensions([EXTInstanceFeatures]);

The sorting will make this obsolete. Maybe we can just rename the implementation to AAAAA_EXTStructuralMetadata 😆 But ... more seriously... this is not the only case where extensions depend on each other, so there must be a way to solve this.

[LoongZP]

My current approach is as follows:

[LoongZP]

Maybe we need properties like prereadExtensions and prewriteExtensions and build a dependency tree from them.
Then the ordering of extensionsUsed and extensionsRequired in GLTFWriter.write doesn't seem to make sense.
This also conflicts with donmccurdy/glTF-Transform#1256

[LoongZP]

Maybe we can give extensions a weight, which determines the priority of extension reading and writing.

[javagl]

Just a short note: I have not yet looked into the update for glTF-Transform 4.0, but should have some time to do this in the next days.

You probably saw the comment at donmccurdy/glTF-Transform#1659 (comment) , but I still have to read/understand that in the context of the code.

Regarding the "weight" or "priority": There probably is no solution based on that. In theory, extensions might have mutual dependencies. (I'm not aware of any, and could imagine that this could cause a ton of trouble in many places, but I think that it is not disalowed - so the possibility probably has to be handled when trying to find a generic, robust solution...)

[javagl]

I started a draft pull request at #185 that contains the first pass of updates. Most of that was simple and rather syntactical.

Resolving the extension order issue may be a bit more tricky. I'll try to have a closer look at this soon.