Joining SubD vertices?

I added your comment to the open report on this It has to do with the sub-object groups for these check boxes.

1 Like

You know you can use any combo of keys as as alias? For instance e was taken, so I used ee for edges filter. ff for faces etc.

Hi @theoutside
If that was directed at me: Thanks, I know - it’s just that I have some 260+ aliases, so all the good ones are already taken. I work with one hand on the kb (right), the other on the mouse (left), and try to keep my alises as short as possible, and easy to type with the right hand.

1 Like

I think we are talking about different things Kyle,

I know even a bit more than that. I know that if a specific vertex is at a known, precise XYZ location (within file tolerance) I want to give Rhino an unequivocal input to say : stitch (merge) these other vertices to that existing vertex’s location.

This is what Rhino is doing already with the 6 steps that I listed:

I know what SubDs, Nurbs, Breps, Meshes, Voxels do, but please let’s not confuse the topological limitations of each with a UX limitation that is wanting me to use a mouse click (and a huge liability to miss-click) to do a precise _Stitch (meaning merge) just because your team is not able to have ‘order of selection’ memory.

Why do I want to be 100% certain of where a vertex goes? Because we do use SubD for all the things many say ‘we shouldn’t’, including generating tooling geometry. So if we have to work with existing information, mating surfaces, fixturing, etc. we need to be CAD exact. And we have proven that this is doable. So please do not minimize what we do for a living and how we do it. We all work differently, and that has always been welcomed at NcNeel.

Let me explain why this request is so important for my team: We never trust Rhino (or any CAD/ non-CAD 3D program) to do certain things by mouse input, for example:

  • location of a mirror plane

  • moving a model from point A to pint B (in fact I personally never move models in 3D space, ever)

  • flattening something (via Scale or SetPt)

  • collapsing geometry (like this Stitch to second vertex location)

Developers should always recognize that need as something important. Dragging is a liability, when a miss-snap means thousands of dollars’ mistakes.

I’ve noticed a tone lately coming from many of you an McNeel that is very worrisome: “No look, everything is fine, look it all works great here in my cube example just fine, all I have to do is do this, and this, and this, and this, and create this macro, and change these settings in my options, and, and,… and it’s done. Simple!”

…and that’s the problem: you have waaaaaay too much friction in SubD, not enough smarts in the underlying architecture, and an attitude of: “This is not CAD, don’t expect it to be very good.”

I’m not buying it. These tools need a ton of more/better work IMO. If you cannot even honestly admit that, we have a much bigger problem than tools. Admitting you have a problem is the first step of fixing it, and we are not even close to that.

I know you want to ship, and look, just admit all the shortcoming and say: 'We are going to ship anyway" I’m fine with that. I’ll update to 7 on day 1, no matter what, but let’s have more productive discussions.

Speaking of that, I need to do better too. My videos the other night show clearly I’m really frustrated where things are. I don’t want SubD in Rhino to become what some other areas in Rhino already have become for us: “Not Good enough, stay-away material”.

I hope this helps explain why I’m so frustrated with this stuff.



I’ve got to sympathize, at least, with G’s main point here: that precision and SubD both can and should exist in concert – for the sake of moving the needle, and in an attempt to make Rhino preeminent.

Achievement of such is where the value prop lies, IMO, at least for manufactured (tooled) product. I do believe such is well known, btw…though reinforcement feels better, and never hurts, in consideration of the goals. (and success for all!)

I’ve got stuff that is going through molds too that was a SubD, and do strongly advocate that SubD is not, and should not, be viewed solely in the context of ‘blob slapping’ – as good as some people are at ‘blog slapping’. (which is really quite impressive BTW). From a precision standpoint, view SubD in the same (precision) light as nurbs! Really!!!

To date, my success deploying SubDs all the way to tooling always involves nurbs, mating surfaces, fixtures, etc. The precise nurbs surfaces are overlay ‘control’ surfaces where the key areas of the SubD form are ‘pulled’ to, and the ‘in-between’ more freeform surfaces are stitched (vertex merged) to the ‘nurbs controlled’ SubD sections. Thereafter the nurbs control surfaces still play a subsequent ‘pull’ roll, as the stitching process, etc., can muck things up. Precision (continuity continuous) matching to mating surface is paramount too. This is all something that current Tsplines is good at btw.

Some of this may sound arse-backwards to some, but consider that it is only deployed when there may be advantages to having the form as a SubD over pure nurbs polysurfaces. Furthermore, I have held the opinion that ‘precision SubD’ (to coin a term, and whatever the heck that means, and however such manifests) is the ultimate future, negating need for all these wiz-bang nurbs plugins people may fear loosing one day. (or clutching to older versions for dear life…)

Unfortunately, I can’t comment with any authority on the WIP in this regard because I haven’t really tried to use WIP SubD at all in any significant way, sorry, my bad - one day. Still, any further new tools, UX, precision SubD modeling advances that G is trying to drive-through here should help add value, IMO.


the only way to make subd “precise” is to allow for snapping of verts… we can already do that.

the only way to get “tighter tolerances” is to have more faces on a subd which increases complexity, file size and injects the opportunity for inflection into the model.

these are 2 opposing truths…

To get smooth light SubD, you need less faces this = less “precision” (yet you can snap all the verts you do have numerically via osnap already)

To get a “precise” Subd, you need more faces and as such add a ton of complexity that you will have to deal with downstream. Particularity bad if you have to data transfer.

There is no in between…

if you want a smooth Subd that snaps to a precise CAD drawn circle, you will have to add a ton of faces to get it to be “precise”. This typically wreaks havoc with your topology and can cause headaches when modeling down stream.

