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

With the new SubD object in Rhino, selecting, transforming and editing parts of an object by adding/removing faces and new edges (let’s call this “subediting”) become fundamental parts of the modeling process. We are excited to study how subediting should work. While we are at it, it will be great if these methods will work at least also on meshes, and where applicable on polysurfaces.

The first part of this is to improve the selection mechanism so that it is intuitive and easy to access, is coherent between different object types and is as non-disruptive for existing users as possible. Of course, these goals are somehow conflicting.

So, we would like to know your opinion and improve our current selection toolset based on your experience, also with other programs. Let’s start with what we have today around selection…


In versions of Rhino preceding 5, there was a selection filter based on the command line. For example, after starting the _Trim command, one could use _crv shortcut to filter only curves. Some subobject types behaved like their geometry counterpart. For example, in certain commands one can use brep edges as curves.

In Rhino 5, in addition to what was there in Rhino 4, we have the selection filter dialog. This has the advantage of being more visual, and allows a similar workflow as the command line one.
In addition, it is possible to select subobject with a keyboard combination that is unknown to many users: the Ctrl+Shift combo. It can save a lot of time, but it has the disadvantage of precluding utilization of these two keys for other usages: only Alt is still available, for example for copying, and holding three keys down is not very easy on the hand.

In Rhino WIP, there is an Object/Subobject switch in the Selection filter toolbar.


Suggestions that we have gathered so far: (Note: none are really mutually exclusive and some can be improved)

1) Object/Subobject button for mode toggling

[Object] / [Subobject]
A button that switches between the two. It would be similar to the half-filled checkbox in the current Selection Filter in the WIP, but more visible, maybe on the status bar.

2) Object/Subobject keyboard key shortcut.
Rather than keeping Ctrl+Shift pressed, it could be possible to use a key combination to switch between the two selection methods.
This shortcut could even be the current Ctrl+Shift: as soon as it is pressed, it could toggle the button above(?)

3) A subobject selection MODE that is pickier:
[Objects] / [Faces] / [Edges] / [Vertices]
One keyboard key could switch between each. This might be visible on the status bar.

4) A Rhino toolbar to make current filters work like method 3:
If I click [Objects], then the current selection filter will pick whole objects and no subobjects.
If I pick [Faces], then subobjects are used with faces and remaining checkboxes are unchecked.
If I pick [Edges],then subobjects are used with edges and remaining checkboxes are unchecked.

The current toolbar instrumentation could be improved, and if checkboxes are aligned with the prescriptions of the table above, the button might look “pushed down”.

5) Changing highlight color for subjection selection to a special color that is by default different than the one for whole objects. Maybe light green could work.
This would make it easier to recognize when a subobject is selected rather than a whole object.

6) With a modifier key available, we could add an option for “predictive” selection, that will be particular useful in SubD editing. For edges, it could work like this:

What do you think?
Do you think we need to explore other directions?
Given that you also know Rhino’s philosophy, can you envision selection in other ways?


I think it’s the most intuitive way to handle all options by just using one button. The only concern is AD has been adapted this method. Not sure what is the border line for copyrights. Sorry, if it’s not useful. (11.9 KB)

Spread layers like tree winkles to add more options.

Holding RMB to call out sub-D modeling menu would be great. Interface can change in many different way.

Kind of a meager reply but just today I found sub-object selection not working for grouped objects. (V5) So your quest should incorporate handling selecting inside groups as well.


My initial thought would be to hook up mesh subobject editing along the lines of Rhino’s control point editing. F10 would bring meshes into Edit Mode, similar to the Blender implementation. Without having F10 pressed clicking a mesh would highlight it as a whole and one could only apply global transformations. Mesh objects would shade in an unobtrusive way, Vertices wouldn’t have to show, Subobjects weren’t selectable at all.

As soon as F10 gets pressed the shading of the mesh changes visibly and preselection highlighting is made available, I imagine it to work on all subobjects by default. The first pick sets the filter to the respective subobject type. Done right this may work extremely well, I use this mode almost exclusively. One should also offer an alternative mode, I’ll cover this later.

F10 on surfaces offers a protected mode which doesn’t force the default Rhino command sequence but allows for iterative tweaking without having to run traditional commands. I’d wish that this worked similarly on meshes, in terms of grabbing edges and vertices and moving them around.
In addition there generally was a chance to also use this Edit Mode to introduce the ubiquitous keyboard shortcut heavy SubD command sequence. Pressing and holding the Hotkey, say X for the Extrude command with a subobject selection already established would directly do something useful, additional options could get called/cycled through with Modifiers, there was no need to press Enter to complete the command execution. Of course for such to happen one needed to pull focus off the command promt, otherwise one would only write xxxxxxxxxxxxxxxxxx. With this in place one could also offer switching subobject selection modes with say ASDF which various popular programs use. Essentially one could use this to establish a secondary layer of keyboard mapping which only works in Edit Mode.

Tsplines has hooked up its TS-EditMode in a similar way – and one has found a good way to make the promt available for input if need be. One here needs to put the cursor over the promt, then it gets focus again.

While this all might all sound like breaking with lots of Rhino conventions I here actually see potential to serve people with quite diverse backgrounds. Those who already have experience with SubD modelling were served a familiar work experience, those who prefer slowly getting aquainted with mesh editing and would like drive operations via buttons and the promt things could work that way as well.

F10 could generally also get offered to enter Subobject editing on Polysurfaces (instead of having to press Ctrl+Shift), again preferably with pre-selection highlighting. Of course doubleclick is also still free to turn on points on anything apart from Blocks* too – I also found this a lot nicer on curves instead of having them shown all the time, as it’s currently the case in the WIP.

1 Like

It’s past my bedtime and haven’t read all of Holger’s post yet.

As a none-mesh and none-subD user, my concerns are mostly aimed at keeping the current workflow alive. I am opting for alternative 2 but wouldn’t mind a different single key or combination. I find that F10 is a bit too far to the right of the keyboard for something that I would use a lot.
My 2 cents.


Here are my suggestions, somewhat fine-tuned after the meeting skype chat on Tuesday.

I would like to have two different colours for whole object selection and sub object selection. One remaining problem with this is that when a Face is selected, it is not possible to see whether any of the edges surrounding that face have also been selected. One possible solution would be to only draw the face mesh yellow and leave the edges black, but this obviously won’t work in wireframe mode and it requires the Shade Selected option to be enabled*.

As for key/mouse combos, here are my suggestions. I think they are consistent, flexible, reasonably predictable, and memorable:

  • Left click on a selected object changes nothing.
  • Left click on an unselected object deselects everything else and selects only that object.
  • Left click on any part of an object with subselections will deselect everything and select only that object.
  • Shift+Left click on a selected object changes nothing.
  • Shift+Left click on an unselected object adds that whole object to the selection set.
  • Shift+Left click on an object with subselections will add the whole object to the selection set.
  • Control+Left click on a selected object removes that object from the selection set.
  • Control+Left click on an unselected object changes nothing.
  • Control+Left click on an object with subselections will deselect the entire object.
  • Control+Shift+Left click on a selected object removes that object from the selection set.
  • Control+Shift+Left click on an unselected object adds that object to the selection set.
  • Control+Shift+Left click on an object with subselections will deselect the entire object.

  • Middle click on a selected subobject changes nothing.
  • Middle click on a selected object deselects that object and selects whatever subobject was clicked on.
  • Middle click on an unselected object deselects everything else and selects the clicked subobject.
  • Middle click on an unselected part of an object with subselections will deselect everything else and select only the clicked subobject.
  • Shift+Middle click on a selected object deselects that object and adds the clicked subobject to the selection set.
  • Shift+Middle click on an unselected object adds the clicked subobject to the selection set.
  • Control+Middle click on a selected object removes that object from the selection set, then selects all subobjects portions of the object except whatever subobject was clicked on.
  • Control+Middle click on an unselected object changes nothing.
  • Control+Middle click on any selected subobject will deselect only that subobject.

The above is consistent because:

  • Left click is always associated with whole object selection.
  • Middle click is always associated with subobject selection.
  • Shift is always associated with adding to an existing selection set.
  • Control is always associated with removal from an existing selection set.
  • Modifier-less clicks are always associated with replacing the existing selection set, with the one exception where an already selected object is clicked, which changes nothing.
  • This behaviour should work for all object types, no special incantations needed for meshes, breps, or subd objects.

I realise not everybody has a fancy mouse with a middle button. I realise this still doesn’t solve the problem of distinguishing between face, edge and vertex clicks.

Problems with this approach: We lose the popup toolbar.

*which I think should be enabled by default, heck I’d even vote to enable it and remove the option from the settings altogether.


Hi Wim,
I hope you read again and discover that I also suggested using Doubleclick :o)
Turning on control points is an old and very well established way to give access to subobjects. I think it was consistant and would not mean something semantically new to follow that route with other object types.

Hi David,
This is a nice scheme and it at first glance only introduces relatively minor changes.

Where I see potential issues is the the suggested usage of MMB and implementing it on Mac. By now every Windows CAD user has a mouse with a midde mouse button available and also Mac users who use a mouse likely have MMB – but again likely it’s the (still sold) Apple Magic Mouse, the one with that tiny pimple as MMB and all the control it gives.
Many Mac Laptop users however don’t use a mouse at all but drive everything with the trackpad. MMB isn’t even available as a default mapping for keyless Mac trackpads, one needs third party software to declare a certain finger position to be MMB. With a default Mac Laptop and using the suggested scheme one had no access to subobject selection at all.

I personally could live with losing the Popup toolbar (although it’s the only toolbar I use) – one could call it with some other key. Shade Selected turned by default is something I consider more problematic, this would probably collide with a lot of peoples display preferences.

I don’t like ANY of the solutions proposed here. But it’s very late here (westcoast travel) and I really need to thing about this from a non-expert user point of view for a couple of days. I will be back, just don’t ship V6 just yet.

All your suggestions are lovely, for geeks like us. Is that who you are going after? Or you want this to be successfully embrace by the majority of Rhino users?


My suggestion was aimed to make life as easy as possible for intermediate to expert users. We can always add a toolbar with specific commands like PickEdge, PickFace which just allows people to only use the left mouse button. But since selecting objects is a mouse heavy operation, the last thing we need to do is require people to move the mouse away from the viewport in order to start selecting in the viewport.

Who suggests that?

It’s absolutely true that my scheme won’t work for everyone, but it also doesn’t preclude a second approach using toolbars or context menus. By all means make a discoverable UI for beginners, but offer a sleek workflow to advanced users.

I think in terms of sleek and speedy mesh workflow for advanced users one should at least consider offering commands with an alternative flow – similar to the way things work in dedicated SubD apps and also quite similar to how direct editing of solids works already today, inside Rhino and other Nurbs apps. I would see extending the already existing subobject edit mode PointsOn to meshes and solids as a door for direct fire functionality + one would get rid of the Ctrl+Shift Limbo for object selection.

For those who are new to SubD-editing, a simple sample for a typical SubD command flow – one can do all this without actually talking with the program in the traditional Rhino way: What do you want to select? Which direction does the extrusion take, do faces stay together, what distance? All the commands in this short sequence are fired and refined via hotkey, decisions get communicated in direct viewport interaction. Sorry for the busy image, but run once gifs seem not supported…

Thanks for your input so far. Really great ideas and help brainstorming this.

I’d drink from the second cup if I could. But let’s also not underestimate our community (:
Now I’m very curious to hear your input.

David, I like the MMB approach with the exception that MMB is already used for panning and this precludes window-selecting groups of subobjects with it. What would you do in that case (at best, something that keeps this paradigm going)?

Holger, I think that the F10 approach makes sense for control editing. Control editing will exist also for SubD objects and that key will most likely be used for that. We are doing a SubD implementation that behaves pretty much like NURBS in respect to precise evaluation of final position and possibility of editing control points. These keyboard shortcuts in edit mode are a powerful ideas. But we cannot really substitute an editing feature with a selection feature unless we denature Rhino completely. Would you repeat all these options (say, Extrude, Inner Offset) both inside F10 mode and in normal Rhino commands?

Here you go with a bugtracking item.

1 Like

I’m afraid that I failed communicating my ideas properly. Following my idea F10 or preferaby doubleclick would sends objects of any kind in direct/subobject edit mode: Meshes make Faces, Edges and Vertices available, on boxy Solids one many push and pull Faces and Edges and possibly corner Vertices, Curves show us their Control Points.

As soon PointsOn is active one could use all Rhino selection methods on meshes, preselection highlighting took care of the filtering. One no longer needed Ctrl+Shift as now the default mode is Subobjects.
Solids, meshes and curves could be in Edit Mode at the same time, all with their respective set of direct manipulation options. Any other classic Surfacing operation but also Booleans with meshes as input would take place outside of Edit Mode.

I can not see how a separate F10 Controlpoint-Editing mode for meshes made any sense, conceptually. Essentially all mesh subobjects have exactly the same sculptable quality, Edges and Faces are just a few more Vertices moved at once.

I lost you here.

No, these were only available for meshes and only in Edit Mode.
None of the typical Mesh commands are applicable for Surfacing anyway: One would not Bevel, Bridge or create Inner Offsets – as these operations make no sense on Nurbs topology.

[quote=“piac, post:14, topic:20544”]
We are doing a SubD implementation that behaves pretty much like NURBS in respect to precise evaluation of final position [/quote]
So your SubD meshes won’t shrink when applying one more SubD level?

It is? Middle mouse click+drag does nothing on my Rhino6. I haven’t got a popup toolbar or mmb command set up so the MMB is just dead weight for me.

Meshes are approximations of the true SubD shape, just like they are approximations of the true NURBS shape. We do not rely on mesh subdivision to reach the SubD shape, every mesh vertex is coincident with the actual subd limit surface, regardless of the amount of subdivisions.

Hmm. So what will happen upon subdividing a box?
Do corner vertices move away from their original position and gradually transfer the whole thing to a sphere or do they stay where the user had put them originally?

I think I see what you mean now. You’re saying that plans are to stick the principle which is already exposed? Conversion from mesh to SubD either spits out a exact and smooth limit surface (without subdivision levels), or a mesh aproximation with (display only) mesh based subdivision.
In typical SubD apps one works on the subdivided mesh approximation directly (and here no vertex stays in place when cycling through SubD levels). It’s still a very useful implementation and the way I personally would like to deal with SubD in Rhino – is this planned?

I use mmb every 3 sec to toggle different view mode. So Pop up menu has to remain. Typing is not a good option for subD modeling, too slow. Using macro command is not convenient in this case. I wonder why so many clicks and keyboard press to make this happen? The most inconvenient part for both beginners and advanced users is too many clickings and pressings. I guess rhino got enough. Completely knowing how to use gumbal took me a while.

Tab key hasn’t mentioned, which can toggle among different selection mode. Btw…