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.
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.
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.
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?
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.
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.
@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.
https://playground.babylonjs.com/#GN9BNW#14 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
how is it breaking for you ?