my solution?
model in subd to what you want keeping your model as light as possible,
then convert to nurbs and use blend to bring the subd and the cad details together.


Backwards… :wink:

Hmm, now you make me think!.. :thinking:

Yeah, different ‘process’ when driven by nurbs for sure.

As for data transfer, actually, current Tsplines converts to decent patch layouts that we have never had issues with, at least when that goes to MCAD. (Creo/SW/Fusion)

that’s my job :slight_smile:

Can you guys please split this thread? I started this to talk about UX friction, and report bugs in the subD tools.

You are now all getting philosophical about the meaning of accuracy and precision in different topology types. And in a very miss-informed way that I rather don’t get into right now. It’s Friday afternoon here, summer, and it’s sunny outside.


Cube? Have you seen the subd challenges I’ve been putting up? Hardly cubes.

I BEAT on these tools every day 8 hours a day.

If you have specific needs, let’s go thru them step by step so we can address them.

Two things I need desperately (unless I’ve missed them).

  1. Multi face local scaling and rotation (just as you can extrude multiple faces at the same time by their normals).

  2. Multi face extrusion with an option to not keep the faces together, for extruding faces next to each other.

1 Like

Both have been requested and are in the wish list- won’t happen for the v7 release but myself and others are leaning on it for the next phase of SubD development.


Hi Kyle,

Maybe you have been too busy, or distracted, but it seems like your comments are missing all my points already explained in this thread by me so far. So I’ll try one more time…

I was referring to this example:

where you show that you are relying in your mouse/attention/snapping skills to Stitch vertices to the last vertex’s position. And I already explained to you that’s not an acceptable workflow when you are selecting in the middle of a very complex model, with lot of snapping targets that are not what you want to snap to, ever. BTW I have asked a long time ago to have a snap filter to only snap to selected geometry. Which it would totally solve this specific problem.

That’s great. We’d love to do that too someday, but I can tell you that since in our team we only use what’s the best for the job, and we all have given SubD Tools in Rhino V7 a fair test, we have all concluded unanimously that Rhino SubD is just too slow. Most of us are using Modo, one is Using Blender and one Modo + Tsplines.

I recommend you also have a good benchmark of what the competition is doing (BTW, it drives me nuts to hear every one of your coworkers sayings: we don’t look at the competitions!) …and what is the expected quality in a production tool. I think for the people who have never used SubD what you guys have is great, for the rest of us, it’s a terrible downgrade in productivity. Do you see that too?

Right now 8-hours of work in Rhino SubD yields about 3-4 hours worth of billable work in a better SubD tool. Maybe not a huge deal of you are doing one thing here and there, but go try working on fully detailed models for a week or two, and watch your / your clients’ budgets melt away with very little to show for. When you run a business of high throughput this is a huge deal. This is why I’m saying this stuff is so bad. It’s bad business to model in SubD in Rhino if you are trying to do it for a living. And it should not be that way.

I know replicating a ‘polygon-slapping’ workflow like what Tsplines/Modo/Maya/Blender are doing is not ideal, and not the best thing for Rhino to emulate. But there are some basic levels of speeding up workflow that MUST be there. Not keeping track of selection order (the reason why I cannot post-select vertices and tell them to stitch to last-selected) is a core limitation that will hinder all kinds of selection tools, that Rhino also doesn’t have yet.

I already listed one, I repeated it by quoting, and I’ll re-quote it again, for the third time:

Can you please confirm now that you read this? and that you understand that from our point of view 6 steps for this is just not ok, and that relying in a mouse/viewport/snap as an alternative is not ok either?

…speaking of moving things around with keyboard and pickable input… I today was layout out plans for a new studio, non-critical work, but after doing a bunch stuff I realized that some of my desks where scaled 1D smaller in one direction. Why? because while I was moving things around I must have accidentally clicked the scale handle:

That is bad design IMO. And man have a been vocal about all the gumball problems and liabilities, yet here we are, destroying models.

I already did for the Stitch vertices.

I also already listed all these issues, also summarized a second time around, and now doing a third pass as a quote:

I really hope this helps, and if it does not, let’s all just move on.

Have a great weekend,



I read everything you say.

Stitch is currently Going thru some revisions,

The goal is to be able to prepick anything (edge, loop, fave or vert) and have it stitch. Enter for average, slide left or right to locate elsewhere if you don’t want to average.

Post pick will have auto indexing.
Stitch, pick 1st vert, auto index to 2nd vert, enter to average or slide to choose.

Same for faces.

Same for loops.

Partial loops will have to have an enter to index to 2nd set.

I am doubting that this slide feature is useful. Just like @gustojunk I mostly want to merge a vert to another or average out. In T-splines I had a short cut key for that:
Pick 1st vert, hit z, pick 2nd vert > merges to 2nd
Pick 1st and 2nd vert, hit z > average out location

This worked very well

What does auto index to 2nd vert mean? Is this essentially the first behavior of T-splines I just described?

Really? That’s the one thing left that Clayoo has that Rhino SubD doesn’t. Their plugin is super buggy and super slow but multi-gumball sure seems like a basic function.

Hopefully we’ll be able to work around it with some Grasshopper components? Please?

A feature that would be very helpful would be a way of highlighting coincident vertices. We have tools for other problematic subobject situations, like the ability to show nonmanifold edges. Highlighting coincident verts fits within that theme.


Thanks inju
This is what I looking for !


Hi Gustavo -

On the list as RH-59306.

1 Like

RH-59306 is fixed in the latest WIP

1 Like