@sdmitch said:

What defines a good or bad pairing?

No overlap when moved center to center. Where 'center' is center of paired face.

You know, I've yet to solve the problem of adding an image to a post? Never-mind...it pays to actually look at the screen staring you in the face...doh!! These are all individual groups. Here is a correctly paired and moved (face center to face center) pair followed by an incorrect pairing...Ignore the purple dot and odd selection coloring, they are not germane.

Thus far I've found 13 pairings that fail for obvious reasons:

• Bottom, Left"
• Bottom, Right"
• Front, Bottom"
• Front, Left"
• Front, Right"
• Front, Top"
• Rear, Bottom"
• Rear, Left"
• Rear, Right"
• Rear, Top"
• Top, Left"
• Top, Right"

I will continue to test at least until I figure a way to code, detect and fix.

@sdmitch said:

No, it can be negative. The sign of 'z' of the product of the two vectors you are using to determine the angle_between should be the sign of the angle of rotation.

Very good to know. I just built a 3d grid of nine boxes to see how many bad pairs I can find. Anything on a diagonal path is bad so far. That arrangement seems like it should be all of the possible pairings but I'm not yet confident enough to bet the farm on it.

@sdmitch said:

So you would like to specify the "face" on the "moved" object which is to be "paired" with a specified face on the "fixed" object?

Pretty much. As part of the existing code I already know the orientation of the two object BB faces. And have written code for opposite? so I know when things are amiss. The rotate90 code is also written. I'm now pondering the code between. And wondering if rotation will always be positive.

When I say face in this instance I'm speaking of the side of a bounding box and not a SU face. My problem stems from a naive assumption on my part, that the closest pair of faces of two objects would be what I think of as 'opposing', i.e. right with left, top with bottom and so on. Only a second or two of visualization would show that this is not so. Right may easily pair with front, rear with left and similar. Needless to say this does not lead to good result.

So the obvious solution is to rotate the object into 'paired' alignment. My problem is that I'm having trouble thinking of such a solution. Clearly the un-aligned would have to be rotated to match the target but what does that imply? I mean it is obvious that right would have to rotate to become rear in order to match up with front...and I suppose that means a rotation around the z-axis assuming normal orientation. Seems like it would always be a single 90° right or left(around the given axis).

So the sledgehammer approach is to map out each possible rotation and apply it. Which leads me to ask is the a better solution?

As is often the case the problem is simple—code in question works much better if properly invoked:

pk = HSM_Picker.new()
mod.select_tool(pk)

Thanks all, sorry for the stupidity

@thomthom said:

@hsmyers said:

@thomthom said:

What is the value you get from .best_picked?

That should only return an entity - so I wouldn't expect @@picks.length to work. (Unless you accidentally picked an edge - in which case you are getting the length of the edge.)

Don't know, will find out...oh the joys of print statements!

Try the debugger: https://github.com/SketchUp/sketchup-ruby-debugger
I prefer RubyMine for debugging: http://forums.sketchup.com/t/please-help-me-to-setup-de-debugger-on-rubymine-for-mac/289

Hmmm...haven't used any, could be interesting...

@thomthom said:

What is the value you get from .best_picked?

That should only return an entity - so I wouldn't expect @@picks.length to work. (Unless you accidentally picked an edge - in which case you are getting the length of the edge.)

Don't know, will find out...oh the joys of print statements!

Back to debugging... The following appears to run without error—or actually without doing anything other than returning "[]"!

mod = Sketchup.active_model # Open model
ent = mod.entities # All entities in model
sel = mod.selection # Current selection

SKETCHUP_CONSOLE.clear

class HSM_Picker

  @@picks = []
  
  def activate
    @@picks = []
    Sketchup.set_status_text('Select an object', SB_PROMPT)
  end

  def deactivate(view)
    view.invalidate
  end

  def onLButtonUp(_flags, x, y, view)
    ph = view.pick_helper
    ph.do_pick(x, y)
    @@picks << ph.best_picked
    if @@picks.length == 2
      p 'done'
      Sketchup.active_model.select_tool(nil)
    end
  end

  def onCancel(_flag, _view)
    Sketchup.send_action('selectSelectionTool;')
  end
  
  def picks
    @@picks
  end
end # class HSM_Picker

pk = HSM_Picker.new()
ets = pk.picks

Implication clearly being that I don't know what I'm doing (certainly true!) So once again begging for clues here... In line with previous I had expected

ph.do_pick(x, y)

to politely wait for the user to make a selection (or two) and then be available for interrogation but I fear that may have been naive. My initial understanding ( or miss in this case ) is often warped by my expectations based on years of building APIs more sigh

@sdmitch said:

In the API the ph = view.pick_helper statement does not does not have variables passed to it. Taking off the (x,y) made it work for me.

class HSM_Picker
>   def activate
>     @@picks = []
>     Sketchup.set_status_text('Select an object', SB_PROMPT)
>   end
> 
>   def deactivate(view)
>     view.invalidate
>   end
> 
>   def onLButtonUp(_flags, x, y, view)
>     ph = view.pick_helper
>     ph.do_pick(x, y)
>     @@picks << ph.best_picked
>     if @@picks.length == 2
>       p 'done'
>       Sketchup.active_model.select_tool(nil)
>     end
>   end
> 
>   def onCancel(_flag, _view)
>     Sketchup.send_action('selectSelectionTool;')
>   end
> end # class HSM_Picker
> Sketchup.active_model.select_tool HSM_Picker.new

Ah! On such screw-ups as this are founded the bugs that plague us! Much and many thanks sir.