I am in the process of writing a substitute for the missing ExplodeLinetypes plug-in (from RhinoLabsTools for V4) that is missing in V5. I have run into an anomaly with splines which has caused me to hit the wall here… Essentially I am re-creating a linetype on a curve from the linetype pattern definition. I found a nice, simple, clean algorithm for doing this which works perfectly on all types of curves - except splines. Splines seem to have had some sort of weird tolerance factor added in and so far I have not been able to discover where it’s being done or how to reproduce it.

It is not necessary to script this to see the problem, just have a look at how Rhino attributes a linetype differently to a line and a spline of exactly the same length in the attached file/image… For the most part the behavior is the same, but there is a “fuzz zone” where the curve length approaches an exact multiple of the pattern length. For lines, polylines, circles, arcs etc. when the curve length hits an exact multiple of the pattern length, the first segment is divided in half and a half segment is put on either end…

For splines, the same thing happens, but it happens a tiny amount BEFORE the exact multiple is reached. So there is a small zone where a line curve and a spline curve of the same length do not get the same pattern attributed to them. This makes it unreliable to try to reconstruct the linetype for splines, as I am unable to determine exactly how this tolerance is calculated and therefore am unable to reproduce the Rhino behavior exactly.

Hopefully the attached file and image will explain the problem. The pattern length is 10; 100.000 is an even multiple of the pattern length. When the degree 3 spline in the file is between 99.950 and 100.000 long it behaves differently from a line of the same length.

Without knowing how to calculate this “fuzz” factor, my script will end up being inaccurate with spline curves.

Thanks, --Mitch

SplineLineType.3dm (246.1 KB)