Bounds change depending on active context?

ittayd

I created a rectangle, grouped it and then grouped the group.

I select the inner group and print its bound's corners:

I then select the outer group and print the inner group's bounds corners again:

The values change.

My problem is that I have a point (the start of a dimension) that is then deemed outside of the bounding box of the group:

But if I open the outer group, it is OK:

How can I make sense out of this?

Dan Rathbun

Eneroth explains this somewhere here.
Basically the API is trying to "help" you out when in edit mode by converting coordinates to model space.

Personally I find it unhelpful, and unexpected because the docs don't explain it.

ittayd

I think the docs do mention returning coordinates in model space. I read "model space" to mean a global standard coordinate system. So I would expect the coordinates to never change no matter what entity is opened.

And, I wouldn't mind the coordinates changing if contains? would have acted sanely, always returning true to a point that is inside the group

Dan Rathbun

@ittayd said:

I think the docs do mention returning coordinates in model space. I read "model space" to mean a global standard coordinate system.

Because SketchUp was early on designed to create models for Google Earth, it can get confusing if we use terms like other CAD systems use, ie "World Coordinates" or "Global Coordinates". GE modelers might have taken our comments to mean in the GE space.

So, in SketchUp, each model is itself a component, that has a model axes that cannot be moved when it is opened directly. This is referenced (in all versions) by the Ruby constants ORIGIN, X_AXIS, Y_AXIS and Z_AXIS. (Do not make reassignments on these references!)

Do not confuse this with the drawing axes (called a UCS in AutoCAD.) A user can move the drawing axes anytime and the native tools will honor it, ... but the original model axes and origin remain as they were.
In 2016+ versions, an API Axes class was exposed so Ruby tools could react to the user changing the drawing axes.

When the model is opened directly in order to change the model' origin or axes, you'd need to select everything and move it, thereby changing the geometry's orientation / location with regard to the model origin/axes.

But model definitions within the model can more easily have their axes changed. If you were to insert the same model into another, it becomes a component. Right-click on the instance, and you'll see a "Change Axes" choice. If you change the instances origin/axes, it applies to the definition and all of the instances in the new parent model.
(I suppose if you then saved this component back out and overwrote the original, then you'd be changing it's model axes in a more GUI way, and without the danger of not selecting everything that needed moving. But I've never had the need to do this.)

So anyway,... we try to refer to model origin, model space or model axes, instead of "global" or "world", but you'll find some users still use those if they also still use (or came from many years in) traditional CAD.

Dan Rathbun

@ittayd said:

And, I wouldn't mind the coordinates changing if contains? would have acted sanely, always returning true to a point that is inside the group

BoundingBoxes are always aligned with the model's axes. This means if you rotate a cuboid instance, it's bounding box will increase.

The second thing you need to realize is that bounding boxes have an untransformed state (ie, the definition's entities bounds,) and each of their instances transformed bounds. The transformed bounds are not just translational, they can also be affected by the rotation and scaling of the instance.

@ittayd said:

I would expect the coordinates to never change no matter what entity is opened.

As a coder, most of time when generating geometry, you are just working in the definition's local coordinates with the IDENTITY transform, (ie, everything is 1:1 and you're specifying geometry oriented in relation to the definition's local origin and axes.)

But when the user double-clicks into an instance, that might be rotated or scaled (transparently they are actually editing the definition,) but perhaps not at the 1:1 scale.
Imagine an instance that has been scaled 2x. The user would be drawing edges that are twice as long on the screen. So their needs to be some transforming back to the definition's scale and coordinates.

Julia wrote a really good explanation of this recently (ie past few months.) Need to find this and give you the link.