Incorrect Bounding Info

Hello again!

I have an application that requires bounding information of meshes, regardless of their transformations (except scaling). Which means, I would like to read correctBoundingInfo.boundingBox.extendSize to output the same value regardless how it’s translated or rotated, and surely the multiplied value when scaled. (Not sure if extendSize or extendSizeWorld+transformation, but you get the point, I need to get the same width-height-depth values of the box)

The bounding related methods work well for for simple mesh hierarchies, but may fail otherwise. For years I’ve been avoiding this issue by running through child meshes, finding the maximum and minimum world vectors and then creating a new bounding info. But in this project I figure that transformations may break my method.

PG Link

Here is the link to an example. In here, an imported model from the asset library is subjected to changes in position & quaternion then its bounding is recalculated in every 5 seconds. Points to consider:

  • The initial bounding is false (see the image)
  • The bounding calculated following the first transformation after 5 seconds is correct, but when rolled back to the original it’s false (false in a different way from the initial bounding)
  • Previous two points are vice-versa if a setTimeout or onAfterRenderObservable is used for recalculations (initial and original become correct, transformed one becomes false).

PS: I’ve been trying Vector3.TransformCoordinates on root and/or child bounding vectors to find the min/max points with respect to the root mesh’s local coordinates but they didn’t work better, so I created the PG without them in order to avoid confusions.

Will be looking forward to your help :confused: Thanks!

cc @Evgeni_Popov

Maybe something like this which uses getHierarchyBoundingVectors and sets to the mesh with an identity transform. The bounding info computed in the original PG is in world space which can only be assigned to a mesh to represent the total bounding info if it is identity.

Thanks @bghgary , but is there any other way than changing the hierarchy? Maybe there is just a correct transformation needs to be applied. Also your solution does not solve the issue in my project somehow.

Another option is to change the scene to use right-handed system which will make __root__ into an identity transform. If you can explain why you need to set a bounding info for an empty root mesh, maybe there is a better way to achieve what you want.

Already using right hand system. I am trying to position an object at the picked point, and rotate it with respect to the picked normal. That part is working quite fine and the mesh can be positioned and oriented correctly. For the mesh to be snapped from “bottom (min local y) or back (min local z)”, rather than its pivot or center, I need to calculate the bounding information regardless of the mesh’s position and orientation (not scaling, but just ignoring that now).

It’s common to me that imported mesh hierarchies having a bounding of all-zero vectors on their root mesh, and refreshBoundingInfo() not working as expected. Please try this with the model in the PG. So for this reason, I’ve been manually setting the bounding info with this method in all my projects.

But when you see the following image (PG Link), you can see that the rotation of the child is naturally reflected on its bounding box; and that rotated box adds up when minimized/maximized. Looks like it’s because of the global coordinate axes. Which means, for different rotations of parent mesh, the bounding info will be inconsistent. Please try setting the rotation of the parent mesh in the PG and observe.

Sorry for flooding with too much explanation. Hopefully I could state my problem better this time :grin:

I appreciate your help, thanks again!

That sounds like what we do for gizmos. Maybe @Cedric has thoughts.

The bounding info of a mesh is just for that single mesh. It does not include the hierarchy. Setting the bounding info of a mesh to include the hierarchy is not the intended purpose. In the case of glTF, the __root__ node is only a mesh because of backwards compatibility reasons. It ideally should be a transform node which will not have bounding info.

1 Like

I’ll take a look the coming days.


BoundingBoxGizmo helped me find a workaround. It’s not an elegant solution, and does not solve assigning the correct bounding info (yet) but I will keep on working on it in the following days. If you come up with one, please share :grin:

PG Link

1 Like

I’m starting the investigation.
Using the 1st PG:
when I create a box mesh using the wheel world bounding info, I clearly see that min/max are not using the root transform.
when I set the scene to use the right hand coordinates, first bbox computed is correct but the next one is not. Letting the intervql running, it looks like 1 out of 2 bbox is correct. So, this looks like a cache issue to me. I now need to know what cache mecanism is causing that.

You know the scenegraph pretty well @sebavan , do you see a way to force refresh or see what can be the cause for the BBox to be 1 update late here?

@Evgeni_Popov, do you happen to have a bit of extra bandwith to have a look ?

I reused the PG from @bghgary and applied the inverse transform of the root to the bounding box.

It seems to work (?):


It seems to work with the PG! Please give me a couple of days till I can test with my project. I am currently abroad and don’t have my computer with me.


1 Like

I am back again :slight_smile:

There is a catch with the purpose of “reorganize” function: it needs to recompute the bounding each time it’s called. This is in order to cover some cases such as calculating the bounds of a mesh that is subjected to some transformations (my project enables the visitors to transform the meshes). However, in your PG it is calculated only once and stored. In this PG I moved the bounding-related lines to the end of the reorganize function and the issue remains.

I can surely store the info on load but I would prefer getting the bounding info on demand. Thanks again!

In this case, I think you will have to loop over the vertices of the child meshes and transform them by the parent world matrix before computing the min/max bounds, which is not very performant. If you can store the natural bounding box at start and simply transform the min/max bounds, it could be much better.

@Evgeni_Popov Alright. I think utilizing BoundingBoxGizmo is enough to tackle my problem. I appreciate all the effort, thank you sooo much!

1 Like