Named positions matching?

I’m getting a hang on named positions and it’s quite useful once you can get passed the crazy/criptic UI :slight_smile:

but there’s one thing that I still do not understand. if I add details to an object that has already been moved and rotated into various saved named positions, how do you make the new stuff follow that object?

Example: I made this basic USB connector object, applied a but of positions to it (along with the rest of the model parts). That all works well. But now I want to add a bit of detail (like those blue contacts below), but once I make another name position active, the connector will move to a new position, but the blue contacts do not follow it. If I boolean union, then the USB connector looses all its named positions. How can I solve this? Is there a Name Positions Match command somewhere? …where I can tell new objects to follow the named positions of an existing object that already has them?

@andy, is this something you are in charge of?



one more question on Named Positions:

if I copy-paste an object so I can use it to snap and manually _Orient3pt these lost in space new pieces I see that NamePositions adds new saved Name Positions as copies? see below… W

hat’s the logic on this? How is this useful?

I usually end up deleting all of the named positions after a copy, and then re-creating them. If you try to use any of the copies, stuff goes all over the place.

1 Like

That’s what I’m seeing too. I question this should be the default behavior. I’m copying geometry, from a given position and paste in into the same position, but not into a new named position. If I want name position information in the new pasted object I’ll assign it. …another reason to have a NamedPositionMatch command.

Hi Gustavo - select all the objects,(Connector plus new stuff) select the named view in the list, and Save the named view, overwriting the existing one of the same name with the currently selected objects.


I don’t think that’s it Pascal. I can always select the ol and new stuff from a given location on the viewport and tell Rhino I want that to be the new Named Position. I get that.

But the problem is the following:

I created connector.
I saved position01 for it
I moved to a different place, saved position02

Now I want to add more detail to the connector. I set it back to position01. And easy to model ortho-oriented position

I model the details and I tell those details to also have position01 saved.

How how to I get them to follow the connector to position02 (out in crazy XYZ location and rotation)?

Makes sense?

1 Like

Yeah… got it. I do not see a good way to do that…



FWIW, I would also like to see improvements to the organization of Named Positioned objects. I frequently just delete them all and start over again.

In case this gets on some list - keep a link to this related topic:

1 Like

Yeah, me too…


Reading this topic I realize I do not use NamedPositions because of this type of issues.

I would like to use them as it’s great to have an option to have various positional states.
I remember playing with it for a while but it’s not practical for a model in development as the management of positions gets cumbersome once you need to edit the positions; add or remove objects to it.


For me this is an example of a functionality I’d welcome, but once I start to use it, only the basic functionality was there the moment things get complicated the tools are just not practical.

1 Like

I was using it last year when designing a mechanism for a folding seat. It would have been very useful to quickly try ‘What if’ situations. I was hoping that, once set up, adding objects to Position A would have duplicated them to Position B in a kind of automatic Orient3Pts. As Willem says, the practicalities of managing the details soon became apparent and I abandoned the idea. Haven’t used it since - went with Blocks and layer state manager instead

@gustojunk maybe I have find a solution that could fit for you…just combining groups with named positions:

1.Create a named position of all the elements in the initial location
2. Start to create group of element that you want to move and stay all of them “together” in the same location
3. Move the group. When u have moved it, u can realise if you have left geometry without adding to the group, the select addtogroup command and add those geometry (doesn´t matter that they are on different locations actually)
4. Finally, reset the named positions to the original state…then if you move again your group it would have added the geometry that u have left and u could move all of them together

I know that it is not the best solution, but for me was useful. Revit has a very similar feature with “exploded geometry”, u can add more geometry to the location where u have moved the elements

That’s Javier, this is a bit hacky, but a great workaround for now. I’ll use it next time I have to setup moving stuff. Thanks for sharing!

@pascal Is a NamedPositionMatch command on the wish list? I run in this situation today too and missed it. Named positions are coordinates only and it would be great to assign the relative movement from one object to an other.

@gustojunk There is a workflow to have a flexible named positions, but it doesn’t work for match exist named position states. If you plan to use named positions for changing assemblies than it helps to work with blocks. So, if your connector would be within a block than you could add details or exchange the geometry and keep the named positions because the named position is saved for the block.

Hi Micha - I am not sure what you mean here - can you show me an example?


I don’t know how the named position works today but I think that it would be possible to track the transformation matrix from the initial state and the final and then being able to apply it to any of the object like Micha is asking.

And I agree with Wim, it sound as a great tool but it’s irritating if you try to use it in a productive environment.
Would be perfect for exploded view but I’m always creating a file copy with new position. And then doing the all process again when I change smtg.

1 Like

Thank you @skysurfer, that’s what I mean.

For example at Bongo we have the equal command _BongoMatchAnimationProperties.

Also we have the possibility to animate an object (parent) and make other object to childs of them so that they follow the parent object, the very useful command is _BongoSelectChildren. OK, maybe this is to much functionality for named position, but having no way to make new objects following the previous set movement is a big problem.

Hi @Micha, thanks for the suggestion. Since trying to figure out a workflow for this, now almost 4 years ago we have learned a few more things, and have changed a lot of our priorities:

  1. Named positions are too unreliable so we really stopped using them altogether.

  2. Snapshots: pretty much the same as above. We only use them on a destructive/disposable copy of a file. We cannot trust files with Snapshots anymore. We need to be ready for them to be wrecked or bloated to a point of becoming unusable, and no one cries, no one complains.

  3. Instead we are using blocks and updating/replacing blocks a lot more. And we change the positions of block instances and turn on-off those differently positioned blocks instead of trusting namedPosition, or snapshots. This approach is limited because if you want to make relative movements of the parts inside the blocks you now would have to deal with nested blocks: Yikes! This is where my head starts to hurt and there’s no good UI or object management for this. So block usability gets in the way of productivity.

  4. When we need to do more complex stuff we don’t even try in Rhino anymore. All geometry moves to Blender these days and we do all our work with proper instances, and groups inside empty nodes that can be updated, duplicated, etc.

I think that a lot of our pains in Rhino are because we do heavy production work (massive files, lots of design iterations, multiple animations, materials/colorways options, multiple users collaborating, etc) and such day-to-day realities for us (my business) seem like ‘edge cases’ or ‘too hard to solve’ for McNeel and probably not relevant to most Rhino users (maybe?). Therefore I think most of this could be most efficiently solved with one single improvement:

A robust, fast, responsive, intuitive, and actively and continuously supported Rhino-Blender live-link.

We now do all our front-end conceptual work with positions and ‘what-if’ options in Blender/SubD with some imported meshed Nurbs parts. Same for all the tail-end viz work, using Cycles X, Octane and realtime PBR shaders with Substance Painter.


Thank you @gustojunk for the deatailed insight in your workflow. In my situation here, a lot of data exchange with my client, based on NURBS, is needed and I want to stay in Rhino. But it’s good to know alternatives.