All 3 of the Ctrl-Shift-Left click on … options exactly duplicate other left click options above them, so they could continue to be used for sub-object selection as they are now.
I would very much not like losing the recent-commands popup menu on middle button.
Could the enhanced middle mouse button be exposed similar to how delayed context menus work for the right mouse button? If so, it would seem to me that the David’s middle mouse suggestions would get a middle mouse click, and the existing middle mouse button functionality (most recent commands, popup toolbar, macro) would get the delay, and press and hold could cover those who have enabled manipulate view on the middle mouse button.
Maybe use a key to call out a menu similar to
_popupmenu command in Rhino.
So the workflow is press a key and Rhino screen pops up a list of menu to select different object type (face, edge, vertex) and use gumbal do the editing job like subdividing surface, extrude and move. In this way, very straight forward.
you can try to pry my pop up bar from my cold dead fingers… 
seriously…can’t lose the pop up unless a better solution for a quick menu can be proposed as well…it’s literally the single biggest speed advantage I have when using rhino-
@Willem, good news (: subobjects selection works in group. This is true in Rhino WIP.
I think many many people pan by dragging with the MMB in perspective views, thus preventing window-selection, if MMB is the main subobject selection tool. This keeps on being the biggest concern I would have. I like this otherwise (Mac and trackpad concerns notwithstanding).
This is a fresh idea. I kind of like it (: Let’s just see how this would evolve if we elaborate it. It would still be some sort of option 3), with selction “modes” (objects, faces, vertices, etc) that switch?
This would then enter a “mode” similar to the one in 3), right?
I think we should listen to this strict sense of need. Maybe not enough, but could @anon66739973’s solution just above help for this? Using a key.
I was hoping we could free some modifier key for some other usage by removing that redundancy.
Yes, that’s what I meant with highlights on object type.
Yes, same concept. Either keep pressing TAB to switch option or using mouse to select.
I think this is a very good point. If it happens, a part of this would be for historic reasons. However, maybe we could visualize control points and points on the final surface in these two different situations. Especially selection-wise, it would make sense to select on the final surface, and “control points” would be the level 0 (control net) ones.
I just mean that a command requires subobjects, then do we require the user to push F10? Or we change mode everywhere? Or what if the user wants a normal curve and a brep edge?
In general, I think this solution could work if we manage to bring it back as much as possible to the way Rhino works already today.
There are some well established conventions for sub-d stuff that I would personally like to see retained. Living through the tsplines development process, there was a decision made to mimic both maya and modo style selection conventions for sub-d objects so that users that are flowing onto or out of tsplines would feel immediately at home. This led them to the a-s-d-f keys for point, edge, face or object selection and works, in my opinion very well. The issue here is how to enter or exit sub-d mode, something which tsplines always struggled with. (ctrl+spacebar turned it on or off) yet there was always this awkward overlap between what was tsplines and what was rhino, especially for hotkeys.
I for one, do like the idea of a “sub-d” mode that could be activated via hot key toggle, (say s then d+enter (or right mouse enter)… it’s quick, close and not hard on finger tendons to run) this then “activates” the sub-d object (maybe it’s outer border highlights to show it’s active) and allows you to then use the a,s,d,f modifiers and gumball to operate
a quick tap of the esc key and you are back to “normal”
this to me sounds like a very quick, efficient way to use a very cool modeling style.
thoughts?
Demo:
note: existing _popupmenu command already worked like this. After click an option, it automatically exits. In this case maybe SUB-D mode.
@piac
http://screencast.com/t/UeuIfK6K
Ctrl+space may only good for one language speaker. Ctrl+Space is the default option for toggling different language option for typing. (Although it can be changed in windows setting) Ctrl+Space is a good combo though. I thought about this option, but I concerned about those people who are multilingual.
BTW, Tsplines is nightmare to me. I quit a while ago although I installed it. haha
[quote=“piac, post:27, topic:20544”]
If it happens, a part of this would be for historic reasons. However, maybe we could visualize control points and points on the final surface in these two different situations. Especially selection-wise, it would make sense to select on the final surface, and “control points” would be the level 0 (control net) ones.[/quote]
Well, I personally would never want to show the control polygon but always work on final surface/subdivided mesh approximation directly. It has become super uncommon to model with the control cage shown, it just gets in the way, feels more indirect and occludes the view.
[quote=“piac, post:27, topic:20544”]
I just mean that a command requires subobjects, then do we require the user to push F10? [/quote]
The alternative proposal I made was doubleclick. It’s free on all applicable objects, Blocks were no valid input anyway but also here (on Blocks) doubleclick means “drill down”. But Tab would probably be fine as well, that’s the one Blender uses.
[quote=“piac, post:27, topic:20544”]
Or we change mode everywhere? Or what if the user wants a normal curve and a brep edge?[/quote]
My idea was to change the behavior of just the object in question, pretty much the way one can have surfaces with controlpoints on and such which have them off, side by side in a file.
[quote=“piac, post:27, topic:20544”]
In general, I think this solution could work if we manage to bring it back as much as possible to the way Rhino works already today.[/quote]
This is an obvious desire, but I am not sure if it workflow wise made most of sense for this new modelling paradigm. The least one can say that there’s no Subd package out there which only works remotely in the question/answer sense of classic CAD á la Rhino, Autocad etc.
A large part of my scepticism whether native SubD in Rhino makes sense (you remember) has to do with not being able to imagine to edit meshes using the classic Rhino command flow. Most SubD commands are semantically far closer to sculpting Nurbs control points: Not constructing but fiddling. > See also Kyles comments.
This is a very strong candidate to investigate. The way double click currently works on Details is another example where it represents “drill down”.
From the top of my hat it already operates on:
The semantics of a double click as opening or activating are widespread and it still has no major significance in the Rhino GUI. Double clicking has been discussed on previous occasions as a means to enter an objects edit mode. I found a recent general wish:
http://mcneel.myjetbrains.com/youtrack/issue/RH-29771
I’m not familiar with sudD modeling so I can only make assumptions (correct me if I’m wrong)
A subD mode should not be exclusive like the current block edit mode.
In other words an activated subD object should be present and editable alongside other geometry. The analogy is that of curves/surfaces that are editable because their controlpoints are on.
Could a double click on the object be activating that mode and a double click anywhere on the object de-activate it? Specifically on the object to prevent a global switch de-activating all other active subD’s
I assume it is wise to investigate how T-Splines and other subD type software handles the editing as they are based on convention and are likely matured. It will make the switch for users coming from other subD software easier and present new users with a seasoned UI.
As this is a radically new introduction into Rhino it think it not wise to try and cram the UI into existing paradigms as they will probably only make things worse. It needs to be an addition to the existing UI paradigm and as such even open up options to overflow into currently troublesome UI issues.
-Willem
I have to agree with Kyle @theoutside on this. The a-s-d-f keys for point, edge,face, object selection will be familiar to many subD people, and it works beautifully.
I also agree that a ‘sub-d’ mode toggle is a good idea, especially if there is a clear indication that we are in subD mode. Mind you, I shoot myself in the foot often in T-Splines by using a Rhino hotkey when in T-Splines mode, even though it displays a nice heads up display when T-Splines is active.
As for the Middle Mouse Button. I’m a long time Wacom tablet user and I would be very very very grateful if you could resist the temptation to include any functionality that mandates the use of MMB or scroll wheel.
Very exciting, keep up the good work, Steve
[quote=“Willem, post:31, topic:20544”]
I assume it is wise to investigate how T-Splines and other subD type software handles the editing as they are based on convention and are likely matured. It will make the switch for users coming from other subD software easier and present new users with a seasoned UI. [/quote]
Yup, this sure made a lot of sense. Tsplines had exactly the same idea before their first release: “We’ll hook up everything just the way it works in Rhino, everybody will imediately feel at home then.” Unfortunatelly things turned out cumbersome and slow for anyone and also unfamiliar for users with existing SubD experience. After getting lots of complaints by customers, one pretty soon changed strategy and established TsEditMode which allows for action sequences and keyboard bindings not doable in vanilla Rhino. Everyone who contributed to this thead and stated that it was great to pick up some well established SubD Editing conventions or wished for pressing keys (such as ASDF) for change between subobject types essentially asked for nothing else but SubD Editing being hooked up in ways not in line with how Rhino works today.
There sure were solutions, if one looked into this, pretty much the way F11 allows us to turn off points selectively for clicked elements in a collection of Surfaces and Curves showing their Controlpoints. Such could be Modifier + Doubleclick (such as Ctrl+DC to remove one of several objects from PointsOn state). If one put even more focus on discoverability one could even display an unobtusive, clickable widget near the live-edited object to turn PointsOff. Both methods were no efficient way turn off points for dozens or hundreds of elements at once, but having that many objects showing points made no sense in the first place.
T-splines has its own mode because it’s a plug-in. Rhinoceros shouldn’t work like that. Feel like Rhino, work like Rhino should be the right direction in my opinion.
Rhinoceros uses macro command, any command can be replaced by a single key. You can not predict how many people have already replaced universal sub-D keys in other way. I personally don’t mind using QWER, how about others? I’ve been using TFD(Top/Front/Delete) since first time I knew how to set up macros.Can you imagine how many people could suffer from this?
T-splines sub-D keys shouldn’t apply to Rhinoceros. You have to think about those people who use T-splines. What if hot keys interfere? Do you give up Rhino or T-splines? QWER is awesome, but in this case it will create problems. One of many reasons that I don’t like T-splines, simply because it interferes with Rhino Gunball.
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.
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.
Thanks
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.
Giulio