Parts Labeling: Keeping Trees Matched up

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.

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 (50.2 KB)

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 (39.1 KB)

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.

Check this as well. You can ungroup the result.

Parts Labels Out of (42.4 KB)
Same result…

Parts Labels Out of (43.7 KB)

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

Looks like it isn’t working:

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:

One Layer of this:

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.

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

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.

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?

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 (55.4 KB)

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

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

I’ve revise my previous posting…

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 (57.9 KB)

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 (77.9 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.

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.

Parts Labels Out of (48.4 KB)

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

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 (51.8 KB)

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

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

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…