Subobject selection vs Object selection -- SubD -- selection extensions

I respect that you differ here. But it’s not correct that they had to solve things differently because they are a plugin. Indeed it would have been greatly easier for its makers to stick to Rhino conventions (and one had already started off that way). Establishing new conventions was a result of user requests and caused them a lot of work.

  • I will close my eyes and wait for V6.
  • I totally understand what you mean. It’s just different perspective.
  • In the end, I prefer what Rhinoceros favors.

Don’t mode me in… If there’s any way at all we can use SubDs and sub object selection without switching modes, we should try that first.


Hehe… I actually suggested a mode which would free the SubD-Modeller from the hardcoded modality inside each single Rhino command. The “press enter when done” is nothing else than the OK to press inside a Popup. Don’t press it, don’t step forward.

In any good SubD implementation however one can tell the program to throw in 3 edgeloops and may go through the subsequent inner 20ms conflict (– no wait, 2 should be enough to harden that corner, well maybe 3 was actually better…) without typing numbers and without ever touching Enter to let things register.

Leaving theory away (a great friend of non modality myself)…What concrete editing options would one inevitably lose by establishing a workmode similar to PointsOn for another entity type. What exacty would spoil the elegance?

I think this kind of selections

would also help to better organize Rhino commands. No more need for different commands to handle points, curves etc .
But, please, along with modifier keys, also give us regular (‘mouse friendly’ and ‘macro friendly’) commands.

I would also avoid different modes, if possible, or would make different modes optional, so that you can choose to use another mode but are not forced to.


Almost a week ago we started this conversation together. I was lucky to have such an interesting group of people to talk with. Maybe this thread has been entertaining for some.

For me, it’s been tremendously useful!

So, thank you for joining it.
I would like to summarize some of the broader suggestions, so that we have something like a list to discuss internally (sorry – I will be omitting some parts, but feel free to point where I have been too hasty).

7) A more advanced menu that would open, similar to the MMB one, but with a temporary selection option that is chosen by hovering with the mouse over a certain area. This would trigger a half-mode for the next selection (I think?)

8) Using a MMB click to subselect. Two interference: one is the beloved pop-up menu (for some) and the other is with window-selecting objects that would interfere with panning for people who do not use Shift+LMB for that. It could be integrated with some type of more-modal or more-command-based interface to cater for trackpads and simpler mice needs. Choosing how to subselect an edge rather than a face is still a bit unsolved, except with filters/modes.

9) Double-click or F10 to “temporarily explode” an object into its components, and then use standard selection for its inner parts. There has been some discussion regarding double-click as a choice, and F10 is “far away” from fingers, in the middle of the keyboard.

10) Tab key to toggle modes or a-s-d-f (but what enters the a-s-d-f mode?). Still similar to 3) otherwise. Tab is not used for many other purposes in Rhino so it is readily available. Seems to be a classic of SubD implementations elsewhere.

This by no means should stop this conversation if you find that you have something more to say.
For now, thanks for letting me and the rest of McNeel hear your voice, your ideas, and your perspective. Your point of view will be considered in this and other developments related to the UI.



Hi Giulio, all,

I have not read all the replies, especially since most of them are just arguing about what keyboard shortcuts are best, I don’t want to add extra opinions of this area, well except for one thing later below in this post…

I would not feel very attached to this history. This is the first time I heard that such filtering mechanism mid _trim command exists. So most likely 99% of your users also don’t know about it.
Also status bar toggle makes a lot of sense.

I like this idea, using the same combination as we have in V5 for one-time sub-object selection would be a good transition/learning for people? or will it be more confusing?
I think it would be great to have some other visual that you are in subobject mode. Why not have point-on, like when you invoke the _PointsOn command. When you see an object with points on in the viewport you know you need to ESC out of it to do other stuff.

I think the status bar will become too crowded, but maybe if the objects you turned into sub-object mode contain meshes, then that automatically floats on a selection mode toolbar? Unless yoru workspace already has that always visible? Can you be able to detect that?

this suggestion (or mine of points on) makes a lot of sense, but it also needs to be able to be toggles from the display tab. Many times we will want to be making design changes, and visually pushing/pulling in subobject modes and don;t want to have ‘warning visual modes’ in our way of making visual design decisions. makes sense?

I like the idea, but I’m not sure if I want it to make the selection or if I rather just highlight (half as opaque as a true selection?) what it would select, And then a double clock or a commit will make the selection.

I have a couple more thoughts about some of the overall feel for the comments I’ve seen seeing here:

