I am exporting this object in gltf, but in my editor it does not correspond to what it should be.
You can see that the pivot, when I select the object, is at the center top instead of the bottom center. (it wasn’t that I faced a rotation to the object that was inside out, and suddenly the pivot can be found at the top)
And if I look at the inspector, I can see it in the object hierarchy, the root Ancien_Gate that contains a root Ancient_Gate and two primitive object.
If I select the first root and displays the gizmo with the inspector, the pivot can be found anywhere on the object to the scene of the centre at the bottom like on 3ds max. and you can see that the pivot point to the vas, which is strange.
And in the editor, logically I have a frame selection boundingbox around the object, but it does not appear.
If I export in .babylon, everything is alright. that is what which does not go with the gltf. I have the impression that it merges objects in 3ds max, export no longer works correctly after show with Babylon. Or I did something wrong, but there are inconsistencies that I don’t understand.
Whenever I have (accidentally) used multi-materials in the past, something broke - either weird coordinates, colors broken, normals not right. So I am not allowing multi-materials anymore. Anyway, I would try to assign a single material to the gate; just for testing; and see if that works.
Ok, it might indeed explain the problems and the strange hierarchy.
But with .babylon this work properly. So I think that in this kind of case the gltf is not fit if I understand correctly.
gltf does not support the materials multiple ?
I note that the boundingBox is not shown also on the selection of the object.
It appears that on the children, not on the root that encompasses all the sub objects.
I have not try with a glb, but I imagine that it will be the same problem.
In fact I find that gltf when used in an editor, it’s pretty hard to adapt. It works well to present a model or in a game, but we want to handle it in an editor, right away, it creates many problem.
So I’m going to stop using gltf and use the format of babylon which works much better.
gltf does not seem to me to adapt to a editor.
Sorry, no, I did not want to imply that It is just that whenever I used multi materials in the past issues (like yours) cropped up. Might have been mistakes I made in Blender, idk. It was not worth the trouble for me in the end.
Also keep in mind: multi materials means 1 draw call per material. I do not know Max but in Blender we usually “bake” multiple materials into a single one (i.e. 1 draw call overall).
I could not open your .gltf in the Sandbox. So I converted it, in Blender, to a binary .glb. I am currently looking at it and all Gizmo render just fine. The bounding boxes are different but that is expected because there is two meshes (gate + pillars).
Thanks for watching. I usually do it on separate objects to texture objects, it"s easier, then in the end I merge everything and that creates multi materials.
So in the sandbox, it works. But in my editor if I use pickResult.pickedMesh and Babylon"s gizmo (BABYLON.PositionGizmo), it does what I showed (gizmo move, bounding box missing…) And even if I go back to the parent, it seems to do the same thing.
Maybe the problem is with Babylon"s Gizmo. Because even with the inspector I can"t see a selection of the whole model.
But if you use a glb, maybe it makes a difference. I didn"t try. I should look at the results I have with glb.
Here"s what I do to select the objects:
initializePointerObserver() {
const excludedTypes = [
"ground",
"nodeConnectLogic",
"connectionSphereForInfoLinkLogic"
];
this.scene.onPointerObservable.add((evt) => {
if (evt.event.button !== 0) return;
const pickResult = evt.pickInfo;
if (!pickResult?.hit) return;
let pickedMesh = pickResult.pickedMesh;
if (pickedMesh.parent) pickedMesh = pickedMesh.parent; // I select the parent for the gltf, because the selection selects a child of root
const type = pickedMesh.type;
const meta = pickedMesh.metadata;
if (excludedTypes.includes(type) || !meta || meta.isGizmo) return;
this.isMultiSelect = evt.event.shiftKey || evt.event.ctrlKey;
this.handleMeshSelection(pickedMesh, null, this.isMultiSelect);
}, BABYLON.PointerEventTypes.POINTERDOWN);
}
Oh, I see. I think this could explain the missing bounding box. So if we have this hierarchy:
root (empy mesh [geometry=null)
containerNode (TransformNode)
gateDoors (Mesh)
gatePillars (Mesh)
If you select one of the two meshes, the code replaces the pickedMesh with the parent, i.e. the containerNode. But the containerNode has no geometry, so I would expect it correctly should not have a bounding box. I would expect, if you commented the “parenting” line in your code, the bounding box should show.
Also keep in mind: afaik there is no whole model anymore. The loader (I guess) splits it into n new meshes per material. But I double checked the Docs. There also is a “proper” MultiMaterial. This sounds more like what you need. If I read the docs right, it could suffice to just merge the meshes back into the original one again with the multi material flag set to true (?).
Just to add to the conversation. GLTF does not support multiple materials assign to a single mesh (the spec defines that each mesh has only a single material). My guess is that the exporter is separating the mesh into multiple meshes based on the materials assigned.
That"s where it"s problematic for a editor. Selecting a child mesh will move with the gizmo that child. The entire object will not follow.
In a publisher I"m not the only one to add models. Other future users may encounter this same problem with multi-materials.