Hello everyone,
I can’t think of any good solution to orient a small connection part into a larger model.
It would be great and helpful if I could get some advice here. 
Following is a photo of the two models and a GH file of them.
Thanks in advance for any kind of help!
Orient to place object.gh (1.1 MB)
Orient to place object Edited V0.gh (2.1 MB)
I believe this is not a good way, there must be something much better.
This version is better than my version ‘a’ (deleted). And no plugins, of course. 
Inside the ArcPl cluster: (yellow groups above)
Thanks for the help!
It works well on this large model, but sadly it won’t work on other large models.
Thanks anyway! It did give me an insight into how to solve a problem like this!
Thank you for your efforts!
It’s perfect!
I used this code on my other models and it works perfectly on nearly every model that I have! 
And I will try to understand now how this solution works.
It really helps and I appreciate your time and efforts 
The algorithm I used depends on one of the semicircular faces of the “biscuit”/“domino” tenons (connectors) for both location and orientation. Matching is weak as it depends only on area, though that could easily be improved by comparing area AND perimeter length AND discontinuity points (2). The tolerance value of theisEqual cluster (‘T’ input) could be increased from its default of 0.0001,
If you post an example where it fails, I’ll take a look at it.
Thank you for the thorough explanation!
With this explanation, it’s much clearer how the algorithm works.
So far, only one model has failed with this algorithm, probably because there are negative spaces that are not perpendicular. I will try to fix that myself first.
I want to extend the functionality of this algorithm a bit further.
My Goal:
Because some of the connectors will exceed the boundary of other models, I want to check if they are intersecting with the other models and remove them accordingly. Some need to be replaced with ‘half-connectors’. I tried with List Length (smaller intersecting area, fewer curves), but it didn’t work.
Would it be possible for you to take a quick look at this? I would really appreciate it!
Nah, that’s a different issue.
I’ll give you a tip though - AVOID Path Mapper! PShift does the same thing in this case:
Use this component.
This started simple with the white group, using SDiff to “subtract” a BBox from all the blue connectors (before they were blue). But that left some cut off connectors in the same places where the pink connectors are… So the cyan group is an elaborate scheme to leave only the blue connectors you see, leaving out those that overlapped the pink connectors. 
I really don’t like such HUGE GH files!
Thank you very much for the help and the elaboration is clear for me to understand!
Also, thank you for the Pshift tip. I will use it to replace Path Mapper
I am really sorry for the large GH file that caused unpleasant problems.
I will look into it to see if I can downsize or simplify the geometry.
Thank you for the tip!
Didn’t notice that there is a Clash component.
I will try to understand how it works.
I realize that internalizing geometry is standard practice for the forum. When that geometry is small, it’s no big deal.
But when the geometry is large, as in this case, it causes me grief - especially when multiple versions (copies) are involved. Small changes to the GH code require multiple copies of the huge file. In these cases, keeping the large geometry in a Rhino file that small GH files refer to makes more sense. Or have a single GH file with large internalized geometry using Data Output to pass it to “real GH” files (the bits that manipulate the geometry) to access it using Data Input.
For example, you don’t need multiple copies of the connector. Instead of this:
You could/should have only one connector, like this:
Unfortunately, making that change to the GH requires copying the large geometry along with it.
Filter Parts by Intersection_2023Jun11a.gh (2.6 MB)
P.S. Saving that GH file without internalized geometry (“Clear values”) is only 41K (1/65th size)
This idea has made sense to me for a long time so I can’t resist making an example.
Geometry is in one file using Data Output with ‘Destination’ set to “Parts geometry_V1”:
Hopefully that large geometry doesn’t change much. Small GH files that work with it get the geometry using Data Input (black group on left):
Voilà!
Thank you for the very detailed explanations!
This information is indeed something I need.
I’ve been bothered for a while about how to downsize the file and/or speed up the calculations.
I will apply your suggestions to a larger file that I’m currently working on and make sure to post something like this if the geometry size is too big.
I am truly grateful for your tips and insights.
There are quirks about using Data Output and Data Input to be aware of,:
including the limitation that you can’t turn the “dog handle” and swing the hinge at the same time because the sliders are in separate GH files…