I think adoption of SubDs in people’s workflows present many challenges, and the way the current apps in the market deal with this stuff is not a great example of what works for rhino users. I think of rather trying to emulate the Tsplines way or the Modo way, or whatever let’s realize that all those products have had a tremendous failure to be widely adopted or relevant in the Rhino community. Splines is extremely modal, clicky and slow and not fun to use at all, even if it didn’t crash every 5 minutes. Modo is extremenly complex and deep that makes it very intimidating for most people. So I would use them as great examples of what to do, for those few things that they do well, but also of what NOT to do in many cases.

re: toggling modes. Toggling between faceted/smooth vs. toggling between object/subobject

I think you are still thinking that TAB would toggle between Object/Subobject.? if so I need to clarify that one area that does work well in Maya, Modo, Silo, etc is that TAB toggles between smooth/SubD mode and faceted mode. So just clarifying: Tab should toggle this latter behavior not the former, correct?

toggling subobject: First: multi-subobject, Then filtering!
When I shift-control click a nurbs cube in Rhino (mid-face) I’m able to select a face:

When I shift-control click a nurbs cube in Rhino (mid-edge) I SHOULD be able to select a shared edge:

unfortunately this is not tuned right yet (bug report!)

When I shift-control click a nurbs cube in Rhino (on corner) I SHOULD be able to select a vertex

unfortunately this is not tuned right yet (bug report!)
But I should be able to get this

I think this should be fixed so users that just click where they want on their model to click the collection of entities that they want, without messing around with any filtering at all.

The same approach, consistent with NURBS’ “any sub-object is pickable” should apply to meshes. Also at the same time as nurbs.

Filtering for added granularity: NO ASDF!

ASDF is not something that you want a geek be explaining to a human. We geeks, using american layout keyboards know what ASDF means, and where they are located, humans do not! They most likely associate it in conversation with ASDK and will endup buying fusion. And if they are using an AZWERTY keyboaard you are out of luck.

I think those keys should be: 123… easy to tell anyone and to be remembered. “remember when working with meshes and you want to tweak them it’s as easy as 1-2-3”, any trainer will love you for that. disclaimer: Modo uses that as their default, and it’s the single shortcut that all our users that still dabble with modo remember:

also the fact that they show you the key shortcuts right on toolsbars does help.

last, and most important point: A well pointed Ctrl-Shift-Click …is both a suboject selection mode entering plus makes selection:
Of course i should not have to:

  1. click on an object
  2. activate sub-object mode (ctrl-shift)
  3. select the face I want
  4. drag it.

when I can place the cursor on the face that I want to drag and simply:

  1. click on the object’s face (that activates sub-object mode + selects the face I want)
  2. drag it.

If I have to first select F10 in the suburbs of my keyboard, or any other non-object-oriented function key, before I can click on my suboject directly, we just have introduced unnecessary friction.



@gustojunk I re-read this and I am bit confused by this last point. How can this distinguish between full-object and sub-object selection? How will it pick the whole object?

Sorry, because I’m ctrl+shift clicking as I would do today. So I activate the subobject at the same time that I pick the subobject’ face. Makes sense?

[quote=“gustojunk, post:41, topic:20544”]
I think of rather trying to emulate the Tsplines way or the Modo way, or whatever let’s realize that all those products have had a tremendous failure to be widely adopted or relevant in the Rhino community. Splines is extremely modal, clicky and slow and not fun to use at all, even if it didn’t crash every 5 minutes.[/quote]
Tsplines actually introduced quite a few mechanisms to make using their tool less modal than normal Rhino. One of them was their transform widget, long before Gumball. If you think that sucks you would certainly not like a SubD implementation which purely uses traditional Rhino methods. They btw also solved the ASDF vs 123(4) problem – you can use any key you want (for my personal taste any of these mappings consumes far too many keys :o)
Personally I think Tsplines has the greatest shortcoming in the area where any SubD style modelling implementation inside technical programs I’ve seen struggles: When transitioning from a blob to a part. Also I find the fact that they don’t actually use mesh based subdivision levels but only offer a toggle between control cage and precise Subdivision surfaces as a needless workflow+performance killer, I’m afraid McNeel plans to take this way too…

[quote=“gustojunk, post:41, topic:20544”]
Modo is extremenly complex and deep that makes it very intimidating for most people. So I would use them as great examples of what to do, for those few things that they do well, but also of what NOT to do in many cases.
[/quote] What I see as the main problem with modeling inside any of those large multi purpose VFX program is that geometry creation is just a relatively small part of what these programs deliver overall. That doesn’t mean that the modelling tools suck, not at all.
But even a silly cube drawn inside Modo and the like carries everything in it to animate it, to let it explode, to be part of a character rig, to be either driving or to be driven by other entities. One as a user therefore from the first minute on has to deal with complex object hierarchies, even when the sole and only goal is to create some pieces of geometry. Its somewhat comparable to setting up a simple Blog inside a CMS designed for large Online Magazines.
In Modo apart from from subobjects Vertex/Edge/Face there’s also Item Mode. An Item may simply hold the entire object (so far straightforward) but at the same time be a container for more than just a single mesh volume, which also sets a common origin for all of its subobjects. Further there’s Pivots and Centers and alongside with them comes a rich choice of local coordinate systems. All of this may make perfect sense for building, wiring and animating really complex scenes. Just a small fraction of all this however is required for creating geometry with subdivision surfaces. Simple modelling only programs like dusty Silo still deliver the proof.

