Group bounding box offset from contained geometry related to geolocating model

[alberta-74]

I’ve been struggling with creating a group, closing it and then finding that the bounding box is offset from the group’s contents. I read through a number of reports of a similar sounding issue in 2025. I tried a few experiments and think I’ve found where it seems to start.

If I geolocate my model and then rotate the direction of North, it starts exhibiting the problem. Just setting the location and moving my model with respect the to map is not enough to casue the issue. I have to also rotate the direction of North. When I delete the geolocation, the problem seems to stop.

I hope that the Sketchup dev team and other users find this useful for dealing with this problem.

-Thanks

[alberta-74]

It was easy to reproduce without a model for me. That’s how I found the pattern.

1. Open a new model
2. Start a group, draw a rectangle, close the group. Click on the group and it selects as expected.
3. Go into ‘Shadows’ and click ‘Add location’. Type in an address and then rotate the direction of North. Click ‘Set Geolocation’ and close the dialog.
4. Now do #2 again and you’ll find that clicking on the new rectangle won’t select it. Press Ctrl-A to select everything and you’ll see where the bounding box for the second rectangle appears.
5. Go back into ‘Add location’ and click ‘Delete Geolocation’ and do #2 again and you’ll see that it works properly again.

I just did 1-5, above, and it did it again. I tried the above with just moving the model on the map and it didn’t do it, so it seems directly related to the rotation of North.

Hope this helps.

[alberta-74]

Sorry… Yes, this is the free web version.

[alberta-74]

Again, this is a software behavior report and isn’t related to a specific model - you can start with an empty model to see this. This is being observed in the Sketchup Web Free version. Whether it exhibits in other versions, I don’t know.

I’ve identifed several more points about this behavior.

1. After geolocating and rotating North, the problem only happens when you open a group, start drawing and then close the group. It doesn’t happen if you make a group of existing elements.
2. The offset is only in the red-green plane and not in the blue (which would be altitude). Whether you make a blue-plane, red-plane or green-plane rectangle, the boundary box corners only offset in the red and green directions.
3. You can fix the bounding box by opening the group, adding an element and then deleting it. Opening the group is tricky as you need to make a wide selection that incudes both the visible object and the invisible bounding box and then pressing the Enter or Return key. Note that you need to delete the added element in order to force a recalculation of the bounding box. When you just add the element, it just widens the invisible bounding box to include it.

Now, from a software code point-of-view (I’m a old-time SW engineer), I’d look at code that sets up a group bounding box when the group has no elements in it. The code that calculates a bounding box from a group of existing elements or after deleting an element from a group seems to work correctly.

For those experiencing this issue like me - my modeling habit is to create and draw inside of groups to keep my objects separated from one another (I even shortcutted the G key to make group and Shift+G to close group) - don’t rotate North until you’re ready to model shadows and delete your geolocation when you go back to drawing.

I hope this helps.

[colin]

I am enjoying a nice Monday off, because of a US holiday. But, I sent a link to a colleague who does QA on web, and hopefully he can reproduce the problem you see. I’m quite sure he isn’t online today! So, let’s see what he says tomorrow.

[daniel_pidcock]

@alberta-74 Thanks for the bug report, I see this also in SketchUp Desktop so this looks to be a problem in add location itself. It only reproduces if using the ‘Make Group’ option, not if I create geometry and then group it:

(from left to right, created before geolocating, created by make group on geometry, created by make group then draw geometry)

I’ll pass this onto the team that maintains add location.

Dan

[alberta-74]

That makes good sense. Particularly if the ‘make group’ action delegates to the ‘add location’ subsystem to establish the origin point for groups. If you think about it, the origin point is undefined in the scenario where make group is started without any elements. That suggests that the software isn’t fully handling that scenario when setting the initial origin.

Thanks for looking into this. I really appreciate it. In the mean time, I don’t mind waiting to geolocate until I’m ready to check shadows. My modeling has gotten a lot easier since I figured that out.

[daniel_pidcock]

Hi @alberta-74,

My colleague has just looked at this and found it’s also an issue when using the axis tool, not just add location, so this seems to be an issue for the core modeller and we’ll pass it on to the team responsible.

Dan

[alberta-74]

