Basic polygon selection is painful, slow, unreliable. Example attached


The only way that I’m aware I can select individual polygons on a mesh is using SubObject selection. Is this correct?

If so, that means I have to constantly be using two fingers pressing shift + CTRL simple to select my work? (do you know how many hours a week a SubD modeler spends just selecting? (if you don’t, you should measure it, it will be humbling and eye-opening)

Please take a look a what I’m used to:

and now watch me try and fail miserably doing the same in Rhino:

This is just unworkable for me. Am I the only one who finds these tools limiting and terribly frustrating?

Here’s the file, with the example I select-wrote in Modo next to it and colored for reference:

easy_select_test_gf_190802.3dm (2.9 MB)

Thanks for listening,



You can use the SelBrush command

1 Like

@all, in V6, having the Sub-Objects filter enabled, _SelBrush using _Polyline=No comes really close. But i see no way to unselect using _SelBrush ? Am i missing something ?


What’s important to note from my Modo video:

Selection/Deselection all takes place by simply activating polygon mode:

  1. I can click-click-click
  2. I can click-hold and drag my mouse around (basically making a selection bush)
  3. I can mouse I’ve without clicking or without click-holding and I can see a highlight of which polygon will select if I click/shift-click.
  4. I can unselect the same way. Going back and forth betting adding/substracting from my selection
  5. I never see an ugly fake brush
  6. I can also (not in the video) marquee-select a bunch of visible polygons.
  7. I can also (not in the video) marquee-select with middle mouse a bunch of visible + backfacing polygons.

So no, SelBrush does not come even close to a useful tool, not a fast one, not a good experience.

Imagine if when you select a single object Rhino (regular click to select) it first places a giant ugly dot before it selects your object? That’s what SelBrush is doing. It makes no sense por polygon modeling. The selection tools should be based on what’s right, rather optimal. Not on what’s already there.


1 Like

Yes, here I reported watching the first movie about selections

And here is @BrianJ responding​:point_down::point_down::point_down::point_down::point_down:

…I’ve been thinking about this over the weekend (Damn you McNeel, here we are again! I’m in Spain, supposedly just enjoying nature and good food and relaxing by the pool… but I can’t, I need a better SubD now!)

Anyway, I get it that it’s really really hard to put into words, specs, examples what’s the underlying problem with what I see being developed right now and I think the best way to describe it is: everything feels rigid. And not flowing.

The example of me just hovering over a grid of polys and effortlessly painting/unpainting/visually mousing-over to highlight and check alignment… all that is what makes a workflow intuitive, natural, flowing, delightful.

It’s an extremely qualitative and experiential quality what I’m talking about. Other examples of these contrasts of rigid vs. flowing:

  • Typing on an iPhone keyboard vs. a low end Android*. You can type in both, but if you try them side by side you will experience an astonishing difference.

  • Navigating and reordering renaming layers in Rhino vs. any other CAD program (this proves to me you to get this, and you can do it right).

  • Riding a modern BWM motorcycle vs an old Kawasaki.

  • Cutting tomato slices with the right serrated knife, vs a smooth blade one (no matter how good and how sharp).

  • Noving sliders in a lightweight/efficient GH definition vs. a bloated one.

  • Navigating a heavy model in a viewport with a powerful Quadro card vs a low-end one (or Intel Graphics for that matter)

I’ll leave you with this example or ‘flow’ posted yesterday by your own @DanielPiker:

Also I’ll leave you a link to this book about the Apple Keyboard development:

If you work are McNeel and are interested in reading/listening to it, send me a private message with your email/shipping address and I’ll send you a copy in your format of choice.

I know you have a lot of internal pressure to replicate T-splines functionality ASAP, but as a designer and early tester, user and now employer of one of the best TSplines modelers in the world I can tell you: the quality bar of T-splines was extremely low, and that’s the reason I never adopted it except as a necessary/undesirable solution. The limited market success of TSplines as a product might have many reasons to be, but the fact that when designers like me tried it and ‘it felt like shit’ (I don’t mean to be offensive, just unequivocally clear) didn’t help.

I’m saying all this because what I see is not based on the limited features and tools developed to date, that’s totally understandable. My feedback is based on ‘how shitty’ what has been made feels already. And I’m afraid that’s influenced by the underlying architecture/foundation that you have put in place for this workflow. And from my point of view this si just not good enough, not even close.

I know I’ve been your long-term toughest customer, and sometimes overly alarmist. And hopefully I’m overreacting and this will be as nice and smooth as some other tools you have created. But based on what I see so far I see this is going in the direction of your rendering and materials look and feel. And that’s all I have to say as a cautionary tell.

I love you all McNeel folks and my feedback is just trying to help. Before is too late.



1 Like

[Ops, fixed spelling error: cure -> core]

I think anyone can read books on UX and still miss the point(s). In some, and perhaps rare, cases “theoretical knowledge” simply isn’t enough, it takes passion (for the problem domain) to stretch oneself so far as to make a user experience what it really should be.

How much effort, and resources, are put into “ergonomic” tools and office equipment, from monitors to crazy looking chairs and stuff, and people still being disrupted and worn out by what you call rigid workflows.

I understand, though, that “workflows” can be quite different depending on what type of design you are dealing with, but basic generic stuff (almost) always applies, like the things you mention, everything from highlighting preview-selections on mouse-over, zero hassle one-click selection/unselect etc, etc.

I’ve said it before (but I’m no longer on flames about it) that developers with focus on logical problems (core functionality) can’t be expected to be passionate about perfecting UX. Period. It’s just a fact out there.

Solution: Hire UX experts and work with them as “internal consultants” as part of the development cycle. Basic level UX (as opposed to very specialized commands and tricks) really is a “first class citizen” which isn’t always possible to fix “later when we have the time”.

In architecture, automotive, and in many other fields, UX is an essential part of the core product / product design. In software which is used many many hours a day (as opposed to many other products where UX is given more focus) UX is more important than in most other cases. Really.

R6 is what it is. But 7 is a holy number and… ah, never mind. :grinning:

// Rolf


Thanks for the feedback Gustavo etc. Here’s a quick video of how I’d do this now in the v7 WIP. I believe the underlying abilities are there but not obvious enough yet for users to find. Perhaps icons that enable filter and selbrush settings would help. Thoughts?


Looks very good. And the idea to “bundle” filters to support typical operations (and giving them icons) is all in the right direction. Good approach.

A useful option would be to activate “toggle” selection which would deselect any items being brushed if they are already selected. I think there’s need for two different modes because one or the other isn’t always optimal, depending on what is being selected (and depending on user preferences).

But this seems like a very good start! Users with very demanding use-cases may have other thoughts.

// Rolf

I’ve filed to see if @mikko can help here.


Why not click Sub objects on the selection filter list and hiding the gumball will help a lot in R6.

Hi Brian, It´s good to see you have a ´developer mode´can be a bit more useful. Before I spend any more time into documenting everything that´s pure friction about this approach, even after I do all the clickety’clack to get to the point that I can paint, with a brush, that´s not really a brush, and once the unknown units of arbitrary number for brush size is chosen is selected, assuming you can make user-friendly tools for this, I have to ask 2 questions:

  1. Have you tried to also do this is Modo?

  2. Once you do, you experience anything different in terms of:
    2A. Intuitiveness?
    2B. Head-up of what will be selected by pre-highlighting?
    2C. Ease to align rows of selecting by using this highlight as a ‘smart-tracking’?
    2D. speed to add/remove?
    2E. Consistency of selection accuracy ad various zoom levels?
    2F. Ability to combine drag (paint) AND click as equally valid input modes?



1 Like

I forgot to show in the video that you can hold Shift and move your cursor to interactively change the brush size.

No, I know Blender which has selection modes and brush selection for comparison but I never got into Modo.

I agree that a faster smoother workflow for entering selection filters and also brush selection would help. The goal is not to copy any application’s tools specifically but rather enhance what Rhino already has to try and provide what’s needed. I know this isn’t what you want exactly. If specific and targeted requests for feature changes are filed, they have the best chance of being worked on by development. If you have specific issues with SelBrush after trying the current v7 WIP version, please let me know and I’ll make sure they’re on the pile. Thanks!


Excellent addition…Thanks @BrianJ

I hope that is what you understood from my video, follow up comments and my specific questions about good, deliberate UX decisions. Otherwise I think this situation is a much more difficult uphill battle than what I had thought.


What if all the reasonable approaches are already scattered between different pieces of software and there is nothing original left for Rhino? If there are some things in Rhino that are mediocre quality at their cores, will glass ceiling for them is being “mediocre +”?

No need for a battle, just specifics about what works and doesn’t. In this case, I filed what I could distill down into a request that hopefully makes sense to developers. If there’s more you’d like on selbrush, just explain. If it’s not directly connected to selection filters, maybe make a new post.

I don’t control all the decisions about what can or will change in Rhino but I can make a case for any updates/changes/features that will solve a problem. The best way to be heard is to be specific about a request and to keep it simple. If your overall hope is the combination of 10 different changes, take the most central to the list and explain just that first. In my experience this can get more attention and possible action.

Let me know if I can help communicate what’s needed to development, keep in mind I’m an artist and teacher not a developer so I won’t be able to code it up myself for you :slight_smile:

1 Like

What you describe here is what you should be describing to your coworkers, not your customers.

I know that you guys make a very powerful and stable software, and that your focus to customer support and passion for your work is superb. But I also shake my head when I see some of the things you have been shipping in the last decade and how badly thought-out they are, and also how limited and poorly tested and executed they are.

You know how many times I’m working on something, my own client project, and I encounter a Rhino situation that I have to stop and think: “what did just happen? WTF!!! I can’t believe these guys shipped this feature like this” … and off I go again, and I have to stop doing my work, to do yours.

This is all a reflection of a culture that expects us to do all the work, and we have our own jobs, and we only spend time showing stuff where things get frustrating af. So of course the resulting threshold of performance and UX quality of your tools is ‘barely above frustrating af’; powered by your open-source bitchin’ n’ moanin’ process.

You all can do better. You all should do better.



I think this sentence could regard more of the reality extending beyond only one problem domain (you are an expert within your own problem domain). By having many domain experts (of which you are one) McNeel can potentially make a better software which solves problems in several problem domains (or “workflows” to be less abstract).

But most important - a tool maker is not always the domain expert!

I think I have sen you say that you are not a software developer. And nothing wrong with that. But here lays a big problem, namely to design and produce the perfect race car intended to win races out there, without being a race car driver yourself (which is the most common case, developers are typically NOT the domain experts for the use cases of the software they make, which btw is why I have suggested that developers consult UX experts for that part of their jobs).

I’ve myself been in the position to design and implement a very complex business system covering a “problem domain” which I had no (zero) experience of when I started up the project as the chief architect. And without a super-good communication with the domain experts in the field the project would have failed miserably (and some say that about 50% of systems with the size I designed typically fail).

But a software like Rhino is technically speaking more complex than most business systems, and still the statistics about the success rate of business systems (which typically has it’s complexity centered around concepts rather than complex technology) is terribly low. Terribly low.

From all this I can conclude that statements like “can do better” and “should do better” are statements with little or no general meaning. The technology stacks we use today is a complete disaster compared to what it SHOULD be if the so called advancement in technology would have kept up with the advancements in other fields of tech.

We landed on the moon when I was a little boy, and more or less all the basic concepts that we use today in software development were already invented in those days. But since then we have only made it so much more complicated to develop even the simplest functionality in software applications or system with ever increasing complexity. Exponentially increasing complexity.

For this reason I think you should be critical, not of the developers drowning in the ongoing havoc, and instead direct your frustration at the madness of the IT-industry in general of the last decades which went down this route of making even the simplest things incredibly hard.

Nevertheless, the need for a useful UX remains, but as I said in an earlier post; if a good UX wasn’t planned and designed already in a very early stage of a software, it’s not going to be easy, and sometimes not even possible, to add it later in the development process (try make major changes in your own design in later stages and you’ll know what I mean. It all too often means , “start again, from scratch”).

You being a domain expert in your field is the only possible way for a company of McNeel’s size to get the right input, in an early stage (meaning, lotsa bugs) and…

In my opinion McNeel developers are doing incredible work given their preconditions. And I think they listen carefully to us users. But please regard the “technical debt” madness (über-complexity) they are working in.

At last: Lots of sharp minds are currently trying to find way to get out of this mess. And what is needed is a paradigm shift. But McNeel isn’t into that part of the IT industry which caused the mess, instead they also use development tools made by others, in their work to make (CAD) tools for us.

IT-technology is in a state of mess. Let’s not make it harder with unrealistic expectations.

// Rolf

[edit: spelling etc]