We hope that it will not impact performance. I think that is what is worrying you most, here, right?

No, I consider not having mesh based subdivision levels exposed to the users and only having a toogle between super low res + edgy and perfectly smooth (á la Tsplines) a major disadavantage. Perhaps one should not do what seems most straighforward from a mathematical point of view. But I wonder if I can get across what I mean…

  1. Being able to see the cage at all resolution states is very helpful. When shaping a freeform volume from scratch it is common practice to start off with an extremely lose cage. Good modellers in this minimum complexity state already define all mayor features of the shape, they have developed a good sense of the way a shape develops in in smooth state - but one will want to have a peek here and then. The higher SubD states had to appear absolutly instantly, having to wait for a transformation (miliseconds to many seconds and minutes) as in Tsplines sucks.
    At some point the low res mesh should be collapsed, so that one has some more geometry to work with. In traditional SubD one can simply freeze the mesh approximation at the currently displayed density. Wysiwyg, no mode change required here.

  2. interoparability with mesh software.
    With mesh based approximations one can simply send a the present state of a mesh over to Zbrush to use a single tool here, from there bring it to Modo to unwrap and finally send it back home to Rhino as a mesh with the same basic topology, with some vertices in other places and proper UV’s, while the mesh inside Rhino has retained its SubD history. This ability was very vital generally, but particularly useful in early states of the Rhino implementation, with just a very slim feature set.

2a) again UV’s: There’s hardly anything more elegant as the way UV’s work in in mesh base subdivision surfaces. Slice the mesh at basemesh level and reproject to any higher level. There sure are options rebake existing UVs to true SubD and back to meshes at export time but that’s a needless source of errors. Tsplines in the last version I have isn’t able to properly retain existing texture data in imported meshes.

  1. locked data: Most SubD apps don’t expose the concept of “true Subdivision Surfaces” to the user and will not able to read your accurate data. Maya indeed as an exception has this dual system internally, but I’m not sure it can read true Subdivion Surfaces from other sources.

  2. Performance: I simply doubt that interactive preview in all modelling operations (not just subdivision) will be as fast mesh based subdivision surfaces.Tsplines after ten years of development isn’t but mesh based previews are. If things still get too slow one can simply step down one level. It’s proven, it just works.

  3. Convention: Touch and feel of Tsplines, Clayoo and the like simply will not feel attractive for someone with a background in mesh based SubD and used to the snappiness of editing here.

  4. What does one actually win by giving users accurate Subdivision Surfaces? This is an honest question. Also in Tsplines there’s brilliant options given to create perfectly curvature contionous – but still all lumpy blobs. I my opinion one rather needed to develop deeper strategies for for the smartest sythesis of Nurbs and Mesh in interactive modelling. Only representing inaccurate hand-sculpted geometry accurately througout the modelling process does nothing good in its own rights, imo quite the opposite.

I’m more concerned about workflow, I trust your geekiness on the performance side of things :stuck_out_tongue_closed_eyes: .

I also agree that the ASDF workflow is pretty much the industry standard and will promote an easier adoption rate.

I also get that using ASDF creates an issue with the command line thus the workflow created in TSplines creates a mode based structure. For them hovering the command line disabled the hotkeys and allowed for command line input. Not sure if thats the best way.

And speaking of T-Splines we have a huge base of Rhino users who will be migrating what they have learned in T-Splines into standard Rhino sub d workflow. Making that transition as easy as possible will help all of us that have been training our customers how to use those tools for nearly 7 years now.


The SubD Rhino says:
Selecting items in the viewport shouldn’t get looked at isolated from other mesh specific workflow demands.


Off topic @hifred, very cool model/render.

Thanks Miguel, everyone!

@piac I really like how 3dsMax does it. You just select in which mode you want to be in. It is very easy to understand and very straight forward to use. You can google between the different modes by pressing 1,2,3,4… is very fast way of working.

Worth checking this video out:

Is there anything we can test?


Hi @piac,

greetings from Munich, I hope your doing very well.

Are there already some of these special selection methods in the WIP, to start right now with SubD modelling?



I know the thread is a bit old, but:
To me this is a key feature for successfully working with Sub D. Being able to choose if vertizes, edges or faces can be selected, OR objects. And the ability to select only visible, or also hidden. And to have a “paint select”, not only a click or drag a rectangle. C4D works like that with meshes and it works very well.