Another quick experiment. I tried the axes tool as well and see the problem. It looks like ‘make group’ without any elements fails to factor in the reset axes when setting the origin. It doesn’t have to be rotated at all. I suspect the rotating North is a form of changing the axes for shadows purposes of the model, but moving the model on the map does not (which make sense).

I’m now imagining (using my old-time SW engineer mind’s eye) that ‘make group’ instantiates a group object where the constructor initializes the group origin to the original model origin (0,0,0; 0 deg, 0 deg?). It then iterates through the list of currently selected elements to calculate a bounding box setting the group origin on the first element (which has the adjusted origin). If nothing is selected, the loop is never entered and the group origin never gets adjusted with respect to an altered axes. (It’s probably more complicated than that as it always is.)

1. Make a group of one object before moving the axes. All is well.

2. Move the axes down a bit aligned with the original group.

3. Do the ‘make group’ again with an object on the opposite side of the new axes. Press Ctrl-A to see where the bounding box shows up. It’s precisely where it would have been if the axes hadn’t been moved.
   
   

[colin]

@daniel_pidcock did log a bug report, SKOR-21245 in our system.

I added a screen recording and the steps to show your later example.

I’m in a meeting with the developers tomorrow, I will make sure they have seen the report.

[alberta-74]

I’m sorry to keep harping on this issue, but just when I thnk I’ve figured out how to avoid it, it happens again. I think this pinches me so frequently because of my habit of creating an empty enclosure and then putting stuff into it - you can tell I’m a SW engineer - type the { }’s then write the code between them.

It seems now that the origin point of a group is calculated (moved within the group) upon closure:

1. Turn off auto-save first. More on this in a moment.

2. Open an empty group and draw one or two things without closing the group. You can see that the axes are still where they were before you opened the group.

   

3. Close and then reopen the group. The axes have moved in relation to the group’s contents.

   

4. Now that the axes have moved, you’re set up for problems if you attempt to nest another group within that group. Do a ‘make group’ while the group is still open and draw something, close the nested group and then press Ctrl-A to see where the nested group’s bounding box appears.

   

Now, why is closure important? If you open a group and nest other groups within without closing, it seems to work correctly:

But if you close a nested group, reopen it, and then nest another group within, the bounding box is offset again:

Now, why is auto-save a factor? The above scenario happened to me while I was modeling because an auto-save happened while I was in an open group and nesting other groups within after the save. The save appears to effectively close or finalize the groups you’re in so that it can serialize your model to a file without groups being half calculated. In any of the steps above where it says close the group, you can substitute a ‘save’ and it will have the same deleterious effect.

One last note that I want to add that may or may not be related to bounding boxes. In one of the illustrations that colin or daniel posted above, I noticed that a back corner of one of the rectangles that was misbehaving was disappearing. I had a similar effect when I was experimenting and trying to figure out what was going on, but I haven’t reproduced it since. When it was happening, I found that changing the ‘Field Of View’ in ‘Scenes’ seemed to affect how much was disappearing. Working theory: If the offset bounding box ends up closer to the viewer than the rendered object on screen, the render starts to partially or wholely get clipped.

This issue is easy to reproduce, but may appear to happen inconsistently because of auto-save. If it’s also wrapped up with ‘FOV’, it may be implicated in a set of seemingly unrelated bug reports. As a former, now retired, SW Eng’ing Mgr, I’d humbly suggest making this is higher priority to at least diagnose if not fix.

As always, hope this is helpful.

[alberta-74]

Sorry to add once again, but I was able to reproduce the ‘FOV’ issue.

I created a rectangle in a group, then moved the axes and created a misbehaving one in ‘Perspective’. Then I played with the ‘FOV’ and was able to make half the rendered rectangle get clipped:

I can make it completely disappear by widening the angle:

Now, I figured I could get it back by switching to ‘Parallel Projection’, but no:

If I orbit, I can get it come back partly although there’s no ‘FOV’ control involved:

If I ‘fix’ the group by pressing enter (it’s the only thing selected), adding an element and then deleting it, it comes back in full:

I’ve experienced a glitch several times when I created elements in a group only to have them mysteriously disappear when I turn my model around.

In short, I suspect this one problem may be implicated in other bug reports about ‘disappearing groups’.

As always, hope this helps.