Offset Bug

Offset with Loose=Yes of an ellipse results in a polycurve with 4 segments and C0 continuity between segements. The expected result would be an ellipse or single closed NURBS curve. In contrast Offset with Loose=Yes of a closed degree 3 NURBS curve results in a single closed degree 3 NURBS curve as expected.
Version 6 SR12 (6.12.19016.7051, 1/16/2019)
Offset Bug.3dm (50.6 KB)

Hi David,

Thanks for posting what you’re seeing. The Loose option for Offset is new in v6 so I checked with the devs and this is mathematically expected for an ellipse when loose is used. The offset of an ellipse is not an ellipse so when the loose option is used the edit points (editpton) are actually in the same location as they would be if offset normally.

I’m not sure what your doing that needs this but I would guess you want less points on the offset result. If so, here are some ideas that might help…

  • Use a normal Offset and then use RebuildCurveNonuniform to reduce the ctrl pt count.
  • Make a ‘deformable’ Ellipse and offset that Loose.
  • Offset loose and then run ExtractPt and use CurveThroughPt on those with the closed option.

Technically the loose result is apparently to do with the “fully multiple knot” structure of the ellipse… but please don’t ask me to explain that :slight_smile:

Hi Brian, David, ‘devs’,

I would have expected a loose offset of a regular ellipse to look like this:

i.e. offset the control points in a rectangular manner. It makes an ellipse as well (and the offset is correct at the quadrant points).

LooseOffsetEllipseSuggestion.3dm (313.0 KB)

1 Like

@BrianJ I completely understand that a “loose” offset of an ellipse may not be an ellipse. Given that McNeel has defined a loose offset based on the edit points the loose offset of an ellipse should be a single curve with C2 or higher continuity which goes through the offset edit points, not a polycurve with cusps. Offset the edit points then determine the curve which corresponds to those edit points.

Hi David - if you offset the edit points of an ellipse, the result is indeed a cuspy-thing.


So a consequence of the ellipse representation using multi-knots and defining a loose offset using edit points is cusps…

Perhaps the loose offset option should only be available for non-rational NURBS.

@pascal, devs

I don’t understand why ellipses and circles/arcs are not special-cased for Loose offset, offsetting the edit points in this case doesn’t make any sense to me when offsetting control points gives a better result with less curve deviation… And it’s relatively easily programmed in this case (IMO).



I’m with Mitchell!
the offset loose of a conical crv should be the same type of crv.

I’m with Mitchell too!

But keep in mind that an offset of a conic is not a conic, I don’t know how that fits in with being ‘the same type of crv’.


But a loose offset could be… as per my example above.

Hi Mitch - yep, thanks, I do see … but I’m too dense so far to see how to do this predictably on an elliptical ‘sub’ curve though - can you see where the points should go?


Workin’ on it… still need a bit more time to finish my “proof of concept”…

Here is a really bad hack, the code needs lots of cleanup and there are still issues to be resolved, UI, etc. It works on closed ellipses or open ellipse segments; and should work on out-of main plane objects as well, can’t guarantee the on-screen side picking will work correctly for those though.

Edit: below is a somewhat improved version… (4.0 KB)


1 Like

Here is a comparison of the native loose offset of both full and partial ellipses compared with the script
(original=cyan, native loose=red, script loose=green)

You can see that the script produces better results in every case. However, one downside with partial ellipses made by the script in its current form is the endpoints do not fall on the line normal from the original. I think that can be fixed in the code though, it’s just a matter of calculating the split points differently.

LooseOffsetEllipseExample.3dm (384.4 KB)

1 Like