Hey guys.
I load my objects with the function importMeshAsync. The object also contains animations.
But I don’t get any AnimationGroup back as return value (in the Promise, the value is a empty array).
If I load the object with AppendAsync, then I get an AnimationGroup displayed.
Why don’t I get it with importMeshAsync? I need this return very much. 
Thank you for your help.
Because animation groups are at scene level and not at mesh level. You should use SceneLoader.Append to get them
Thanks for the quick reply. =)
So what are the animationGroups in the return value of the importMeshAsync function for (importMeshAsync Doc)?
These should be the animationGroups that were added by the import or was added? Or am I blind right now? 
OMG I forgot about that :). But my comment stands 
if the animation groups are targetting more than your mesh they will not be in that list
Wouldn’t it be nicer if the animationGroups contained those that concern the mesh? Would help me a lot.
After I have imported the mesh, I would like to go through it if there are animations on the mesh. But that’s not possible at the moment.
Can you repro on the PG? I want to make sure it is not a bug
Here is a funny PG =) Babylon.js Playground
In the sandbox the animations are there, in the PG they are not.
Ok so this is expected as the babylon loader does not populate that info for the reason I mentioned earlier
but replacing the importMesh with a Append works:
https://playground.babylonjs.com/#34ZCKI#1
Thank you, for the idea.
But i need the informations from the Promise in importmeshasync (mostly the meshes array) to work with the new meshes. Any idea to merge or workaround this Part?
can you work with a gltf file instead? The gltf loader may populate it actually
Could we do that in the future and switch from .babylon to .glb. But we would have to adjust some things in the system, because the __ root __ Mesh takes over some things now and not the current “MainMesh”.
For the glb I use the same import function as for the babylon. for glb the animationgroup is there and for babylon not. Wouldn’t it be more consistent to follow up here at .babylon?
PS: Will the GLTF exporter still be able to export a gltf-embedded (gltf and bin in one file)? I would like to load the gltf with gzip, like the babylon. glb is a binary and has no effect with gzip.
I agree on the consistency and if you are ok to do a PR to add it for bjs I will merge it asap.
GLTF export can generate glb which is one file with all in it and I guess the size should be in the same ballpark as a gltf+bin file
@Deltakosh Thanks for the quick reply.
I’ll try and then create a PR. =)
About GLTF export: Yes, that’s right, but I would like to use the advantage of gzip (Nginx), and in my opinion this only works with text-like files (html, babylon, js, …) and not with binaries. And gltf-embedded is “gzip”-able.
the problem is that we will not load gltf+bin embedded file 
Ahh okay. I didn’t know that. Then the question is of course obsolete =)
Can you clarify what you mean by gltf-embedded? If you mean base64-encoded buffers in a single glTF, then this is supported.
glb is a binary and has no effect with gzip
Can you explain this more? A gzipped GLB should work well if you don’t have any textures. If you do have textures, gzipping a texture just wastes time.
@bghgary Yes, base64-encoded buffers in a single gltf file.
So is the compression on the .babylon as effective as on the glb and is the transferred size similar?
If so, I would write it on my roadmap.
Assuming no textures, I would expect a gzipped glb to be best for transfer size, but it’s better to try it to be sure.
Okay. I can test it soon and write something here again.