I was working on creating a script in grasshopper when i discovered something that was causing me lot of frustration. I was able to recreate the problem in a simpler format which i will provide here. I now know how to work around this problem, but i want to understand why it happens.
When i have a closed polyline, the start point of the curve will be the start point of the first segment. For visual purposes i offset the curve inwards and then explode it to get the separate segments. If i then join these segments together again, the start point is now shifted to the start of the last segment. This becomes obvious when i try to loft this newly joined polyline to the original polyline, and the result is messier than one would expect.
Why does the starting point change during a join curves component?
I have never experienced this behavior in gh for closed curves… is this is an assumption of yours?
would you mind posting a gh file where shifting segments and joining them yields the same shifted start/end points each time?
as far as I know, start/end points stays the same if both the curve is open, and all the segments belong to the very same curve:
but for closed curves, start/end points just might end up in the same location as result of a lucky sorting when they go through the joining function… but that would be nothing more than a lucky random sequence that does not necessarily happen:
You say you have never experienced this behavior in gh for closed curves, yet you display this exact behavior in the second video in your reply. I´m not assuming it happens, I have demonstrated that it happens (and so have you) and I wonder if anyone has an explanation for why?
To me it seems that this behavior is not random, and yields the same results every time. In your second video you’re shifting the starting point of the curve through every possible point, yet the joined curve is always one segment off from the original.
If the join curve component had worked as I would intuitively imagine, the numbers of the segments would overlap, no matter how many times you exploded and joined a closed curve.
But alas they don’t, hence my curiosity to figure out why.
what I meant to say is:
given a set of segments that form a closed loop, when they are joined in a closed curve I would not expect for their initial sorting order to be kept, even if they are initially sorted in such a way they already form a closed loop
I don’t recall experiencing that when a set of segments that form a closed loop are joined in a closed curve, they will keep their initial sorting order
just to give some more flavor (green numbers -inside ones- are referenced to non-yet-joined segments): you will notice that when I Reverse the order of the non-joined segments, the joined curve keeps being counterclockwise
given that, I don’t really understand on what you base your assumption that joined curve segments should retain the same order those segments had before being joined
to my knowledge, to get a closed Polyline where you control the order of the segments, best way is to use a list of vertexes
Okay I see your point now, and you certainly added more flavor to the problem by reversing the order.
Maybe it is the case that one shouldn’t expect the sorting order to be kept, but I see no reason for it not to. The program has an algorithm to sort the segments when joining (meaning it’s not random), but it seems to do so in a counterintuitive way.
Even in the reversed order example, I can still figure out what it is doing. It is still shifting the starting point to the start of the last segment like in the original problem, but now it also makes sure that the order is counter clockwise.
Wouldn’t it be more intuitive for it to not shift the starting point, regardless of whether or not it flips the order to be counter clockwise or not?
My only assumption for why it should retain the same order the segments had before joining is that it would give the user complete control of the operation. Whereas now it shifts the order in some way that the user is not initially aware of. I guess it has something to do with the case when the segments are not ordered sequentially from the get-go, but my assumption is that it should be able to at least have the same origin point as the first segment in the list, without compromising the join-operation.
Also, I figured out that the only reason the joined curve flips back to the original rotation is because the direction of the segments remains the same even if you reverse the order of the segments. If I flip the initial curve, then the join operation will generate a clockwise order as well.