Behaviour of ImportMeshAsync()

I am working with the Babylon library in an Angular web-application, in which I want to import different meshes inside my scenes. Things have went quite smoothly so far, but I have encountered a strange issue with my imported meshes.
The models I have imported were made by myself, in Blender, and exported as Wavefront .obj files. I’m importing them inside my scene with the SceneLoader.ImportMeshAsync() method. I also have to precise that, since it’s an Angular POC, everything is written in TypeScript.

The issue, or at least the strange behaviour, I’ve found is about the vertices of my imported meshes. It seems that the imported models have an immense amount of vertices, while the original ones in blender only had a few. It caused some issues, for I wanted to modify the shape of those models, by elongating some of them.
For example, the model in the picture below is made of 174 vertices in blender.

While in my Babylon application, the same model has 2088 vertices.

I have searched around the net to find any information about it, but I didn’t find anything. I have to precise that I managed to make my application work, but I’d like a lot to understand how the library works in case of other issues in the future.

I’m sorry for not being able to provide a playground, I just wasn’t sure how I could use my own models in it.

Thanks in advance for any answers, they would be greatly appreciated.

It is likely that your model in Blender is not built only with triangles? Perhaps you are using other primitives that, when converted to triangles, generate more vertices?

I don’t think so : I just tried, to be sure, and even after triangulating my faces, and having the same amount of vertices in blender, I still end up having 2160 vertices in my Babylon project…

Can you export the model to a .glb file instead? That way we could compare the number of vertices and see if it’s a problem on the Babylon.js side or if it’s Blender adding vertices to the export.

I just tried it, and exported it in my application as an glTF 2.0 (.glb) file. It seems to partially work, since I can’t get the vertices in my code anymore…
I can’t send the file in here, since it’s against the guidelines, but I can try to provide it through another mean if necessary.

Although, I have to precise that I think the additional vertices come from Babylon : when I open the .obj files with a text editor, I can see all of the vertices and their position. And at that point, the files seem to have the same amount of vertices as in Blender.

Can you share a playground with the asset? Using External Assets In the Playground | Babylon.js Documentation (

Perhaps you are calling convertToUnindexedMesh somewhere? Mesh | Babylon.js Documentation (

I tried to reproduce it in this playground (, but for some reason, the await instruction seems to not work in the playground. It’s roughly, however, how it works in my application.

And about your second point, I just checked, and I did not call convertToUnindexedMesh() anywhere…

Couple of thoughts:

In Blender, do you have modifiers that reduce the mesh verts? Like Decimate? And do you have the “Apply Modifiers” checkbox ticked in the Blender export dialog?

Are you running this in a browser, and is it possible it’s a browser caching issue? Like maybe you are seeing an outdated version of the mesh when you run it? I ran into this a lot before I started reloading the browser with Dev Tools open and the “Disable Cache” checkbox ticked (on the Network tab)

You don’t need the await instruction line 34, and the mesh you are interested in is #1, not #0 (which is a special node created by the glTF loader to convert right handed coordinates to left handed):

I get 286 vertices and 116 faces.

Are you able to provide the .obj so we can compare?

I did not use any modifiers in Blender, so I don’t think it’d come from that
For the Disable Cache part, I tried to disable it, but it didn’t solve the issue

Thanks for the thoughts though !

Oh, I didn’t know about the index having to be #1, thanks ! I’ll try to manipulate it a bit to understand how I can use it properly.
For the .obj file, I’ve added it at the following URL (3D-model-host-BabylonJS/rail.obj at main · CharlesSamamaRochegude/3D-model-host-BabylonJS · GitHub)
Although, I have to precise that it isn’t the exact same model as I’ve used in my actual application, I couldn’t hand it over. This new model had 60 vertices and 106 faces in blender. It’s the same model in the .glb and the .obj files.

Here’s a PG that loads the .obj:

The number of faces is ok (116), because there are a few faces with 4 vertices, which must be converted to 2 triangles.

The .obj loader is designed in such a way that it only reuses the data in certain cases, based on normals already found… I must say that I don’t understand how this works, but it explains why the number of vertices can be different from the number in the file.

1 Like

After adapting my own code to look like yours, I don’t see much differences… I really don’t understand why it behaves that way.
But I won’t annoy you any longer : my application still works fine, and it doesn’t seem to affect the performances. I was just wondering if anyone could help me understand why the import generates so many vertices.

Thank you very much for the time you gave me, it was very nice of you three, @Evgeni_Popov , @kloklike and @carolhmj !