In this topic Hole in model becomes solid in Shapediver - #4 by pavol
there’s the suggestion that using the Explode component for curves returns a list of segments which is different on different computers. In my experience Explode always returns a list of segments in the correct order starting from the startpoint and following the direction of the curve as shown in my test here:
Does anybody else have any knowledge on the order not following the logic I assumed is there? Can anybody from McNeel explain/confirm/deny the logic behind the list it returns?
I am quite shure explode always returns the same order.
I have done multiple projects where this component was at the center of the process and I never had any unreliable order across different operating systems and versions.
However, the shatter component may be different. I do believe it is dependant on the order of the parameters it is given.
Edit for reference: Order of segments on Rhino 6 for Mac (6.29.20239.15172, 2020-08-26) and Grasshopper 1.0.0007
Grasshopper special cases certain curve types, but ultimately relies on the Rhino.Geometry.Curve.ExplodeCurve() method as provided by the Rhino SDK.
The logic is as follows. In the case of a recursive explode:
If the curve is a polycurve, any nesting (polycurves inside polycurves) is removed and the Explode() method is called. Then, each resulting segment is exploded again using the same method.
If the curve is a polyline or can be losslessly converted to a polyline, each line segment is appended directly to the exploded list.
If the curve is an arc or line, it is appended to the exploded list withou modification.
If none of the above, the curve is converted into a nurbs curve and split at all internal C_1 locus discontinuities. Segments between discontinuities with very short domains (< 10^{-16}) are rejected, as are invalid segments.
So Rhino is involved in the above algorithm in four ways:
The implementation of the Explode() method with respect to polycurves.
The polyline detector.
The discontinuity finder.
The curve validator.
And ultimately different versions of Rhino may choose to construct their polycurves in different ways as well, so that can be important too.
It seems unlikely to me that (2) or (3) would change between versions as their behaviour is relatively well defined and their implementation not particularly difficult. However, (1) and (4) may well change from version to version as we figure out more ways to detect invalid curves or prevent invalid curves from being created.
Looking at the C++ code for polycurve exploding, it seems to me you get the actual curves that make up a polycurve, with their original parameterisation. I do not know whether, when or under what circumstances it is possible to have a polycurve made up of segments with a different or possibly even reverse parameterisation from their underlying curves.
Without a replicable case, this is just me wildly guessing while looking at C++ code I don’t fully understand.
