Bug In V7 SR8's Joincopy

[EricM (Eric Paul Marvets)]

@Trav

curves were picked and then the command is ran vs running the command and then selecting the curves.

No, it’s random. It’s not like _CurveThroughPt which does rely on the order of point selection. _CurveThroughPt’s seam is chosen at random (not first or last point selected), but the seam will not migrate or switch directions.

Complete info with demonstration video showing the issue is here:

CurveThroughPolyline/MergeCrv/Joincopy

This came up while trying to figure out a workflow in a live stream. I originally asked for CurveThroughPolyline to have an option to join curves that were within tolerance. Somehow, that ended up becoming MergeCrv and Joincopy. Three things: There’s no way to control the seam with Joincopy/MergeCrv. You get halfway through a workflow and a seam will suddenly shift and wreck the surfaces you’ve created. [image] [image] JoinCopy_MergeCrv Bug.3dm (124.6 KB) Joincopy being a separate co…

Exactly why MergeCrv < Joincopy can be found here:

MergeCrv - disappoinment, flawed,

MergeCrv is a disappoinment and flawed. It could be very useful for me but as it exists it is of no value. Starting with degree 3 input curves which are G2 continuous the result of MergeCrv with Roundness=1 is lumpy and very different from the input curves. At a minimum a note needs to be added to Help warning the user that the result will have a different shape than the input curves. The algorithm with Roundness=1 appears to be simplistic; nothing more than creatng a curve using knots and cont…