# Loose offset Component - Curve Direction not observed

If I flip a curve using the Offset Curve - Loose component, the direction of the offset doesn’t change. This seems different in behaviour to, say, the standard offset curve.

Hello,

The offset behaviour is unpredicatible (at least from a users point of perspective). Good practise is always to check. If you deal with closed curves you make both directions offsets and check for overall curve length, to see if outer or inner. If you deal with open curves you might do a so called left/right check.

1 Like

Usually if I have a group of say 10 curves, and 2 are offset in the wrong direction, I can just flip them and the direction swaps. With the Loose component this didn’t seem to happen though.

My finding so far, is that this issue I’ve mentioned only applies to closed curves (as used in my example).

Yes, but this is no bug in the real sense. Because calling the offset functionality doesn’t guarantee ordered offset direction. It never was like this.

It is simply that the underlying algorithm works quite different. You can even decompile to see how the loose offset works.

In other words, always make offsets in positive and negative offset direction and append an algorithms which sorts out the right offset for your. This however highly depends on what you are looking for. If you only deal with closed curves, then choose the curve with smaller length for being the inner offset and the curve with greater overall length for being the outer offset.

This obviously increases your definition in size, but also makes your definition much more reliable. Offset direction issues are one of the most common spots of definition failure.

Hi Tom - yeah I understand what you mean entirely. What I’m saying though is that plain vanilla ‘Offset’ is working differently to ‘Offset (L)’; Offset (L) is sometimes preferable to create cleaner offsets.

I think it has something to do with the clockwise rule which applies for surface direction? Something along those lines. See attached file and video. See how running the Flip command in Rhino doesn’t change the loose offset direction in the case of a closed curve.

offset_vs_offset’L’.gh (7.2 KB)

Edit - this is working in some closed curve cases, but not all.

Of course they work differently, since one is implemented in Rhinocommon from core McNeel devs, and the loose offset is a Grasshopper algorithm implemented by David Rutten. As far as I remember correctly. Of course they differ. I mean indeed they do something similar but very different at the same time. In the Rhino command you’ll have different behaviour as well because you additionaly have mouse input. But again, since they do not guarantee orientation, its up the user to filter out.
If you guarantee someone to bake a cake, it would be odd if someone complaining about your cake’s form. If its rectangular or round is irrelevant unless its part of your agreement. Maybe sometimes you bake it round and sometimes you bake it rectangular. And there is probaly even a good reason, but your client doesn’t know.
Since both algorithms work in a different way, their behaviour may vary in certain situations. It actually would be quite hard to let them behave exactly the same way, if they are calculated differently.

Ok, this is indeed a valid concern. So you want the loose offset be computed based on the initial curve direction, so that you can flip them manually. I don’t know if this works out, but again, you can implement an algorithm on top doing this for you. For instance by comparing tangents at a fixed parameter (t). If you multiply the initial tangent and the offset tangent (dot product) a negative result would mean you have to flip the offset sign.

Thanks Tom. I also felt there was some validity.

My algorithm was quite simple to generate an internal offset and also join up breakpoints to create a taper illustration in a less manual way. When I have my drawn input done, I feed it in. Then I just had to flip to flip curve direction for one or two of them if they were offsetting outside. So, I noticed that flipping didn’t change anything in some cases of Offset ‘L’.

Specifically, the GH component ‘Offset’ and GH component ‘Offset ‘L’’ is what I’m comparing between (as opposed to rhino offset, to be clear).

Currently I have no Rhino on this machine, but if I find a time after work, I may upload a simple algorithm sorting things out for you, if not someelse is doing this for you. In ideal situations manual flipping shouldn’t be necessary at all. Are you dealing with closed curves only in your use cases?

If the drawn input has been done cleanly enough, the curves should be closed. See below the basic example of what I was using.

This helped me create a simple tapered loft after as well, using the original closed curve and offset, transformed up by a measure (I don’t like the output of Rhino’s ExtrudeCrvTapered - it makes it impossible to fillet with some nasty 3 sided surfaces).

Here are the algorithms I was talking about:
alg.gh (28.2 KB)

thanks Tom. How would you propose adding a function to draw lines between breakpoints, if not all line segments are straight?

My method was exploding and using all the start points (assuming a closed curve input) and making segments between them.

Given that an offset curve, when exploded, may have new segments, you can see why sometimes the loose version was more favourable for me.

There are a couple of very different solutions to this not uncommon problem and it depends on various factors.

One solution I often did was kind of:
Offset each segment -> Rebuild cp 6 degree 5 -> extend smooth -> Intersect and Trim (or instead of Trim : Circle/Sphere -> Trim at circle/sphere-> Blend between segments.

Over the time I have written many derivatives using tested and reusable code to some degree, so thats why I said „kind of“.

However as you may noticed the key here is to build in tiny helper functionality. At this point scripting is beneficial. I‘m not sure if writing you a script
really helps you in solving similar problems for you in the future or if I solve the problem for you on the first try. I don‘t even know if you can read duch a script and so I propose you prepare as much as you can within Grasshopper and solve the missing parts in a manual process…