I also noted that the oversized box has the widht of the xy-diagonal of the tight box:
bounds_oversized_x = Math::Sqrt(2 * bounds_tight_x**2)
So, it seems obvious what Sketchup does, but not why. And it’s strange that the bounding box is dependent the camera.
Please do not hesitate to file a bug report in the issue tracker …
If an edge is drawn diagonally between the X and Y axis, that formula would still make the “rotary” bounding box include all content, while being based on the actual bounding box as opposed to being based directly on the geometry.
Seems to be special handling of special cases stacked on top of each other.
way back, we were informed that the ‘display’ bounds were broader so as not to be mistaken as edges by users…
and that as they were already part of the GUI, the API wasn’t designed to use them for anything more than ‘first round’ culling…
Geom::BoundingBox.new collecting target drawing elements was implemented for coding purposes…
there’s a Scott L blog or SCF post somewhere…
I’l see if I can find it, but at lot seems to have vanished in the ether…
john
OH! I was confused by @CAUL’s terminology for the topic title.
I thought he was really speaking of bounding boxes not selected boxes.
I agree, they are two separate things. And currently there is no padding control for the latter.
Just to be clear, I’m interested in the Sketchup’s internal representation, that is, the size contained in entity.bounds.
The normal graphic oversizing in the viewport is if I’m correctly informed (by @eneroth3) a constant 30px in screen space or something like that. The problem under discussion is an oversizing by a factor √2 of entitiy.bounds
This applies to the box drawn when editing a group or component, not the actual bounding box/selection box.