Hi all, how do i sort the items in this list so that when i redraw the curve, they keep their order? I need to work through iterations of this curve sahpe and would like to keep the order of the split components every time i redraw the curve so the division is assigned to the curve segment in the same general area. Encountering this issue in one form or another in about every script i’m working on, what am i missing? How do you control the order of items in a list when working through iterations? See attached and thanks!

sort curves order.gh (25.1 KB)You could order it according to their position, e.g. by deconstructing their x,y,z values or using their distance to an object of your choice. When you deconstruct them you end up with a second list that you can use to edit the original list of items, that might work with the remap component.

I changed the way the intersections are found (they don’t intersect!), using `CrvProx` *(Curve Proximity)* and the way the curve is “shattered” at those intersection points. By using the same method on both of your groups, the sequence of segments is the same, no need for sorting.

sort curves order_2020Aug12a.gh (24.5 KB)

Instead of duplicating the group with all the code, this is an example of how to use `Stream Filter` to choose either `Crv 1` or `Crv 2` as input:

sort curves order_2020Aug12b.gh (15.8 KB)

*(re-posted to answer the original post)*

Or you can handle multiple curves at the same time:

sort curves order_2020Aug12c.gh (15.7 KB)

P.S. The method I used didn’t require any sorting but since the thread title assumes sorting is needed, I might as well mention `Sort Along Curve`. See white group.

sort curves order_2020Aug12d.gh (16.3 KB)

I used the base curve as the ‘C’ input to `AlongCrv` which assumes that both curves have the same start point and direction. It can just as easily be a circle *(approximately centered)* that is used for both curve variations, so you wouldn’t have to worry about start point and curve direction.

sort curves order_2020Aug12e.gh (18.0 KB)

Yet another way… Instead of a circle, `Crv 1` could be used as the ‘C’ input to `AlongCrv`, regardless of which curve variation is being evaluated. The important thing to understand about `AlongCrv` is that the start point and direction of the curve will determine the sort result .

sort curves order_2020Aug13a.gh (16.3 KB)

thanks for all your help, worked through your many examples and made my script work. Would you mind explaining why the SplitwithBreps as i had it originally is not the right approach and why the ClosestPoints is? Would like to know when to use SplitwithBreps in the future and why it’s not the correct use here. I see how the SortAlongCurve and CurveProximity work very nicely but i just don’t understand the logic of why Splitwith Breps is not working/appropriate here. Thanks again!

The first thing I see in your code is that `CCX` fails to return any intersection points. That causes everything else to fail. That’s why I used `CrvProx` instead to find those points.

A pFrame is not a brep, though sometimes GH will treat it as a plane surface. I saw no need for `Split with Breps` when `Shatter` splits curves using the ‘t’ values directly.

`Sort` has no clue what to do with curves as the ‘K’ input.

You’re welcome.

Thanks for the explanation. This is a bit related to ordering a list but slightly different, for some reason between iterations, the frames rotate and the pipes orientation is not consistent. Looks like you have in depth knowledge, would you mind showing me what’s wrong in my script and what is the way to make the frames keep the same coordinates between iterations? I already flipped the second curve to match the orientation of the first curve, but not sure why the frames seem to have their own mind and are not consisent. Thank you for your help!

frames orientation through iterations.gh (9.7 KB)thanks but i need the pipes to be horizontal and perpendicular to the curves, not vertical, for both iterations.

You can explicitly align the pFrames using the ‘Z’ vector *(white group)*:

that makes a lot of sense, thanks!