This one is another bug. PR for the fix here: Fix a bug with bounding box calculation when using skeleton.overrideMesh by bghgary · Pull Request #6009 · BabylonJS/Babylon.js · GitHub
You have to call refreshBoundingInfo manually for your playground to work though.
But how is this going to work in you have to manually call refreshBoundingInfo on a mesh that was author in . way where it is out of view of the camera… But i wont have control when mesh is BACK in view of camera… that would be on the game development when he move his mesh.
Otherwise ALL geometry would have to be authored in a way that the camera see them completely… And that wont work 
so why is it showing different bounding boxes, in the inspector here?
and then the scene where it refreshes the bounding boxes does not seem to do the fix.
hmmmm… I’m tired as all get out and am going to bed, but will dig more here.
This is the bug that I just fixed.
It appears my fix is still not quite right. Will continue working on it.
That was what I was wondering, because I thought it was tested after the build went through. 
Well, the fix hasn’t made it into a nightly yet.
Then nevermind! Ha, my mind has been all scrambled the last few days 
… would prolly help to look at the post timestamps.
Yes, that is already true for skinned meshes in Babylon. Skinning is done on the GPU in Babylon. We will be forced to perform skinning on the CPU to get the bounding box and thus we just let the user call it manually.
If you feel strongly about this, we can add an option to automatically do this, but there will be a perf hit.
I think im must be talking about something different. I was just saying when i use the current toolkit to export a character to a babylon scene file… I author the gut with a Y position of 6 so he is in the air. My camera is strait forward… i dont see the guy… but if i rotate my camera up… i see him just fine.
If i do that same thing with a GLTF file and i look up… some mesh parts are missing.
i thought this has to be a bug with the GLTF loader because i never had to call any kind of refresh method to load scene geometry… even out of camera sight or even disabled.
anyways… I see you working on the problem still… And thanks so much for all this help 
The issue is that the PG moves one of the nodes (which is linked to a bone in the skeleton). This is all computed on the GPU. Anyways, it’s fixed now assuming you call refreshBoundingInfo when you touch something linked to the skeleton.
Is that for the playground only… or anything i export to gltf even in my own projects ???
It’s not specific to the PG or even glTF. Skinning is computed on the GPU. Babylon doesn’t calculate the bounding box every frame for perf reasons.
Yo @bghgary … I hear ya, its just i never had to worry about this before. I just authored a scene with toolkit and the geometry showed up in babylon. Maybe it is resolved now… i don’t know. I will try my scene again with the latest builds and see what up… Thanks for the detailed explanations for me
I dont know @bghgary …
GLTF Sample: https://playground.babylonjs.com/#FIJ74I#1
Hey Gary… Man… I took that same Remy Model… Ran it thru my legacy exporter that produces .babylon scene files… Same Playground Test … But using a Remy.babylon scene file.
BABYLON Sample: https://playground.babylonjs.com/#FIJ74I#2
This show Remy with initial position up iin sky… can only see feet… wait 15 secs then it will bring him down to 0… AND HE IS ALL THERE… All the pieces, including hair.
So i don’t know… I dare to say… Something is wrong with the GLTF Importer
In the .babylon scene … I never had to go thru and refresh anything because the mesh moved into view
This is because I added a feature such that the skinning behaves exactly like how it works for glTF which is modeled closely to Unity, which I did because of your issue All the bones are now linked to the nodes in the tree and the skeleton hierarchy goes all the way up the tree to the root node. I suspect there are edge cases that don’t work when exporting from Unity to Babylon directly before. For example, if you put a non-identity transform on a skinned mesh in Unity, that should not move the skinned mesh at all since Unity ignores the transform of the skinned mesh.
In other words, in the first PG, the mesh being moved is part of the skeleton. In the second PG, the mesh being moved is not part of the skeleton.
Well that kinda changes things for me and GLTF.
First of all thanks for making that skinning fix where it behaves like Unity
I dont know what im supposed to tell the developers using the toolkit. You gotta manually call refreshBoundingInfo. And Exactly when should they call it. On every frame ???
It’s not any different than before, except that moving the skinned mesh does not move the character anymore and the parent meshes are bones now. If you would have moved the bones in the old version, it would have the same exact problem.
Users should call refreshBoundingInfo whenever a bone is moved if the scenario calls for it.
