Curve.Offset direction is inconsistent

For some reason the Curve.Offset function in Dynamo/DesignScript does not produce consistent results relative to curve direction. As an example, try drawing lines from the center of a circle to even divisions around that circle - then offset those curves. You’d expect a radially symmetrical figure, but instead it “flips” at a certain point. compare the results between GH and dynamo:

what gives?!

@Aparajit_Pratap ping!

2 Likes

I thought this behavior was being triggered by the normal flip. But all are the same.

This node always bothered me.

In this case the results are consistent, but unwanted.

@Andrew_Heumann thanks for pointing it out. This is a bug, we’ll fix it.

3 Likes

When will it be fixed? Curve.Offset is still buggy.

Blue lines are offsets of parts of the centerline. Offset distance is in all cases the same and signed values. The direction of the centerline and the parts that are offsetted is the same (from left to right).

But it is very weird that some lines offset to the wrong side.

@Anton_Huizinga this was fixed in the 2.10 release. If you’re still seeing issues, could you share the Dynamo graph for us to investigate this further?

I work with 2.12.

Attached is a graph and a drawing. It contains an alignment and 4 crossing polylines. The graph reads the geometry of the alignment and the crossings, then the alignment is split at the points in between the crossings with a small cap, and those alignment parts are offsetted. Two of them in the right direction, the other in the opposite direction.

I added a startpoint node to the offsets so you can see the direction is correct, they are not reversed.

Offset parts of Alignment where it crosses a 3D Polyline.dwg (1.0 MB)
Offsets.dyn (106.7 KB)

If you fix the offset bug, can you also fix the split bug? Sometimes the last part of a curve is lost after a split. As a workaround I add the endpoint of the curve, as described here:

Thanks @Anton_Huizinga for providing the files to reproduce the issue and for bringing it to our attention. We’ve tracked this internally for now and I’ll let you know if we need any more information from you.

1 Like

The Split bug for polycurves will hopefully be fixed soon. We are working on overall improvements to Dynamo polycurves as a bigger project.

3 Likes

That would be great!

The offset is made in Curve.Normal direction. Whats make sense for me.

Dynamo geometry doesn’t know what is “right” or “left” direction.

One simple approche to solve this is offset curves in both directions and establish some creteria to choose the “correct” side. For instance, using a point on the correct side and filter curves that are more close to it.

For closed curves simply use Polycurve.Offset node.

1 Like

The offset accepts a negative value to offset to left and positive to right. The PolyCurve direction is the same for all segments. So it is obviously a bug when some PolyCurves are on the wrong side. If you see the screenshot the first and last segment have the same normal but still they are on opposite sides.

Sure we can find workarounds for all bugs, but I would appreciate a fix.

1 Like

@Anton_Huizinga to fix this we have introduced a new Offset node that takes an additional normal input that defaults to the 2D curve’s plane normal (we support offsets for only 2D curves). This default normal can be overridden using a user-supplied normal that is parallel to the curve’s plane normal, either facing the same direction as the plane normal or facing the opposite direction. The normal direction will control the offset direction of the curve(s). It is especially useful to supply a user input normal in your workflow so that you can have all the split curves offset in a consistent direction as long as they share the same plane.

Note that this node will be available in a future release of Dynamo, 2.15 or higher.

1 Like

Great, thanks! I look forward to the new version and will test it as soon as possible! :+1:

This has been a frustrating issue for quite awhile, so it’s great to hear about a true solution that isn’t another workaround. Thanks for the fix @Aparajit_Pratap, and thanks for following it through @Anton_Huizinga!

3 Likes