Recreating component editing bounding box with padding

Hi all,

I’ve been playing a little with recreating the bounding box displayed around the group/component being open for editing, including that nice little padding that allows you to distinguish these lines from the actual geometry.

I thought other developers could find this useful, as these perspective effects are a large part of the SketchUp UI.

This is a quite crude example that does too much stuff in the draw method, rather than caching the results, but shows how you can translate a pixel size at a given point into a physical length in the model, and then use that length to draw to the screen. The same principle is used for the Scale Tool handles, the Protractor and various other things.

Native bounds:

My recreation (with other color and stipple):

class HighlightBox  
  def draw(view)
    bounds = Sketchup.active_model.selection.first.bounds
    # Extend the bounds in every direction with the distance corresponding to
    # 30 px on the screen at the bounding box center.
    padding = view.pixels_to_model(30,
    bounds.add(bounds.max.offset(, padding, padding)))
    bounds.add(bounds.min.offset(, -padding, -padding)))
    view.drawing_color = "Magenta"
    view.draw(GL_LINES, bound_lines(bounds))
  def bound_lines(bounds)
    points = { |i| bounds.corner(i) }
    lines = [
      points[0], points[1],
      points[2], points[3],
      points[0], points[2],
      points[1], points[3],
      points[4], points[5],
      points[6], points[7],
      points[4], points[6],
      points[5], points[7],
      points[0], points[4],
      points[1], points[5],
      points[2], points[6],
      points[3], points[7]

I hope someone finds this useful.


The concept is interesting.

ThomThom had some code that did something similar by hilighting the bounds (perhaps not with the 30px offset.)

What would be the main purpose ?
(In addtion to better color highlight the oft hard to see dotted stipple outlines ?)

But WHEN and WHAT ?

  • Would it be the parent and ancestor contexts that should be “offset highlighted” ?
    (Ie, when you double click to enter a context the model selection is cleared and empty, but there is no empty check in the sample code given. As you drill down into a hierarchy, the grandparent contexts are still “offset highlighted” but get dimmer.)

  • Or is it the objects in the current context that would be “offset highlighted” as they are added to the selection ?
    (Ie, It may look a bit weird when individual edges are “offset highlighted”, etc.)

This was really just a test. I wanted to know if I could replicate the padding SketchUp used for its box. I was interested in whether it could be used to highlight the center of mass by having lines extend from it along the coordinate axes and have them stop at some appropriate distance. It didn’t look very compelling though so I went for just drawing a cross to the model.

This little script has no practical purpose though. It merely illustrates the power of pixels_to_model.

It DOES actually have purpose. I use a scene with dark background when modeling, and the edit context boxes are very hard to see.

The edit context box does not adjust it’s color from the style’s edge color.
The edit context front dotted lines have a hard set near black color, RGB(66,66,66), and the back lines are hard set to about RGB(196,196,196).

If you happen to set the modeling background to RGB(66,66,66), the front lines become invisible.
Even when set to full black (as I usually do) the front lines are extremely hard to see.

If you happen to set the modeling background to RGB(196,196,196) then the edit context’s back lines become invisible.

So this concept could overcome this “issue” until color control is added into the style properties. (This would mean the first option I gave above.)

1 Like

But it can only be used within your own tool while it is active. We discussed drawing on the view without needing our tool to be active. Developers would be able to enhance the viewport (draw sky domes, virtual entity types, enhanced shadows and other effects). All what we can draw vanishes when the tool is deselected.


And analyses like solid inspection could be done without activating a “quasi” tool. To a user it makes quite little sense to have tools that don’t react to mouse clicks.



BLOOP! (burst my bubble) Well, dang yea missed that. :frowning_face:

Well it is a nice idea but I can’t see it becoming high enough on the priority list to ever be implemented.

I’ll file a FR to control the context lines color and stipple via style. It likely has a better chance, but I don’t think I have the patience any more to wait for it.