As expected, this changes the data structure––the number of groups of shattered segments now corresponds to the number of lines that were identified for intersecting in the first place.
What I would like to do is to regroup the data back to the “parent” structure. So, for example if a group had two lines (brep edges), and then one of those lines got split into three segments as a result of shattering, I’d like for the original “parent” group to now contain all 4 items: one single line and the shattered segments of the other line.
Thanks for looking into it, I appreciate your time.
@inno (sorry to summon you), I feel you’ve already taught me how to do this, and I’ve achieved it with other brep multi-intersection workflows, but this is slightly different and (obviously) I haven’t learned anything.
it looks much harder than it is I think the trick is to graft the tree from the start, in such a way you get one item per branch, and use the branch path as identifier of that unique line
that way you can replace the content of each single branch with its own shattered parts (one item will eventually be replaced by multiple items) while keeping the data structure intact
the two small groups on top and bottom are for visualizing paths on curves, in red is the original path of the whole original line, in white -for each shattered segment- its final path (which should be original_path;[0-1-2-3…] ) like :
Sounds much more obvious than what it was (for me ).
Inno, thank you very much. This is phenomenal help. I am excited to studying this very carefully tonight–and similar to the last sculpture you helped me with, I’ll come back with some pictures.
Did a fair amount of it and after that I can see why you say it’s easier than it seems, ha (easier said once you study it ).
Yes.
I love when you finally ‘get it’ yet can’t necessarily explain it quickly and immediately because that equates to untangling wires in your head in order to verbalize your understanding? LoL - saying this because I have a rare job where the boss is even weirder and actually wants to know what has been figured out.
Aside from the key “grafting” at the beginning, this is where the other crucial action happens because this wasn’t explicit in my question and yet you knew it would be needed.
I sound like a clown at work attempting to explain and describe what this ‘bottleneck’ was
Thanks to this I can reference back to the actual breps and get the plane data I definitely require to build insert tabs for fabrication:
Lastly I was wondering if the sorting of the shattering parameters was important/necessary or just part of the classic Inno habits such as the integer component:
lol maybe we have the same boss and we don’t know it
YES, you stare at the screen for a couple of minutes, and suddenly you realize you’ve understood, and then that weird little smile forms, like a child peeing in the sea
ohhhh wow, that looks HUGE!! curious if that is a whole installation or part of one!
in line of principle, I think both Sort components could be omitted, I just have the weird habit to make data “straight” -if that does not interfere with the process- to make it easier to trackback stuff when needed
if you remove Sort_A you can also remove its Int parameter, as it only transforms back the data type into Int in order to make the Member Index work correctly after Sort_A itself (the merge of the MCX outputs iA and iB yields ints, and Sort yields floats)
Sort_A has indeed no relevant role: those indexes will be the same values just in a different order, and it doesn’t really matter
the second one, Sort_B, I think “nowadays” can also be removed… I had some memories that probably go back to Rhino 5 (?) where the order of the shattered segments was somehow related/influenced by the order of the shattering parameters or something like that?
it looks like the parameters get internally sorted during the shattering, so they will follow the direction of the curve… I wouldn’t bet my life on thatI can finally bet my life on that thanks to this stupid example that will live in a corner of my brain forever: jittering the order of the shattering parameters does not change the order of the shattered fragments output
.
I think the trick is to graft the tree from the start, in such a way you get one item per branch, and use the branch path as identifier of that unique line
).
).
