Parts Labeling: Keeping Trees Matched up

Grasshopper
,
#1

I’m working on a definition that includes labeling of CNC parts and placement of points for drilling alignment holes.

I’ve managed to get the planes for my labels, the points, and the parts outlines into three different orders in their lists.

image
image1630×1412 41.7 KB

I can see how it happened, but I can’t figure out a way to fix it. The methods I used to find where the points and planes go are the problem, but the methods are also the most reliable way I can come up with to get the locations I want.

So is there a way to get these lists in the same order? Or to group the points and planes with the parts outlines based on them being inside the outlines? (I need to group them before I array them and then nest them.)

(FYI parts are not near the origin, the image shown is at about -600,-700,0)

Parts Labels Out of Trees.gh (50.2 KB)

image
image2866×1408 459 KB

#2

Yikes! That got a bit confusing so I had to simplify the code. I haven’t added any labels yet to prove that the surfaces and points match but have good reason to believe they do.

Parts Labels_2020Dec12a
Parts Labels_2020Dec12a1316×388 64.9 KB

Parts Labels_2020Dec12a.gh (39.1 KB)

#3

The labels themselves matched the planes, so if the planes match the outlines, the labels will work.

Gonna take a look and see how this works out. Thanks so much.

#4

Check this as well. You can ungroup the result.

Canvas at 02;59;59
Canvas at 02;59;591306×741 144 KB

Parts Labels Out of Trees_re.gh (42.4 KB)
Same result…
Canvas at 03;29;55
Canvas at 03;29;551092×624 114 KB

Parts Labels Out of Trees_reV2.gh (43.7 KB)

#5

Rats. I’m wrong. What a fascinating puzzle, it doesn’t look that complicate… but it is! :frowning:

#6

Looks like it isn’t working:

image
image1380×1210 16.1 KB

image
image2184×979 212 KB

The Goal is to the hoops split up into two overlapping sets of parts. It would be fine if there was a processor intensive way of just looking for whatever is inside of each part outline, and putting the contents and the outline in the same group.

Below are manual bakes of what I’m trying to achieve:
One layer of this:

image
image1683×1563 55.2 KB

One Layer of this:
image
image1933×1557 56.9 KB

I can sort out getting the labels to auto generate, and I can sort out getting the points where I want them. The only problem is the grouping, and the only reason the grouping is a problem is that if the outlines touch each other, it breaks RhinoCAM’s nesting algorithm, so I need to array everything before I nest.

#8

I know. I swear it was but must be wrong.

#9

It broke my brain too. I tried a whole bunch of tree stuff and considered a whole bunch of methods of deriving points directly from only the outline curves before I posted this. Deriving from outline curves is bad because it’s hard to not do it without creating conditions where it breaks: sort out the exploded curve parts that are two inches long? works only until there’s an outer or inner curve that is coincidentally the same lenghth as the end lines.

#10

This seems to do the trick.

Can you explain why using shift list on the planes is necessary and why it works on all the lists? I tried it earlier while trying to fix this, but my implementation must have been wrong. Is the “2” in shift input going to work with any input curves?

#11

This feels like cheating but it looks like an off-by-one error so I used Shift List after SrfSplit and it looks better now?

Parts Labels_2020Dec12b
Parts Labels_2020Dec12b803×822 14.9 KB

Parts Labels_2020Dec12b.gh (55.4 KB)

#12

In HSKims definition it looks like correction of an off by two error?

#13

It looks like @HS_Kim added a fix to your results (and ignored large parts of it)? Whereas I largely rewrote your code.

#14

I’ve revise my previous posting…

#15

I used Area ‘C’ (Centroid) in the first cyan group to label the surface fragments just to be absolutely sure the labels corresponded to the right piece. But once you are satisfied the code is correct, you can uses the stray MidPt component instead for better location of those labels.

Parts Labels_2020Dec12c
Parts Labels_2020Dec12c1383×592 89.7 KB

Parts Labels_2020Dec12c.gh (57.9 KB)

#16

I’d previously omitted my labels because they use a newish Ngon component and I know I have a better chance of getting replies when everything is vanilla.

Here is what I was working on, with your first solution plugged in. (requires Ngon)
Parts Labels Out of Trees_re_re.gh (77.9 KB)

image
image3465×1413 570 KB

Works almost perfectly. One catch: the points represent alignment holes for assembling the brick-stack of parts. As such, if you look at my manual examples above, points from both levels of bricks need to appear in both the top brick group and the bottom brick group. So the output of the endpoints components in both your upper and lower GH groups need to make it into the group component at the end of each.

image
image1533×1533 54.1 KB

#17

I’ve only checked the data tree issue this time since your text for engraving produce multiple curves, so it will mess up all your arrangements.

Canvas at 04;57;17
Canvas at 04;57;171816×517 200 KB

Parts Labels Out of Trees_re_reV2.gh (48.4 KB)

#18

Thanks. Presumably I just need to group or tree the engraving text correctly before connecting it?

#19

A little neglect may breed mischief …
for want of a nail, the shoe was lost;
for want of a shoe the horse was lost;
and for want of a horse the rider was lost.

—Benjamin Franklin

I don’t know what that means? “brick-stack”? And where did the pair of highlighted points surrounding your labels come from? I didn’t see them in the original code/spec?

For whatever it’s worth, I added orientation planes for all of my labels but don’t see big value in grouping surface fragments, points and planes? Why is my “A11” a different shape than yours?

Parts Labels_2020Dec12d2
Parts Labels_2020Dec12d21040×883 20.5 KB

Parts Labels_2020Dec12d
Parts Labels_2020Dec12d1704×644 157 KB

Parts Labels_2020Dec12d.gh (51.8 KB)

The two cyan groups are labeling only, extraneous to “Keeping Trees Matched up”.

#20

Yup. Adding group and then trim tree after the text component takes care of it.

#21

As you must know, the method you are using to get those two points near the surface labels (shortening the “tween curve” fragments) means they are all different distances apart, depending on the length of each segment…

Parts Labels_2020Dec12zzz
Parts Labels_2020Dec12zzz1321×485 61.7 KB