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

[gustojunk (Gustavo Fontana)]

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…

@piac

– History

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.

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.

@piac

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(?)

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.

@piac

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.

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?

@piac

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.

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?

@piac

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:

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

@piac

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.

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.

G

[piac (Giulio Piacentino)]

@gustojunk

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)4. drag it.

@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?

[gustojunk (Gustavo Fontana)]

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?

[hifred]

[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.

[piac (Giulio Piacentino)]

@hifred

workflow+performance killer

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

[hifred]

@piac

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.

3. 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.

4. 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.

5. 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.

6. 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.

[gustojunk (Gustavo Fontana)]

@piac

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

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

[travis_serio1]

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.

[hifred]

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

[Miguel]

Off topic @hifred, very cool model/render.

[hifred]

Thanks Miguel, everyone!

[Miguel]

@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?

M

[Michael_Meyer]

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?

Thanks

Michael
www.flexiCAD.com

[Holo]

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.