[FR] Add group/component bounding box edges/vertices to things known by the inferencing engine

SketchUp Feature Requests
1

<7-14-2020 addition>
@DanRathbun was kind enough to point out to me that this feature request has been implemented as of SketchUp 2020. It works for both move and rotate - which is all I was hoping for!
</7-14-2020 addition>

A recent thread caused me to take a closer look at bounding boxes - and their use (or in this case - non use) by the inferencing engine.

It turns out that you can’t directly use bounding boxes edges, vertices, or faces as inferred origins or destinations of moves, rotates, scale, or tape measure operations.

This seems silly to me. SketchUp (SU) has obviously generated the bounding box as a displayable entity, but the generated geometry pseudo geometry isn’t recognized by the inferencing engine. Why not?

I run into this problem often when using 3D warehouse components with rounded edges. I want to use the bounding box - usually a corner - as the point I “grab” in a move, yet without extra effort - I can’t!

Workarounds exist.

@Box suggests hovering over an edge that is on the bounding box, then hovering over another edge which (along with the first) defines the corner of the bounding box, then a snap point is enabled at the corner. (see suggestion here)

@spawn uses multiple moves, each move constrained to an axis, here.

@Coty points out that you can create guidelines to create a snapable inference point. (see here.)

And in the same post, @Coty suggests plugin alternatives.

My point is that it shouldn’t be this hard! SU has already created the bounding box. Surely adding the corners and edges - perhaps even faces - of a bounding box (when the whole group or component is the active selection) to the available inferences can’t be too hard!

Tagging others whose posts/replies have contributed to my feeling the need to make this feature request:
@DaveR @Amatoro @Shep @bill_ruggirello

2 Likes
2

it isn’t generated, it’s an openGL illusion on the view…

to add all that geometry would kill a lot of already big models…

john

3

On the rare occasions when I want to use the corners of the component bounding box for reference, I use ThomThom’s Draw Bounding Box to make a guideline box. It’s easily disposed of when I’m finished with it with the keyboard shortcut for Delete Guides.

As for inferencing for Move, there’s always some geometry at the limits of the bounding box to use.

1 Like
4

Oof! It never occurred to me that the bounding box wasn’t being generated by SU! If you’re correct, that it’s an openGL illusion, then I must revise my estimation of the difficulty of adding this to the inferencing engine.

Can you point me somewhere that will confirm that it’s an openGL illusion?

5

The edges, vertices, and faces are normal drawing element objects …
ie, geometry objects that exist within the model database.

Bounding Boxes (and all other classes of objects defined within the Geom module, are virtual helper objects. They do not exist within the model database, and are only temporary objects used by code.

Bounding Boxes do NOT have faces objects, nor edge objects. They have “corners” that are described using Geom::Point3d objects, another of the Geom module virtual helper classes that also do not exist within the model database. (These point objects are used temporarily to described the location of vertex objects.)

It was a design choice I suppose. Just recently within the past version or so, they added the component origin as an inference point, … so they could add BB corners as inferences to certain tools like Move and Rotate.

Perhaps also BB center, and BB midlines (between corners) ?

It is a valid feature request.

However it needs to be considered along with the other FRs involving inferences. Normally geometric inferences would take precedence. But if you are in a certain placement mode (cabinets for example,) you might want to temporarily set the bounding inferences to have precedence.

So again users would likely wish to have control over what inferences were active/inactive or had precedence. (This is repeatedly expressed in most FRs involving the inference engine. Perhaps a Pro only feature ?)

2 Likes
6

the bounding boxes have no entities, only an array of positions…

model = Sketchup.active_model
model_bb = model.bounds.entities
Error: #<NoMethodError: undefined method `entities' for #<Geom::BoundingBox:0x007f98c45a3228>>

the positions are used to draw openGL lines from corner position to corner position…

you can use these positions to draw openGL lines yourself from code…

or you can use these positions to add geometry like in TT’s plugin, but if it was done to all, all the time then models will bloat…

even a single edge has a bounding box so you can envision the proliferation of entities…

by simply using positions and drawing with openGL on call, the overhead is drastically reduced…

although, if you use a script to really select all entities, the drawing of the view become very very slow…

john

7

All the OpenGL docs you could ever hope for:

https://khronos.org/registry/OpenGL/index_gl.php

* The under the hood names for OpenGL classes and terminology may not match that used by the SketchUp GUI interface.

8

Based on some Googling, and on the link @DanRathbun supplied (Thanks Dan!), I’ve come to a few conclusions:

  1. Bounding boxes have only corners. 8 of them.
  2. SU has to know these corners in order to cause openGL to render the bounding boxes. Thus the corners are either stored with any 3D entity, or calculated on the fly when a 3d collection of geometry is selected.
  3. Come to think of it, in some cases (the Scale tool), SU is also calculating edge midpoints and face centers. How else can it tell openGL where to display the scaling handles?

It follows that one of the following 2 cases is true (although it could also be a mix):

  1. The bounding box corners are already stored with the model. In which case, my FR wouldn’t cause any bloat. or
  2. The bounding box corners are already calculated on the fly on entity selection, then discarded when no longer needed. In which case, my FR wouldn’t cause any bloat.

Thus model bloat is not a concern.

From the point of view of the inferencing engine, it’s obvious (at least to me) that the possible inference points are

  • Calculated on the fly - based on objects that the pointer approaches or hovers over.
  • Discarded at some point. (FIFO stack of limited size is my first guess).

So. SU already has the 8 bounding box points (and perhaps more). Can it be that hard to add them to the inference engine’s short term memory?

1 Like
9

steve,

i wasn’t knocking a feature request for additional inference points…

just pointing out that what you thought was geometry isn’t…

Feature Requests have a format…

  1. the desired result

  2. a use case [ or multiple ]

  3. supporting evidence

what they should’t include is supposition of ease of implementation based on assumptions of how it appears to work…

in this instance something like…

  1. additional inference points at bounding box corners, corner mid-points and at it’s centre.

  2. for easily placing objects that don’t fill the bounding box.

  3. cite the referenced threads.

by following a format, others can comment in support or opposition to concise information…

and contribute to the points directly…

e.g. Dan could respond with add > like you have with the the component origin < to point 1

or I could respond with “here’s another use” etc…

john

1 Like
10

Which is why I used “pseudo geometry”.which @DanRathbun later termed virtual helper objects.

  1. I think this is clearly stated in the topic title
  2. I gave a use case - 3D Warehouse models with rounded edges
  3. I gave 4 links to posts/replies in 2 threads

As far as a standard “Feature Request” format goes, are you asserting that this is already a standard? Or are you proposing one?

And as to speculation regarding ease or difficulty of implementation, that’s just the way my mind works. When I make a suggestion, I can’t help but think about what it might involve. And I’ve seen many feature requests belittled as too difficult to implement, so I tend to address it. And when I think something is likely difficult to implement, I have (at least once) started a topic asking “Should this be a feature request?”

Finally:

Then why didn’t you say so up front? Your first reply in this thread certainly seemed like a knockdown.

11

https://forums.sketchup.com/t/the-feature-requests-category/103?u=john_drivenupthewall

I though you would have read that…

john

12

The Discourse engine allows categorical templates that can display captions for “fields” to guide the topic starter.
The Meta > Help Center category uses a template like this. (Check it out.)

13

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.