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:
@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.
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.
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.
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
_SelectAll
_Join
_SelectAll
_CurveThroughPolyline
Would be identical to this:
with 4 deg1 curves
_SelectAll
_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.
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.
