Grasshopper's curve offset worse than Rhino's ?

I am struggling with a definition because of all the extra little segments added in the corners when offsetting polycurves (polylines made of lines and curves).

It seems that GH's offset tool adds these little segments in even more cases than Rhino :

between line segments, Rhino manages to extend the lines to avoid creating extra segments, while GH makes them even in this case.

This screws up my definition because there is no more one to one matching between the original curves and the offset curves.

I wonder how all the smart guys out there deal with this...

Cheers,

Attachments:

CrummyOldOffsetCorners.jpg, 131 KB
GrasshopperOffsetPolyline.jpg, 10 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on January 7, 2016 at 4:21am

I have code that does this elimination automatically - BTW: NOT like the reduce component (code means C# and no GH component). Notify if you think that such a solution could be useful to you.

Permalink Reply by Olivier Suire on January 7, 2016 at 4:41am

Hi Peter,

of course it would be useful to me, and to everyone using curve offsets I guess :)

I can't understand why Rhino still has this kind of awkwardness...

Permalink Reply by peter fotiadis on January 7, 2016 at 9:04am

OK, in general there's 2 ways to address this issue:

1. Like the approach for elimination used in this def attached (planar curves/polylines). The def uses the offset Curve method and then a "clean" pass gets rid of the co linear nodes. Spot the user option (no elimination/"clean" shown: thus the unwanted stuff [nodes with angles > Math.PI]):

2. Using solely trigonometry and vectors (AND avoiding at any cost the offset curve on a patched surface Method: exceptionally slow) in case of non planar curves/polylines. This is certainly an "approximation" but since it's roughly 200+ times faster than the offset on surface ... well ... you get some but you give some as well. For instance you can do offsets in up to 1K non planar polylines ... "almost" in real-time.

All the C# based solutions (solely for AEC purposes) that I write they use the method 2 (even for planar stuff).

Note: Load Rhino file fist (there's 2 demo cases: polylines/curves and planar breps).

Attachments:

offset_polylines_and_curves_V3.3dm, 458 KB
offset_polylines_and_curves_V3.gh, 143 KB

Permalink Reply by Olivier Suire on January 7, 2016 at 10:30am

Hi Peter,

I tried out your definition, but I found that at least in one instance, there was a fail in the cleanup of an offset corner.

If your method looks for colinear nodes, it will most likely fail when the original curves were not lines, right ?

Attachments:

Cleanup Fail.jpg, 37 KB

Permalink Reply by peter fotiadis on January 7, 2016 at 11:00am

Hi Oliver

Indeed but technically ... it doesn't fail ... it just passes control to the OEM offset Curve method (*) without smart cleanup IF the "item" detected is not a polyline.

But on the other hand ... I could add some lines of code more (in a V4 update, soon) to "clean" similar situations (i.e. remove the co-linear node if the segment is line and join the curves if the segment is curve - like the "mixed" case that you've provided).

This means that currently the clean up works in polylines.

The selected line is standard Rhino Method without any post process.

(*) available options for offset style are only applicable for that case.

Permalink Reply by Markku on January 7, 2016 at 4:37am

In some cases component OffsetLoose also helps.

Permalink Reply by Olivier Suire on January 7, 2016 at 5:24am

Thanks Markku !

I dismissed this component because I thought it would offset only single curves, but indeed, it manages to offset polycurves and does a good job in the corners.

The description of the component is somewhat misleading here.

Also, I'm not too sure why it flattens the list of curves when the input is a polycurve.

The other component keeps data structured.

RSS