Subdividing Mesh and Updating Octree on a Imported GLB/GLTF causes Memory Crash?

So I have a setup where we are importing a GLB as an asset container, initializing it in the scene and then creating instances of it where we are doing a scene.pick method on those objects for specific reasons.

the subdivision works fine, but the updateOctree stuff seems to cause the scene to crash. It works with “newalex.gltf” but not with any of the glbs/gltfs that my artist is exporting from blender?

If you comment out line 12 and uncomment one line out of 9 - 11 you will see the scene crash.

What could be possibly causing this hang?

I tried uncommenting one of the lines and got this on my console:

I can get the same thing to happen with a veeeeery segmented sphere: Babylon.js Playground (

So how do we address this then? Is it just out of scope or is there a way to accommodate things? I think the meshes I was trying to do it to were under 10k total vertices when you add up the entire gltf.

You should not try to subdivide instances.

Try to subdivide first before creating the instances.

In your case I would disable the picking on the mesh itself and add invisible catchers really low poly for picking to prevent slowing down rendering with subdivide.

Ill try that, but I was able to do it on a super subdivided plane no problem.

Also I’m not subdividing the instances, I’m subdividing the sourceMesh.

I also will not be able to disable the picking on the mesh itself we are drawing on them which is the whole point for the pick on them.

I will try to subdivide it before creating the instance though, that does not seem to be the problem its the octree that is giving the hang as far as I can tell. But ill follow your advice on doing that before I instance it and see if that works.

Nope that did not make a difference. Its as soon as you try to calculate the octree stuff crashes either way.

even doing scene.createOrUpdateSelectionOctree is freezing up on an unmodified glb/gltf.

uncomment line 41

You might subdivide several time then. works fine for me :frowning: how is it breaking for you ?

Hmmm, but then it loaded on the second refresh… wtf…

Why is this not working then? (uncomment line 41)
But this is:

they are essentially the same thing.

@sebavan bump
Sorry to bug you on this, but I’m really kind stumped about why this is happening.

This is a memory issue, I ll have a look later but in your case, I would favor using invisible catchers to have even more perfs out ?

I cant, its for drawing directly on the meshes and there will be no way to build those simplified meshes on the fly.

Im doing a 3d Drawing app, in frame where one of the requirements we want is to be able to draw on the environments walls and floors which works well, but id like to optimize the octree picking some because in the past Ive been able to use that to make things work quite a bit better.

And why is the plane that is being subdivided to an amount way more than the glb able to get through?

Something seems sus.

because this is 300k some vertices that is subdivided 100 times and still having it work just fine.

That is way bigger than anything in the glb Im trying to do it to.

Understood may you would need 2 versions of the mesh then a sudbivided invisible one for picking and the visible merged one for rendering as increasing your number of draw calls with subdivisions might have a negative impact on your perfs.

I ll have a look later for the octree.

thank you sir, its not a show stopper it just makes me suspect that there is something not right considering the two examples are for all practical purposes the same thing and one works but one does not.

I appreciate you <3

@Pryme8 you are chosing 32 for depth hence a max amount of octree blocks of 7.922816251426434e+28… this is way too large. the default at 2 is already creating a max amount of 64 blocks and 5 would be 32768.

The mesh in you case filling most of the space would force going full depth in almost all blocks so you will never have enough memory.

1 Like

Ill see if that fixes it.

Nope that still does not fix it.

Also the fact the plane that is way larger then the glb can handle those numbers leads me to think there is something else at work here. this works and the plane is not reference in all the octree forcing them to go pretty deep so it would in the end keep a reasonable depth in most octex

You are a gentleman and a scholar. Sorry to be dense on this, I appreciate you.

1 Like