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?
4 Likes
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:
- textdots
- textobjects
- blocks
- details
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
1 Like
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.
- 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.
4 Likes
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
2 Likes
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:
- click on an object
- activate sub-object mode (ctrl-shift)
- select the face I want
- drag it.
when I can place the cursor on the face that I want to drag and simply:
- click on the object’s face (that activates sub-object mode + selects the face I want)
- 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.
G
3 Likes
@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?