Playground: https://playground.babylonjs.com/#99WCUQ#3
I don’t understand why the getHierarchyBoundingVectors results I get back from the top of the loaded GLB hierarchy are 100x the size of the loaded model.
The model includes a 0.01 scaling directly under the babylon __root__ GLTF support node, and I assume that’s why, but I don’t know how to correctly get the bounding information for such a model.
Any ideas what I’m doing wrong?
Can’t see the model due to CORS, and I have no experience with those two functions, but does it help to iterate through all the imported/instantiated meshes and call mesh.computeWorldMatrix(); before getting the bb info?
Here’s the PG with fixed URL so you can check out the bee hierarchy and bounding vectors (I couldn’t find a fix for the real issue yet thou). 
https://playground.babylonjs.com/#99WCUQ#4
@bghgary might be able to help but I d guess it is related to the skeleton
Sorry, this PG doesn’t work for me. The url to the glb is not valid. Is it a private repo?
The only way I could get it to work is using ImportMesh and then manually scaling the rootNode. So in this case the scaling that you have on your transform node isn’t applied to the bee mesh and needs to be done manually, but at least the bounding vectors are accurate…
https://playground.babylonjs.com/#99WCUQ#7
P.S. for @bghgary, here is the original PG with fixed URL, still using AssetContainer, where the mesh reflects the scaling but the bounding vectors don’t.
I’m not sure how it could be a problem - it’s not my repo. Maybe it worked because I went there manually so it was cached. I knew that was a common file so found someone out there that already had it hosted (it’s a default windows file).
My problem isn’t specific to the bee. I don’t need to use that mesh, but I’m accepting user uploads so who knows what other meshes have this problem. I’m assuming anything with a top level scaling transform?
Thanks Blake for fixing the example!
Checking the inspector, the Bounding Box in the first example doesn’t seem to scale with the mesh. As I haven’t really used containers, I can’t tell if this is a bug or not.
I’m guessing this is an issue with the overrideMesh property of the skeleton and instantiateHierarchy. If you don’t call instantiateHierarchy and instead call addAllToScene, it will be the correct size. This behavior is a bug IMO, but I’m not sure how to fix it. Will think on this more.
How do people normally get a reference to what was added if using something like addAllToScene instead of instantiateHierarchy, which returns the root node? I’d think getting the “last” one would be dirty even if it were reliable, and who knows what the name is on an uploaded mesh. The docs also don’t really specify if these are instanced or not via that call.
The meshes are the same ones that are in the container’s meshes array - addAllToScene doesn’t create any new meshes, it adds the meshes in the container to the scene. So the root mesh here is available at assets.meshes[0] and the bee mesh at assets.meshes[1].
https://playground.babylonjs.com/#99WCUQ#9
Ok, that’s what I expected. I think for performance I’d rather not support some files users are unlikely to use than use a dozen or more copies of non-instanced 200k models.
Considering we’re on 4.2 atm anyway, I couldn’t easily consume a fix - is there any way to reliably detect this to kick an uploaded file out?
I haven’t investigated fully yet, I believe this should only affect skinned models with non-identity scaling above the skinned mesh node.
FYI, I’m going to be on holidays soon so this issue likely won’t be resolved until next year. Sorry about that! Please let us know if this is urgent for you and we will try to find another way.
Hi @bghgary is there an issue for this yet? Do you want me to create one, if not? 
No, I haven’t gotten time to create one yet. If you can, that would be great!
Sorry for the delay. It’s been a busy month.
I haven’t figured it out yet, but in the meantime, I think you probably actually want to use assetContainer.instantiatemodelstoscene instead of instantiateHierarchy. This will duplicate the nodes, skeleton, and animation groups so that you have independent control of the instantiated model.
This should be fixed now. I wrote some documentation to explain what is happening.
glTF 2.0 skinning details by bghgary · Pull Request #462 · BabylonJS/Documentation (github.com)
EDIT: docs are live now: glTF 2.0 Skinning | Babylon.js Documentation (babylonjs.com)