Collisions seems not to work on imported gltf-meshes


I’m new to babylon.js and currently just trying some things for a project to see what is possible / what I have to do for that when I want to use babylon.js. The last two days, I’ve written an gltf-Exporter for my modelling software and imported it in babylon.js, which worked well. The only thing I can’t figure out is why I can’t activate collisions with the camera for this meshes… First, I tried:

scene.meshes.forEach(mesh => {
    mesh.checkCollisions = true;

I also tried to apply it to all child nodes of scene.meshes[0], which also does not work…
Is there any update-function I have to call after I set that checkCollisions-Attribute?

Here’s the modified collision example scene with my imported ground mesh: - the collision with the default plane works well, but my mesh is simply ignored.

Does anybody know what I’m doing wrong?


Hello and welcome to the forum!

The issue with imported geometry is generally the position of the pivot point (axis). If you inspect your scene in the application it was created, I suspect that you’ll find the pivot point is either off center, or that the scaling value is set to a value where a bounding model isn’t set properly in BJS. The solution is generally to freeze and center all transforms prior to export.

Regardless, I’m certain you’ll find the issue by inspecting the geometry in your original application and correcting there prior to export.


You were right about the pivot point, which was not the center of the meshes. However, collision detection still did not work after correcting the pivot point to the center.

So, I was also wondering why a simple cube in (0,0,0) did not interact with the camera, so I used blender to export another simple cube and compared it to my own. While the blender cube behaves correctly with the camera, my cube didn’t interact. After checking that my cube geometry was correct, I detected that the only difference is that I did not used indices. After implementing “pseodo”-indices in my gltf-exporter (that means [01,2,3,4,5,6,…]), collection detection started to work!

So my question is whether it is desired that the collision functionalities only work with indexed vertices or that this is a bug? As far as I know, the specifications of gltf 2.0 allow you to not use indices.

Edit: And thank you for your answer, which helped me to solve this problem for me!

Vertices are always indexed. However, you most likely had an issue with your normals which will not register collisions if inverted. By re-indexing your vertices, you then set your normals to be facing outward from the mesh. I hope this helps.


I’m pretty sure that my normals are correct (otherwise I would have had many other bugs much earlier in my software, shaders and other exports). Just to be safe, I tested it and inverted the normals in the export process and setup a playground-scene where cubes for all 4 cases ( correct normals / inverted normals and unindexed / indexed) are imported. For reference, there is a 5th cube created directly via the CreateBox-function to be sure the normals are correct:

Collision works both with correct normals and inverted normals when an index buffer is used, otherwise, it does not work with imported gltf-files (just tested gltf v 2.0) - just to be secure that the files differs only in the declared index buffer, I manually removed the “indices”-attribute for (1) and (3) without further changes.

If vertices are always indexed in Babylon (which I did not know), I currently think that this is an error in the gltf importer because “_indices” is simply empty when I inspect one of the meshes where no index buffer is set.

It sounds like it’s in the exporter then. Perhaps @JCPalmer can shed some light on this.


Unlike exporters directly supported by MS, Blender’s gltf exporter is not by me. It is done by Khronos. my guess is that format does not handle that. . Babylon files do. To get Pbr, you need to update to 2.80. The exporter for 2.7x is a dead code base.


I used my own gltf exporter which seems to create valid files (as long as I can rely on glTF Validator).

Nevertheless I have just tested the collision functionalities with the Khronos GLTF 2.0 Sample Models (Example “Triangle” and “TriangleWithoutIndices”, see glTF-Sample-Models/2.0 at master · KhronosGroup/glTF-Sample-Models · GitHub). Same problem here: Triangle with indices works, Triangle without indices does not work, see:

The GLTF Specifications also allow primitives without indices defined:

Implementation note: Each primitive corresponds to one WebGL draw call (engines are, of course, free to batch draw calls). When a primitive’s indices property is defined, it references the accessor to use for index data, and GL’s drawElements function should be used. When the indices property is not defined, GL’s drawArrays function should be used with a count equal to the count property of any of the accessors referenced by the attributes property (they are all equal for a given primitive).

(see glTF/specification/2.0 at master · KhronosGroup/glTF · GitHub).

So I really think that this is a bug in the gltf importer and this bug probably would be solved by simply generating indices with [0,1,2, 3,4,5, …] when imported if these are required in BabylonJS. However, it would not bother me to simply create indices when exporting, even if this slightly increases the file size. Apart from these little teething problems, BabylonJS seems to be pretty cool, and importing my own post processing effects was also pretty easy. :slight_smile: