I know the 3ds Max exporter is not supported anymore, but I was hoping someone knew something that could lead in a right direction to get a GLB file with animated morph targets working.
I have a 3d model which has a regular animated translation + blend shapes that are animated.
-If I used the babylon js exporter, the blend shapes gets completely broken, it seems to me the exporter does some sort of optimization or something so that the wrong vertices gets morphed.
-I can’t use 3ds max own GLB exporter, since it doesn’t support animation groups. and I could’ve used fbx but max’s native FBX doesnt support animation groups and the new “realtime exporter” in max doesn’t add keyframes to blendshapes. So nothing seem to completely work.
maybe our DCC overlord has an idea (@PatrickRyan)
Actually, I remade the mesh and applied the morph and animation and suddenly got it to work. I have no idea what was wrong, but after trying everything else that’s where I ended. And apparently it was something with the mesh that the babylon exporter disliked, despite it working fine in fbx.
I really wish someone will keep this exporter semi-alive and update it to max 2025–and forward. Because the Babylon JS exporter is SO ahead of Autodesks native exporter its not even funny, and I doubt Autodesk will do much more, based on previous experiences with Autodesk.
I’m sorry, but if anyone knows. I have a different problem now with blend shapes. It seems that blend shapes are applied based on world position. So I have a long animation of a playercard moving around divided into animation groups. And then I bend it now and then using blend shapes. But the blend shapes move the entire card back to the world rotation, instead of only offseting the vertices that are offset. Anyone knows or have experienced any of this ???
@joachim_barrum without looking at a repro, it’s hard to diagnose. However, it may be a simple fix to add a parent transform to your mesh and add any scene animations in Babylon to the parent transform. This way, your morph targets will still reference the offset from the parent transform which will make your morph target appear to use local space. Any offset you apply to the parent transform will also apply to the child morphs as well.
This is likely only one solution, but I would have to look at a repro to determine if there is another solve here.
1 Like
THank you that was an excellent suggestion! 
I tried to rebuild every card and every morph object, for some reason Babylon seem to be more picky with pivots and orientations than FBX. Even though my morph targets and cards had correct pivot it seems I hade some deep underlying 90 degree offset inside the vertex data of the morph targets that 3ds max and fbx didn’t care about by Babylon did (dunno how that even appeared) . But after rebuilding all of it it now finally works. Which is a relief, then I know that the Babylon exporter can work with all kinds of keyframes and groups. THanks a alot for good tips!
PS! Does anyone know if anyone will keep this amazing exporter updated for future releases of 3ds max? It is a shame if this exporter gets completely deprecated over time. Autodesk should just buy it and replace their own glb exporter imho since the Babylon exporter is 1000x better.
1 Like
@joachim_barrum we have not been investing in the exporters other than bug fixes because we expect Autodesk to release native glTF support and we know it’s been on their backlog. Our exporters are in a large way work arounds since there are things that glTF expects that are not mirrored in Max or Maya due to the shaders used by the software. This means we do not have the best path from mesh/material to export specifically for glTF. Our work arounds just get deeper with every glTF extension we need to support so there is a tipping point where the amount of work required to support each version of the software and support the core glTF spec and 1st-party extensions becomes too high a cost for a small team when we are also improving and maintaining Babylon.js and Babylon Native.
There are also some necessary pain points for an exporter living in a DCC tool with a render pipeline different than Babylon. We are looking into the problem as a whole to find a solution to fix all - or at least most - of the pain points in the asset authoring pipeline. Nothing I can go on record with right now, but know that we also feel your pain and are looking for a better path forward. Wish I could give you an exact solution and timeline, but we are too early for that.
Thanks for the explanation - I completely understand.
I just wish someone who knows code would have made the Babylon exporter available for new versions of Max, since you guys made the code open source. Sadly I don’t code so I can’t But I guess I’ll just hold a version of max 2024 on my machine indefinately - or until Autodesk makes their own gITF exporter good enough for me to start using it - currently it’s extremely underwhelming so I’m not holding my breath.
1 Like