Wish: Offset - Allow Multiple Input Curves

there simply is no way to offset several curves at once with the option both sides.

we have offset multiple which allows you to offset several curves in one arbitrary direction, arbitrary because some curves have the end and start point in a different orientation making it a mess rather than being helpful. and using just the other direction on a priorly grouped entity seems buggy and does not allow you to just choose the other side making even more of a mess.

i usually help myself with piping all the curves coupled with silhouette but that also requires grouping the pipes to get rid of them easily or do delete all pipes manually making it again just more work then which makes tediously offsetting each single line sometimes just more efficient when not having to offset hundreds. but when offsetting a real amount then there is not much one can do.

i found @Helvetosaur posted a script here which is limited to planar curves only but at least it helps with these.

am i missing something? if not my question would be, why not simply being allowed to select several curves for offset?

Offsets of non planar curves are unreliable, which is why the script is limited to planar curves.

What do you mean by “unreliable”? The results may be mathematically incorrect? The results are correct but may not be what the user expected?

If an offset is defined as the curve at a distance from a given input curve, then in the plane there are 2 possibilities - one side or the other.
For a spatial curve in 3d, if we aren’t limiting the solutions to some plane or surface, then all sorts of curve fulfil this definition of being at a given distance.
For instance - a helix around the curve could be considered an offset - or indeed any squiggly curve drawn on a constant radius pipe around the input.

Either or both… What do you think of the offsets in the file below? The polyline was offset from the Top viewport and the smooth curve from the Front viewport.

3DOffset.3dm (2.0 MB)

They appear to be offsets using the Cplane to determine the offset direction of each point on the polyline and curve. Whether they are what a user without experience offsetting similar non-planar polylines and curves would expect is another question. Non-planar curves can appear to behave strangely if the expected behavior is based on planar curves.

What do you think of the offsets of the curve in this file?
Offset3d Example.3dm (2.7 MB)
The curve is an exaggerated sheer curve of a boat. I might need the Top Cplane or Front Cplane offsets. The Right Cplane offset wouldn’t be used.

I would say the results of Offset when applied to non-planar curves may be surprising and unexpected. I would not say “unreliable” because unreliable implies some amount of randomness. The results are not random, just not what may be expected.

I said “unreliable” because Offset in Rhino is in general “unreliable” - You will find many posts here on the subject. Most often it’s incomplete results in situations where the offset of a single curve should end up split into several curves.

This particular unreliability is not necessarily related to non-planar figures, and I don’t really know if they increase the possibility, but I’m always wary.

In the 30-second example below, offset the curve 3mm to the inside. If you click somewhere in the middle, the big square is offset, but you will notice the 4 corners are missing - the correct result should be all 5 closed squares. If you click inside one of the corner squares to determine the offset direction, you will get only that one. I guess I would call that “random”… :stuck_out_tongue_winking_eye:

Offset3mmInside.3dm (2.0 MB)

Thanks @Helvetosaur for the script.
If this topic is read more about wish / improvements for offset:
i would love to have mulit-Value-offset - allowing my to type for example:
which should generate at least 6 offsets per curve -3 to the inside,…
it would also be ok to type 3 enter -3 enter 5 enter 6 enter …
kind regards tom

So “unreliable” is not due to curves being non-planar.

Offset starts by finding the offset point using the user selected location, and then traces out the offset curve from that location. The apparent randomness is due to the offset of some curves, generally planar (rather non-planar) curves such as the example, having multiple solutions depending on the location along the input curve of the start point. That is inherent in how the offset is defined.

Non-planar curves usually do not have that particular problem/feature. They can have the seeming weird “jumps” in certain views such as seen in previous examples. That behavior is directly related to any non-planar curve appearing to have reverse curvature when viewed from certain directions.

The fundamental problem for the user is defining the offset of a curve can be more complicated than the user might expect.

I disagree. This is not a problem that can be laid off on the user by saying “yes, there are multiple solutions possible, you just didn’t click in the right place”. No matter where you click in this case, you get an incomplete solution.

There is ONE correct complete solution to offsetting the object I posted (5 separate closed figures). Rhino does not find that one because its algorithm is set to find one possible valid offset and stop there. Most CAM programs can do this easily with their pocketing routines - and this since the '90s or earlier.

Concerning offsetting non-planar curves:

Offset in Rhino is still based on planes. If the curve is planar then the plane of the curve is used. If it is non-planar then the active CPlane is used and Rhino tries to figure out a projection-based offset based on that plane. The “weird jumps” happen in the areas where the non-planar curve gets near-parallel to the projection direction because the 3D offset needs to “change sides” to comply with the user-chosen (planar-related) offset direction.

