Make it easier to connect a material to a mesh name inside a model

Make it easier to connect a material to a mesh name inside a model. The following is quoted verbatium from the original requester:

"There are two parts to the problem:

1) How do I know the name of the node for which I want to adjust the material
2) With what (QML) API should this be done

The node ids are known in the designers authoring tool, but as we all know, these are NOT preserved as expected through the different format converters and often get mangled. In a recent Qt3D-based project I used the scene loader's helper functions to iterate around the post-format-conversion (gltf in this case) to tell me what the node ids became. Then I could create my own QML API based around a derived class based on SceneLoader which used objectName in a Material to match the node Id and do a switch out using the Qt3D c++ API. This allowed me to write something like this:

CustomisedSceneLoader {
    source: "mymodel.gltf"

    NodeFinder { // this was just a Qt3D Entity
        objectName: "exhaust"
        components: [
            Material { // just a regular Qt3D material
                id: exhaustMaterial
                // material properties
            },
            Transform {
                id: exhaustTransform
                // I could also switch out the transform
                // this was the way I made it possible to make QML bindings into the deep node tree of the model
                // but I had issues where I couldn't easily decide whether to adopt the existing transform matrix or override it.
                // - I might have subclassed QTransformNode to add a special property to decide its behaviour perhaps.
            }
        ]
    }

The customised scene loader matched the node Id with the object name and switched out the material (and deleteLater the existing one). Actually it got a bit more complex than that as I had to do complete Entity transplants and replacements to preserve the hierarchy as I was effectively introducing additional entities I ultimately didn't need) but it does work with one
drawback - I end up recreating parts of the subtree in QML but it doesn't reflect the full subtree. But all that because a scene loader with a sub tree doesn't have a QML binding mechanism. The Qt3D Studio presentation format has this in a loose sense, but you work with known databindings instead, and you can't change out the materials. QtQuick3D goes a long way to bringing this to QML and exposing more of the scene to QML bindings but needs a more declarative approach for [replacing] the materials. One question that was raised during the QtWS is about having a visual node tree in Qt Design Studio as an inspector of the tree POST-IMPORT-conversion much like the one in Qt3D Studio. This would at least give you the Ids of things.
A Node editor (as opposed to a viewer) might open up a whole host of new possibilities e.g. re-parenting for coordinate space management. You could see also (much like the node viewer in Qt 3D Studio) where materials are referenced (shared) or not. This was something else my custom scene loader would handle - because you could use QComponent::entities on a QMaterial to get the list of references.

There is much to think about here."