Bug: ScalePositions does not work in SubObject mode. Why Some transforms do not work in some Objects/SubOjects?

Dear McNeel V7 Shipping Committee,

After a very cumbersome and long multi step process to select a bunch (over 11 K) of mesh faces I went ahead an run the command that I needed to run: Scale Positions, and the selection is gone. It turns out ScalePositions does not let me work with mesh faces.

New Rule: All transform commands should work with all object types, of all topology types, including sub-objects that are transformable. Can you please make sure someone at McNeel goes over all the transform tools and makes sure they are working in Nurbs, Meshes, SubD, and all its subobjects?



Got that, thanks - RH-59970 Scale position - subobject supprt

NamedSelections is your friend here.


Hi @pascal, NameSelections is not my friend, yet. It will have to work a lot better to reach that point in our relationship. It actually has so many problems that I’m just going to ignore it for now.

SelPrevious seems to be a good sidekick for now.



Hi Gustavo - what would it have to do, to be allowed to share your working life? Not select as soon as you touch it? Not rename the set to the command you type right after calling up the selection? (Fixed! as of this morning) Those two are hard for me but we’re still friends…

I see, you have been teaching it some basic manners. Ok, let me have a beer with it Tomorrow night and I’ll report back.


Being able to overwrite named selection would be really good. Right now if I want to add to one, I can’t. I can’t even save something with the same name and have that cause an overwrite. It causes two named selections with the same name.

Also, it needs the arrows for moving items up and down, like the layers window has.

I’m very glad to hear about those things you fixed though. They were driving me nuts. I figured out how to deal with them, but I’m glad they’re gone.

1 Like

Hi Max -
I’ve added your comments to the open item RH-55091.


@Max3 Why not make the save and delete the original? I’m not sure how adding the complexity of an Overwrite is more proficient here? Select > Save New > Delete whatever you no longer want?

For example, almost every time I am saving a named view, it is to the same name it already has, in order to overwrite. To the point I wish there was an overwrite button, so I wouldn’t have to confirm the overwrite.

1 Like

@Trav, that makes absolutely no sense. We as users should be able to override any saved/named attribute, element, file.

We override a .3dm file, we override a named Cplane, we overwrite a named view, we overwrite a snapshot, we overwrite… I can keep going forever.

Please help us driving Rhino towards consistency and user-centric work, always.

Not adding ability to overwrite anything here is total chaos. Not acceptable.


Well said JD,

I wish McNeel could have an internship program for their developers where 1 week a quarter they come to a client’s team (remote for now, office-based in the future) and they join the workload of the week and take part of what is like to work in a production environment.

I volunteer our company to be a pilot for this. Any McNeel developer is welcome to join for a week, a month, a summer. Even follow along a project or two remotely, in its entirety (typical design project is 2-4 months, full product development Is 6-18 months) via our online project management tool. So the can experience themselves what is like using Rhino in the real world.

@Trav, want to apply as our first intern? :slight_smile:


I appreciate your dramatic flare and emotion on the subject, but this didnt seem like the end of the world. Saving is fast and simple. I can certainly add whatever the group consensus is. And hey, I am happy to share my model collection with ya any time :wink:

@jdhill my comment is about Named Selections, not named views.

I am aware of that.

So you want a button that provides 0 prompt to replace data?

Yep. I’d follow the named views workflow, and add an explicit overwrite (probably called “update” not overwrite) button to both. If you are concerned about performing a destructive action without confirmation, undo/redo would probably be the usual solution for that.

@jdhill there has to be prompt or some warning. While undo/redo certainly works if you catch it right away the undo stack could be gone later so that’s not a dependable way out to rely on. I’ve had a Merge option in mind as well as an Update Selection. So it sounds your request will fit in with that. I likely will prompt to Update though.

I would not use the Rhino undo stack, it would be local to each item … “oops, I didn’t mean to update that item”. I am assuming the data is not very complex. But whatever, you get the point.

Sure, we just have to make sure we’re setting it up for users at all levels. You get it.