Running into an issues with offset. Can somebody explain why Offset is giving me a weird result with this curve?
When I zoom on it, it seems to be a super tiny curve.
220602 OffsetCrv.gh (11.0 KB)
Running into an issues with offset. Can somebody explain why Offset is giving me a weird result with this curve?
Hi @siemen
It’s quite strange, it works with other numbers but not with -1. Try to add a Fit Curve component before the Curve Offset component. That problem may be related with the way you constructed the curve.
Regards!
It fails where -1.16 < offset < -0.04. Otherwise OK.
If you explode the curve into its 27 segments and offset them they all offset correctly.
If you rejoin the segments and offset the closed curve, it offsets correctly…
220602 OffsetCrv 2.gh (21.8 KB)
Thanks for looking into it @bbalbastre & @jeremy5
FitCrv seems to solve the offset but alters the curve to have way too many control points to be usable. (These will be converted to machine code and keeping the file size of the code low is essential)
Exploding and rejoining is also not ideal, as I assume the starting point might change in this process? I guess I could add more code to make sure the start point is aligned again. The weird thing is also that when I explode and join manually in Rhino, the problem remains the same.
Would be great to know what actually causes this problem, rather than having to implement a solution for this 1 in 10000 chance edge-case.
Do you really need all those control points?
Do you mean these?
Hi @siemen
I do not understand why this is happening… it may be a bug definitely!
I tried one way to reconstruct the curve preserving the control points:
I know this is not a solution but maybe with this you can continue your work while waiting for a right answer.
Regards!
Curve_adjustment.gh (10.9 KB)
Interesting, is there a difference between using your shatter technique of joining and the explode curve component? And do you know if this always preserve the same seam location? As in, does the Join Curves component join things in the order it gets its input?
Because Rhino’s underlying offset curve algorithm is somewhat unreliable.
There are a couple threads on this forum where folks have attempted to solve this, but none of them fully resolve it in one nice clean method.
I’m not a math guy but it sure looks like part of the problem is that doing the math for offsetting curves using true curves as the starting point is just really hard.
Programs that need to do offsets in order to create CNC toolpaths, like RhinoCAM, appear to get around this by doing everything as very high resolution polylines, which apparently are easier to offset reliably.
The Grasshopper plugin “Clipper” has a great polyline offset component. The tricky part of using it for offsetting curves is converting from curves to polylines and back reliably. You can absolutely make it work within tolerances if you make polylines with a massive amount of segments, but this is often very slow. In some applications, it’s a great solution, though.
I would love for someone with better math knowledge than me to explain exactly why offsetting curves is so hard to do reliably. It’s a frequent obstacle for me in creating grasshopper scripts for automating relatively basic geometry in my CNC work.
I don’t believe so (and in this case it didn’t) but unless a dev confirms it I think you are right to be cautious.
If you bake the original curve (bad) and the split/joined curve (good) and run _What on each in Rhino, the only difference is that the domains of one line and two polyline segments change. The remaining segments are all arcs and show no differences. (With respect to the three domains: the length of two are unchanged by the shift, the third is 0.001 different). Why a domain change should fix the problem, I have no idea!
bad curve What.txt (4.3 KB)
good curve What.txt (4.3 KB)