Re-compute bounding boxes after subdividing a mesh

Hello :slight_smile:
I hope everyone is having good time during these Christmas holidays !

I am trying to subdivide a mesh into sub parts. This is my plan :

  • I apply a texture to the mesh (it looks like a grid with different colors)
  • I split the mesh indices into separate arrays : each color goes into his associated array
  • I make sub-meshes from these arrays
  • I delete my original mesh

I now have several sub-meshes, splitted according to their color :

My problem is they still share the same boundingInfo : the bounding box is unchanged and do not fit to the new dimension of each sub-mesh.
It is a problem because I need to get the position of each sub-mesh into the world space, but each sub-mesh is at position [0, 0, 0] and with a full bounding box.

Do you have any idea about how could I get the position of each submesh, or re-computing a bounding box to actual submesh vertex ?

Thank you in advance.

Hi Boz!

The bounding box accurately reflects the numbers in your positions array.

I manually calculated the extend size from your positions arrays and it agrees with what’s reported in the bounding info and it’s the same for each submesh. Look at this playground with debugger on. Do you think there are some extraneous points in your mesh data?

Hope that helps!


Hi flex, thanks you for replying.

Yes, bounding boxes refers to values into the positions array.
My mesh data does not contains extra data, it is correctly splitted.

The problem is during the assignment of new data inside each submesh, I guess I’m doing it wrong…
Look at the normals displayed on each submesh :

It looks like the submesh still have information about the old full mesh, even if I start with an empty VertexData object…
I am using this snippet to deconstruct the mesh, maybe it is not the correct way to do : Deconstruct A Mesh | Babylon.js Documentation

Thank you to anyone who has an idea about this.

I guess it all boils down to this:

        const newI = indices.slice(subMeshes[index].indexStart, subMeshes[index].indexStart+subMeshes[index].indexCount);
        const newN = normals.slice(subMeshes[index].verticesStart * 3, subMeshes[index].verticesStart * 3 + subMeshes[index].verticesCount * 3);
        const newP = positions.slice(subMeshes[index].verticesStart * 3, subMeshes[index].verticesStart * 3 + subMeshes[index].verticesCount * 3);
        const newU = uvs.slice(subMeshes[index].verticesStart * 2, subMeshes[index].verticesStart * 2 + subMeshes[index].verticesCount * 2);

I would think your indices array newI is all good as indices are ordered in the “parent” array but nothing guarantees it for N, P and U. you would need to manually pick the one referenced by their index and only those.

so your buffer might contain more info than needed which is not an issue for rendering.

do not hesitate if you need more help ?

1 Like

Hi @sebavan, thank you very much.

You may have right, slicing these arrays is not giving me the correct answer.
So I tried to find back the corresponding values from indices.
I updated my playground :

You can try to change the boolean value on top of the code
AUTO_FIND is true ==> previous version with correct drawing but incorrect bounding boxes
AUTO_FIND to false ==> new version with correct bounding boxes ?

In the second case, the bounding boxes seems to be approximatively correct.
Hovewer, as you can see, the model is not draw at all.

Maybe my entry .babylon model is corrupted ?
Do you think I am doing it the good way ?

I could try to change my model, thank you in advance :slight_smile:

I am pretty sure your indices are wrong in the new models.

Basically as you sequentially push pos, normals and uvs, it sounds like indices should also be remapped this way ???

1 Like

Well, I thought this is what I was doing on lines 305 to 307, but for some reason it did not deliver the expected result.

I not manually remapped these values with simply assigning the loop index to the corresponding indice in the array :

Thank you again for pointing out my errors :slight_smile: