How to get bounding box local to the parent component?

In my code, I have a hierarchy of components and to postprocess some operation I need a way to get a bounding box local to the parent.

In my most simple case, the parent component is empty and incluse a cube (which is another component). If I rotate the parent, without ever touching the cube, the cube bounding box stay aligned with the world axis.

Is there any way to get the bounding box which uses the axis of the parent ?

Here is the code, I used to check the behavior, here the parent is simply rotated 45° from the origin.

(0..7).map{ |i| cube.bounds.corner(i)}

[Point3d(-0.707107, -0.707107, -0.5), Point3d(0.707107, -0.707107, -0.5), Point3d(-0.707107, 0.707107, -0.5), Point3d(0.707107, 0.707107, -0.5), Point3d(-0.707107, -0.707107, 0.5), Point3d(0.707107, -0.707107, 0.5), Point3d(-0.707107, 0.707107, 0.5), Point3d(0.707107, 0.707107, 0.5)]

Here, for the unit cube, the x & y bounds should be either -0.5 or 0.5.

SketchUp Ruby API: Geom::BoundingBox says:

Bounding boxes are three-dimensional boxes (eight corners), aligned with the global axes, that surround entities within your model.

You should likely be more concerned with the transformations of component instances.
See: Geom::Transformation

BTW: Don’t confound UI highlight boxes with the API’s Geom::BoundingBox objects.

If the user is within the editing context of the outer wrapping instance, or the inner cube instance, then you can get the editing “breadcrumb” path:


gives an array (or nil if not in an editing context), ie:


But if the user is not in an editing context, you cannot “walk” back up the hierarchy from some arbitrarily chosen nested object that is not being edited nor is selected. This is because instances do not “own” entities collections. Only definitions have entities collections. (If you drill down into any of the “outer” instances in the model, and inspect the nested “cube” instance, it will always be the same exact object with the same id number, no matter which one of the “outer” instances you drill into.)

If you have a reference to one of the nested cubes, you have a reference to all of them. Try pushing it into the selection set:
… and you’ll see every one of them is highlighted.

Because, in reality, there is only one cube. It is a member of the entities collection of the definition of the “outer” component instance.

hi @DanRathbun, thank you for your answer.

I think I grasp correctly the difference between instance and definition, and its consequences (like “no walk up”).

I did find a work around using matrices but it is a shame I cannot use bouding boxes because they are not composable (or usable with component hierarchy). They were the easiest abstraction in my use case.

I got tripped because the bbox of an object can change without any action on it (moved the parent, didn’t touch the child). It breaks the isolation principle between components.

Beside, the default is illogical. It is very easy to build the globally aligned bbox from a local bbox. The opposite is impossible because information has been destroyed.

Any way, thank you for you patience.