I have a .babylon file that has morph targets which I need as a GLTF. I used the GLTFExporter from the latest CDN version of babylonjs and babylonjs serializer. When I import the GLTF file into Blender 3.3 or Blender 4.0 I get errors like this:
morph_vs = morph_vs[unique_indices]
IndexError: index 4564 is out of bounds for axis 0 with size 4564
I assume its related to the morph targets in my model (which is used for the facial expressions). Does anyone know how to get this working?
You can download the GLTF files and test it out by going to https://punkoffice.com/vfashion and clicking on the DOWNLOAD GLTF button
cc @ryantrem to check the exporter (I’m swamped this week)
1 Like
I will take a look this week. @ozRocker can you share the .Babylon file as well? I assume the gltf you shared above is the result of the GLTFExporter?
Thanx mate. The .babylon file can be found here punkoffice.com/vfashion/assets/morphs.babylon
Just a quick update, I’m looking into this and it seems like morph targets are not being exported correctly when a mesh has multiple submeshes. I’ll update the thread again when I know more or have a fix.
1 Like
This ended up requiring pretty much a rewrite of the morph targets related code in the glTFExporter. I have a PR out for this now: Rewrite morph target gltf export by ryantrem · Pull Request #15229 · BabylonJS/Babylon.js (github.com)
If you want to test out the result, here is a glb export of your Babylon scene with my changes:
morphs.glb.zip (1.3 MB)
1 Like
Oh wow you’ve completely fixed it! The morph targets on the head are all there too.
1 Like
On closer inspection I just discovered that only the first mesh (body) has retained UV mapping. The remaining 5 objects have lost their UV mapping. Do you know how I can get the UV mapping back?
1 Like
Can you share the textures for your model to help with testing and investigation?
Also, did this UV issue repro before I fixed the morph targets issue, or only after that change?
I tried using these with the original .babylon file you attached to this thread but it didn’t look like it was rendering correctly. Can you try re-saving your .babylon file with BABYLON.Texture.ForceSerializeBuffers = true;, make sure it renders as you expect in https://sandbox.babylonjs.com/, and then attach the new file?
Oh I just realised that it doesn’t work so easily. These are using texture atlases. Really sorry about wasting your time with those files. I separated the textures from the atlas and altered the .babylon file and tested it so it works without additional code. Here are the new files:
https://punkoffice.com/vfashion/newassets/avatar.babylon
https://punkoffice.com/vfashion/newassets/body.jpg
https://punkoffice.com/vfashion/newassets/eyelashes.png
https://punkoffice.com/vfashion/newassets/eyes.jpg
https://punkoffice.com/vfashion/newassets/hair.png
https://punkoffice.com/vfashion/newassets/head.jpg
https://punkoffice.com/vfashion/newassets/mouth.jpg
https://punkoffice.com/vfashion/newassets/shorts.jpg
https://punkoffice.com/vfashion/newassets/top.jpg
Thanks, this seems to be rendering as expected. I’ll try to take a closer look at the issue soon and will reply back to this thread.
On closer inspection I just discovered that only the first mesh (body) has retained UV mapping. The remaining 5 objects have lost their UV mapping. Do you know how I can get the UV mapping back?
When I export to glb and then load the glb into Sandbox, I see a model that is mostly white (except the shoes). It looks like the shoes are not white because they use vertex color. Everything else is showing up white because the original model is using StandardMaterial with emissive at fully white. When we try to convert this to a PBRMaterial for the glTF, we retain the emissive as full white and the PBR shader ends up rendering all white.
In your original Babylon scene, if I change emissive to black and diffuse to white and re-export to glb, the model then renders approximately correctly and UVs all look fine. I also noticed that the final shader is about 50% bigger, so it seems like all white emissive is resulting in some different shader defines.
I think the problem then is either:
- The standard shader is wrong
- We aren’t doing as good a job of converting from standard material to pbr material as we could
- We are doing the best conversion we can in this scenario and there isn’t a great solution on the Babylon side
I think we need @sebavan’s input on this one.
In the meantime, if you could switch from StandardMaterial to PBRMaterial in your Babylon scene that would avoid the conversion complexity and it’s highly likely everything would work exactly how you want. Alternatively, if you can avoid using emissive in your StandardMaterial I think that would also improve things.
I can fix up the shaders in Blender. If we can restore the original UV mapping then there’s enough info to re-do the materials as PBR materials.
I’ve noticed that the skeleton doesn’t come through. I have a new .babylon file punkoffice.com/vfashion/newassets/avatar_animation.babylon that includes an animation (created via the serializer). The export to GLB works but there’s no skeleton or animation when I open it. Do you know what the problem could be?
lets add @bghgary here for the gltf export.
Console logs says:
Exporting a bone without a linked transform node is currently unsupported
We don’t currently support exporting bones that didn’t come from a glTF to begin with. You can try to create linked transform nodes manually, but it is difficult to do.
1 Like