In the example below, the helix was offset 5mm using the Right view. You can see the points where the result needs to flip sides - to comply with the Right view CPlane-based offset side. A true 3D offset (not based on a plane) is one of the infinite number of isocurves of a pipe of the helix.

3DOffsetHelix.3dm (2.4 MB)

But you know all this stuff - far better than me.

i am already shy to write wish since i made so many empty wishes which got no response i thought adding just one more useless wish will not gain anything anyway, but for the sake of it i changed it after all.

so is there anybody out there who can explain why that is so, or maybe can create a tracker?

@wim i found nothing in youtrack can you add this? or do i have to register? i just cant understand why multiple selection is possible with OffsetMultiple which has a different task (which is partially broken) but not possible with regular offset.

i think that would be rather an improvement suggestion for OffsetMultiple.

I’m wondering if the reason the BothSides option has been ignored is perhaps the unfortunate bundling into one command the offsetting of multiple curves plus having multiple offsets.

In any case, yes, this is a completely logical option for OffsetMultiple when single-offsetting several curves - it should have more or less the same options as normal Offset - including the ability to cap ends, do loose offsets, tolerance etc.

If it was me, I would separate the two procedures. OffsetCrvs could be a new command to just offset several curves (single offset) with the same options as normal Offset. Or even better, roll that functionality into the existing Offset command by allowing the user to select multiple curves.

OffsetMultiple could then simply be used for multiple offsets - with or without the ability to input a list of variable offset distances as asked for by @Tom_P

I made two YouTrack items:


Dear Mitch - i think it is a general question how to name / handle similar, redundant commands like

orient, orient3d
move, copy
offset, offsetMultiple
_rotate3d, _rotate…
split - split (Isocurve for a single surface is picked)…

i am a fan of having a single command, that handles all options - not 2 very similar commands.
_rotate can become _rotate3d _pause (_pause) r0,0,1
maybe the concept of “_pause” has to be updated to handle pre / post pick.

Well, my experience is in the past, when commands have been combined, that they may lose functionality or get complicated to use, due to all the additional options needed to handle all possible situations. I’m all for simplifying stuff, but not at the expense of increasing the complexity of using the commands.

Also, as a workshop guy, I always remember the words of my junior high school shop teacher - “A combination tool is never as good as one designed for a specific job”.

This stuff has been discussed extensively since V3 when the first wave of combining tools started - and was greatly reduced thereafter due to a lot of protesting. IIRC, ExtrudeCrv and ExtrudeSrf were combined for awhile and the loss of practicality was great enough that after much uproar, they split it up again.

well as long as the naming is similar … and they all start with “extrude”… i am fine with this as i work 97% commandline based.
then maybe some kind of grouping in the commandline-suggestions would be great

… xxx
… multipleCrvs
… multipleValues
but this is really some finetuning…

@encephalon @davidcockey @Tom_P

Well, as the Youtrack items have been moved to “Future” - meaning we probably won’t get that for V8, at least not at the beginning - I though I might have a go at having the script allow non-planar curves to be offset.

In fact, just by removing the planar requirement from the selection criteria it would have worked mostly anyway, with one exception - doing round ends on non planar curves. As the original was designed to make arcs, this would not work - arcs are necessarily planar and thus need a plane to lie in. Offsets of ‘reasonable’ non-planar curves can have almost coplanar end tangents, but not quite. So to keep the ends tangent to the offsets when the input curves are nonplanar, we need to make a blend curve instead. And as even with the tangency setting, the resulting blend curves are not really arc-like, they are then pulled to a sphere centered at the end of the offset. The result is then pretty reasonable.

Have a go with this one and let me know if it errors out somewhere (likely).

OffsetMulticrvs2SidesWEnds.py (7.3 KB)

i am totally ok with this being set to future right now, specifically having a mac and dreaming of a speedy and productive version 8 for apple silicon much rather.

still mcneel employes could be a bit more proactive in conveying ideas and wishes into the tracker system, we all profit from that. even though anybody can register there it should not need us registering or even thinking about it to meddle with this. i honestly was thinking several times to register, i can remember @wim telling me about it quite long time ago that registering there is the only way to get it logged effectively i really tried to avoid that in all my discourse lifes here, if the suggestion is not good enough nobody will care anyway they all have plenty to do, why bother with more. sorry that got ranty again.

anyway thanks for the log and for the py.

Here’s another good example of “unreliable”…