Easy Feature Request: Join Input Curves For _CurveThroughPolyline Command



This is simple but a game changer. I’m praying someone can slip this into the next service release.

On the _CurveThroughPolyline command, I’m asking for an option to _Join input curves. Currently, if you select two deg1 curves with 7 control points (deg1/7) and ask for a _ControlPoint deg3 curve, you get two deg3/7 curves. History is enabled for this command, so any changes to the parent deg1/7 curves are reflected in the deg3/7 children. Here is an example of the current functionality using deg1/3 curves that are quad mirrored:

The requested _Join option would take the two deg1/7 curves and look for coincidental endpoints. If one coincident is found it creates a single open deg3/13 curve. If two are found, it creates a single closed deg3/12 curve. If none are found, it works as normal.

This is the simplest way to achieve another useful history enabled curve symmetry tool. Here is the same deg1/3 control curve pictured above if the proposed _Join option existed. The edits to a single parent deg1/3 could then propagate through a number of children created by mirrors, arrays, etc. to update a single deg3/11 grandchild curve:

Ideas for Scaling (Tapering) Blocks?
(Law) #2

Hey that would be awesome

(Pascal Golay) #3

@EricM, in case it helps for now, here’s a python that does what you suggest - no fancy options yet but that should be possible - this one (should) just make either interpolated or control point curve using polyline points, joining what it can if you ask.

CurveThroughPolyline_ex.py (4.1 KB)

! _-RunPythonScript "Full path to py file inside double quotes"

I think it should be possible to add the other options, ( degree, etc) if this is more or less on the right track.



Thanks pascal, but the whole point was to allow history to propagate.


I could use something like that as well.

(Cameron) #6

Yes! Please make this so!

(Pascal Golay) #7

Hm - for now, you can get part way there in a half baked kind of way using CrvThroughPt and moving the point objects with the polyline control points…

CrvthroughPt_History.3dm (53.9 KB)



I am using that, but you can’t insert points and it’s painful to maintain order/control the seam. Specifying the seam on a closed curve would also be helpful, but is secondary to just having a join option.

Pascal, all joins break history. I’m pretty sure you (McNeel) have good reasons for this. This seems like a simple, clean way to circumvent that complexity. I cannot tell you how much further I could extend the history tree, speed up workflows, and build truly reusable components.

(Ken Sanders63) #9

Yes, this feature would be handy!


This would be very handy.


I want this too, cuz Eric said he would beat me up if I didnt say so…

(joking)… its a really nice idea!


Looks helpful to me.


Looks like a great idea to me let’s hope they put in for us


Just wanted to follow and see if this request is being considered?

(Pascal Golay) #16

Hi Eric - well, I’m sorting out how to formulate the request… I guess I get what you want but it seems to me there is maybe a more direct way to get there - one thing is, I am not 100% clear on why you’d need to get the curve from polylines - why not just draw the curves?



There isn’t a more direct way. Try editing this single curve maintaining quad symmetry. You have to select the mirrored points and use scale to edit them:



Here’s a harder one to maintain symmetry based on a polar array:



It’d be lovely to control this repeating pattern with 3 control points, but you can’t. If you want to make the recess a little sharper, your best bet is to delete everything and start from scratch.

You will see how beneficial this option would be if you continue doing this every day, all day, for 8 years.

(Pascal Golay) #18

Hi Eric - OK, I see what you’re getting at, I think… the polyline part is a sort of convenience but the underlying goal is to make a control point pattern, for a single curve, that you can edit globally (for the repeats) from one element… am I on the right track?



Yes, the polyline is a workaround to use history to maintain symmetry or consistency. A join option with history opens a lot of new workflows that allow you to make a large edit with a small edit to a control polyline. Right now you have to lasso a half dozen points between each tweak to a design. Patterns are more difficult because you have to start from scratch. It would save so much time to reuse patterns between projects.

Most of these curves end up being lofted with loose, natural seams. They are often first flowed into position.


This may help writing it up. The join option would join the deg1 curves in exactly the same way as _Join. The output from this:

with 4 deg1 curves

Would be identical to this:

with 4 deg1 curves
_CurveThroughPolyline Join=True

The only difference being that _CurveThroughPolyline Join=True does not break the history tree of the 4 deg1 input curves like _Join does in the first example. One or two of the four deg1 inputs could be parents. Moving, inserting knots, etc. can be called on the parent deg1 curves which propagate all the way down to the single crv from _CurveThroughPolyline Join=True.

(Mikko Oksanen) #21

This sounds to me like Merge=Yes/No option rather than Join. Simply joining would leave the kinks in place, but as I understand this you expect the kinks to be smoothed out. It is likely doable, but requires a tool that sorts the input polylines into contiguous chains.