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)
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.
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:
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.
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.
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?
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.
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.
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.
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?
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…
