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
Nothing terrible, really. Things are working fine - I’d just like to learn from you how you’d go about ‘optimizing’ or ‘shortening’ a little operation, if you think it’s possible.
I have these common lines shared by two brep sets. I then find how many lines exist per brep for each of the two sets:
My question is about whether or not it’s possible to perform this operation all at once without bifurcating the tree as the brep sets have different quantities.
First I thought about pulling the points to both brep sets at once rather than grafting each brep set and pulling the points to each; however, that eventually gives all lines for one brep set and all lines for the other brep set, which is different to getting the lines per brep on each brep set. That’s what I care about, and as you see I already have it but I want to learn if there’s a fancier way to do it simultaneously for both brep sets.
I would also take advantage of the “Principal” modifier you can activate on an input, in such a way to tell the component that one input has the very data structure you would like to keep in the outputs (here is with and without Principal mod to enhance the different data structure in the output)
Thank you @Volker_Rakow! Nice to read from you and great insight as always! I appreciate it.
In concept, I personally like CrvNear (curve nearest object) more than ‘pull point’, ‘brep closest point’, etc. I tend to want to use it often and I feel the component hasn’t gotten the love/rework it deserves.
In most operations, it seems to act slower than workarounds leading to the same solution(s). In fact, not too long ago Inno precisely helped me with bypassing ‘curve nearest object’ here. I’ve ignored the component ever since.
HOWEVER, now that you’ve brought it back…for this particular problem it seems CrvNear actually handles things faster by ~ 10s! An eternity.
Anyway, you were late to a very easy question apparently , so I do have a new, hopefully better question about how to identify ‘co-linear’ or ‘co-vectorial’ lines (sssshh! be quiet math-grammar patrol!).
Let’s say I stick with your CrvNear suggestion and I save 10 seconds. Then I look at the data knowing there are lines that are ‘on the same infinite line’ (not sure how to say it…they’re on the same plane, follow the same direction ray, etc.):
And then I would like to either keep one of the lines or get rid of all the co-linear lines and go back to the data structure minus those subtractions.
It may have to do with the fact you are comparing all the points to the geometries grafted. With my solution, I am comparing all the lines to a complete set of geometries, which is less comparisons.
I am not sure. I am in a new time zone, so I am in my bed instead of at my computer… I would be interested to know what the result of a line line intersection is of two colinear lines is, and if that is useful.
No problem. I wonder how that would work as well. Probably not robust becase the lines will end up intersecting each other in farther space
eventually - that’s why I am looking at finding them as ‘same vector cases within each branch’. Maybe I need to start a new topic…
Same (or opposite) direction vectors for the lines will only prove (anti)-parallelity, not whether the line segments lie collinearly. Line | Line intersection will test for (anti)-parallelity similarly, but by throwing nulls for the (anti)-parallel case.
If you use Curve | Line intersection you can distinguish between collinear (two points as a result), intersection by extension of the line (one point result), and intersection as a result of having to extend both the curve and line segment (empty data set). Both geometries are line segments, but nothing’s stopping you from providing Curve | Line intersection with a line segment as a curve.
Cross referencing the lines holistically will give you all the possible “curve”-line combinations.
data-structure wise, I’m wondering if it’s more convenient to find_&_cull duplicates of colinear lines only after checking for the closest surface, or is it better to do that as very first step, and only at that point perform the CrvNear/PullPoint check?
if you don’t want to resort to Line equations, a maybe convoluted but probably geometrically-working way to understand colinearity might be to introduce a custom Plane that is somehow perpendicolar-ish to the Lines (A), use Line|Plane intersection (B, that considers Lines as infinite entities) and group those intersection points with Point Groups, something like this, which gives you couple or triplet of indexes where intersection points are closer than the selected distance:
I guess a critical point is that (even if this works well in this particular geometrical situation) the grouping distance is just a low slider value, but it does not represent any sort of model-accuracy anymore because lines are on very different angles with that plane
just as a closing note, this will work fine in this particular geometrical case because of how lines are sort of all oriented in the same way and the also are evenly spaced: the above method would not be reliable in a scenario like “given 1 million random straight segments, find the colinear ones” because it would find many many false positives
Got you—I’d love to see what you got. However, I wanted to keep myself from repeating operations¹
¹In reality, the lines you see are place-holders. In a distant past, I generated all intersections lines holistically referencing all breps except for four (4) of them. This was intentional…then failed to predict the future: I didn’t generate intersection lines for those breps in the past and now I need them. Maybe this information is already irrelevant/redundant, I just didn’t want to reopen a can of worms with intersections…but, perhaps I shouldn’t be dealing with this problem to begin with
From there I did a bunch of things with the split tree line sets separately, but since I only cared about the notched breps at the end, I stopped paying attention to carrying through line data and here we are
Anyway, @inno, tremendously clever help again. You saved me with the Line | Plane and Point Group combo. It’s beautiful and reliable for this case as you stated, whether I work with the entire thing or the sets from split tree:
So simple, right? A big reason I couldn’t get to the answer yesterday was that I failed to work with the indices like this. That’s what I needed. Will I ever learn?!
I can integrate it to what I was doing originally:
BUT it’s limited: I don’t find all multi-line occurrences (see far right box above) because of my silly vector tolerance rounding thing, now unnecessary
Yes. In a related what-if scenario, I stubbornly bulk target co-linear lines and results are evidently not what we’re after, so it’s the most important closing note!
.
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
).
).
, so I do have a new, hopefully better question about how to identify ‘co-linear’ or ‘co-vectorial’ lines (sssshh! be quiet math-grammar patrol!).
:
