Interaction suggestions for SubD-Editing

Rhino SubD
1


Hi All,
I have a hard time to imagine editing Subdivision surfaces as shown above, that’s why I thought one should bring up this topic early in the process. The reason is quite simple: I know for sure that one can take care of all of these parameters inside SubD apps, without a lot of GUI and modal queries and in a fraction of the time one needs to read and understand the above text. For me it clearly is one of the most attractive attributes in mesh modelling that one as a user may keep on going forward at all time.
Maybe the initial outcome of a certain operation is not yet what one originally meant to do… but that realistically also happens all the time in Surfacing too. In contrast to polysurface editing however, the whole volume remains fully editable at all time. That’s actually a huge difference! It therefore is perfectly in order to approach a Subd shape iteratively and to give the nurby control freak who’s keen on exact numbers and angles a break – at least for early concept development, where SubD shines.

The last paragraph however wasn’t meant to say that one should leave control away, not at all. The following is an unordered mix of own suggestions and principles found inside applications other than Rhino. I think some of them were worth looking into in order to make modelling with meshes inside Rhino as playful, dynamic and full of happy accidents as it can be. It’s about command flow / commandline options, custom UI widgets, Keyboard bindings and further stuff of that nature. My idea is not that you guys cram all of this into Rhino (chances were meager anyway) some of these options also overlap or even kinda contradict each other – it’s essentially just a big bag of ideas.

As it would have taken a lot of additional time I leave away most illustrations for now. If something isn’t clear let me know and I’ll record a gif. One might notice that Buttons and Toolbars don’t apeary anywhere, simply as I rarely use them in any program.

1 Like
2

Suggestions on command-sequence/command-line options:

Direct Action(sticky option for applicable SubD commands) Established elections or hovered over (and by that highlighted) element are assumed to be the completed selection. Pressing Enter to accept selections isn’t necessary.
Direct Action consequently should work also for Sub-option inside running commands , possible even via user defined hotkey. Rhino currently only offers hardcoded assignments, one needs to press Enter all choices to register. The last choice for the command should be sticky. Reason: Post-picking is uncommon for a variety of SubD modelling tasks, asking for elements to select therefore is not required.

Not only in this context a faster in situ assignment of hotkeys was very helpful. A slim method used in various programs is to let users press an awkward key, such as the Insert Key while at the same time pressing a toolbar button, Menu-Entry or (in Rhino's case) clickable Commandline entry. One gets brief non modal feedback on successful assignment. Rhino 6 should generally be able to display changed default hotkeys correctly, anywhere in the program.

Cycle through options of commands.
When freely playing around with shapes often times one can not predict what option was appropriate or yields the most interesting effect. In such cases was great to have a common way to cycle through live previews of all available options. Cycle condenses several options into just one hotkey, this works well on anything with up to say 6 different entries and mesh operations typically need needs zero time to generate a preview. Such may make sense for both people bad in memorizing hotkeys and those who use them extensively and have just a few options left on their keyboard for new assignments. Examples where Cycling of options may be nice: Orientation of Manipulator + Cplane, Object Shading active subobject selection mode.

Suppression of irrelevant keypresses until end of command or Escape is hit. Keeps the promt tidy. A few important words, written in a quick sequence, such as e s c a p e should probably register.

3

Keyboard and Input device (Mouse) options:

Context sensitive hotkeys
It should be possible to call different operations, depending on preselected entity type.While Rhino traditionally would offer separate commands such as: extrude mesh vertices, extrude mesh edge(s) and extrude mesh face(s) it was great if one only needed one Extrude command, which depending one the selection spits out just the applicable options for the selected subpobject type.

Combined selections of say edges and faces are typically not allowed in SubD apps and I see no reason why Rhino should handle this matter differently.

Sticky Keys of sorts… (making a difference between tapping a key or keeping it held down) Inside programs which aren’t set up to receive text based input at all time, filtering between key only hit once and key held down is of course quite easy. But also in Rhino a non Modifier key held down could after just a few microseconds register as different input from normal typing / Aliases. Having to keep keys held down to access certain functions is widely used, not just in SubD modelling. Classic sticky key behavior would be the program would return to the previously used workmode, after letting go the key held down.
Anyone who has access to Photoshop can quickly try out how this works by using say the Brush Tool (press and release B) and then pressing and holding W for the magic wand. Letting go of W switches back to the brush.

Making currently non assignable Hotkeys available
These are all Shift+Key, Alt+Shift+Key, Ctrl+Shift+Alt+Key combos. One might also offer a Checkbox to override the traditional Windows Alt-Key+Letter driven Menu control so that Alt may get asigned as a proper standalone Modifier – I have not seen a single SubD app not doing this.

Calling of alternative command sub-options depending on the Mouse-Button which performs a drag action on custom viewport widgets (see further down) Options: Hover, LMB, MMB, RMB, the same + Modifiers.

Broader use of the Scollwheel + using it together with Modifiers or normal keys. Currently the scrollwheel is merely used for Zooming, which is a waste. Possibly in conjunction with modifiers one could use the wheel to interactively control areas of influence/falloff for stuff like soft selection, or interactively setting the number of edge loops to insert in all commands which allow doing so (Extrude, Inset, Insert Loop, Bevel, Bridge etc.), for setting the degree/count of smoothing iterations, for cycling through options and many more things.

4

stuff happening inside the viewport:

Hovered Object working like Hotspots:
This way one could establish object specific behaviours on multi object scenes.
A not directly Rhino related example should explain the underlying concept: Digital painting and sculpting applications typically expect Pen-driven input, LMB here is executed by touching the Screen/Tablet. As touching and dragging
around is the most obvious thing to do with such a device the LMB action is mapped to do two very different but both very important things. Outside objects touching the screen with the pen (LMB) tumbles the camera, when touching the screen on top of objects one may paint and deform. While these functions are fundamentally different, usage is immediatly second nature.

Possible usage inside Rhino:
I see that the general vibe is not is not to introduce an Edit Mode for SubD. Generally speaking though comparable filtering inside Rhino could be used to allow for features such as Preselection Highlighting and Paint Selection on Hover for objects in Edit mode an conventional behavior on objects outside of Edit Mode.

Custom GUI widgets for SubD commands:
Last but not least… Most SubD programs give indication of the currently active command with a subtle custom cursor or dragable widgets which depending on the purpose stay in place while dragging or not. Letting go LMB /stopping the LMB drag action finalizes the command execution, just the way Gumball now lets us transform stuff without having to go
though modal queries. That way one could execute a complex command and possibly try out various sub-options interactively while the commandline just protocols what happened. Those who prefer using buttons + the promt, could still do so. A nice feature in some programs: Briefly hitting RMB while still dragging the widget with LMB with LMB cancels the current drag action but keeps the command active and the selection intact so that one can try anew immediately (interestingly Gumball works that way too, not sure if that’s intentional though…).
Additional widgets should imo not get bound to the vanilla Transform widget, as currently the case with Gumballs Extrude handles (sorry if I sound like a broken record here).