OffsetLooseBug.3dm (39.9 KB)
I expect that’s deliberate, it probably runs the input curves through the polyline reduction algorithm and if there are extraneous points within the user-specified offset tolerance, it removes them. Why would you use Offset>Loose on degree 1 curves, when Offset (standard) will give you the exact segment offsets?
I see it isn’t too reliable though, some points are removed and not others:
And actually the result is the same on the above test whether the offset is loose or not.
Well, I was trying to use Offset Loose to stop Offset from changing the curve parameterization (which is a bug):
As for why those extra points are important, it’s complicated but it matters. In this instance, I need them to control the end direction of a srf that was built with FlowAlongSrf PreserveStructure:
I use a lot of complicated History tricks to have an easy to edit shape for form-finding. Reusability is a problem though. It’s hard to remember how something was made years later.
Creating control polygons (_CurveThroughPolyline/_ExtractControlPolygon) is an extra step, but it helps to hide the underlying complexity. I can look for those Deg1 crvs when attempting to reuse something and be confident it will produce a usable srf.
Not a bug, but another complaint about Offset Loose is how it determines direction. It randomly picks the normal of a neighboring line segment (grey or white line) instead of the average (orange line):
I really dislike that the point placement is random with no goal (it will adjust the location to fit offset tolerance with > Deg1 crvs). Plus it makes it so the offset isn’t reflexive:
I’d much prefer Offset Loose to be perpendicular with > Deg 1 crvs, but I understand it was a design choice.
Also, Gumball Align To Object does the same thing with Deg1:
But works (perfectly perpendicular) with > Deg1: