Agree on 1. Your video makes a great case. But this should only work along edges, right? Splitting between edges and re-creating faces on either side of the split that could be triangles or ngons seems like it might be messy.
Agree on 3. _Copy and _CopyToClipboard should work on all subobjects: mesh, SubD, Nurbs. It’s intuitively what a user expects subobject manipulation to allow. If a program lets me grab an edge and move it, altering an object, I expect to be able to copy the edge and paste it in place, or copy it and paste one or more copies elsewhere. It shouldn’t replace things like _ExtractSrf _DupEdge and _DupBorder, but it should return the same results in the same context of use.
But again: _Copy already works. @gustojunk I have _Copy set to control-alt-C on my keyboard options, I use it all the time. And for finding workaround for things that aren’t done yet in the Work In Progress Rhino 7 because it’s a work in progress, it’s been very handy, many times, I’ve been using it for months. _Mirror is handy this way too. It also produces a new SubD from subobjects.
RE: 1 (split edges): yes on existing edges, otherwise we are talking about very different tools like a knife, or polygon splitter, etc. Which of course we should also have, if we want to have a full featured modeler. And like all tools: they don’t have to be used by those who don’t want Ngons or whatever.
Re: 3 (Copy subobjects) The problem with _Copy is that it’s not really a replacement of _CopyToClipboard, but rather a one-shot combination of _CopyToClipboard + _Paste.
Sometimes I want to do the paste later, or on a separate session of Rhino, or _CopyToClipboard (a subObject), close the file and paste it on a newly opened file. Or I want to use _Cut instead of _Copy.
Thanks Gijs, that makes more sense. Of course if you have a series of 10 loop selections across a model, you’d have to do this 10 times, and what’s even worse: you must rely on a tool that needs snapping (and could possibly miss-snap) to do it, so we have an approach that is both extremely labor intensive and very prone to user error. We need to do better
But to get a really good circle in subD we need a way distribute the control points evenly around the circle. So in this scenario, I’m still doing it manually. (Note the bump at about 1 oclock on the hole in the pic above, versus even spacing in the pic below, Subtle, but it matters.)
Sometimes it stacks two adjacent points and then leaves a double space between two other points. So, like, with 9 points, the result will appear to be 8 spaced evenly along nine divisions, with a gap.
In my case it’s easy to spot the double point because all my surrounding faces are quads. I just find the triangle, space the points out a little, run the script again, and the result is good. This seems to be about 1/4 of the time so far. I bet the less complicated the mesh is, the more it will work. In a bunch of cases this will save me tons of time. Thanks!
The reason is that the script fits a circle, then divides this circle and pulls each point to the closest point.
At first I tried to do point by point but a loop of points is not organized in a logically ordered fashion.
I might try to first pull the points to the circle and then do a second move of each point to the closest division point.
For the moment if this happens you can move the point that fails a bit and run the script again.
Yeah this is already super useful. I kinda figured you were counting points, then dividing the circle.
The other thing it does is draw the circle, which, when it glitches, is a great thing to have to snap to. It also tells me which of all the circles I’ve run the command on.