Michael,

I’ll describe my experience with naming and groups in v5, especially what happened before I had any understanding of groups. I was working on a model consisting of multiple objects and clicked on the name of a first object in the Objects section of the scene browser. Poof: a second object vanished from the browser. My immediate panicked reaction was that I had triggered some bug that caused part of my model to be deleted. I now understand that the first object, being selected, was simply assigned the name of the second object, but it took some experimenting to figure that out.

Why did I click the name of an object in the browser? Because that’s how I edit object names in Illustrator and Corel: double click the name to make it editable. I also make this mistake in v4, but there it’s benign because clicking an object name doesn’t do anything. Since I switch back and forth between MoI, Illustrator, and Corel multiple times a day, breaking my habit of clicking object names to rename them will be difficult. But, now I know what’s going on in MoI v5 and simply hit undo.

I think I’ll come to like clicking on a group name to add a selected item to that group. In Illustrator and Corel I often have problems dragging an item through a long list in the Layers Palette so that I can drop it on another item for the purpose of grouping. Click to group avoids that problem.

What I don’t think I’ll like is clicking on an object name to assign that name to another, selected, object. I don’t expect coming to like this because of the vanishing object problem described above.

One solution I see is to deprecate object naming as a means of grouping. I understand that this has been part of MoI for a long time, but now that you’ve come out with hierarchical groups, what is the value of name grouping? In addition to the disappearing object problem that new users like me may stumble over, it creates an inconsistency when coexisting with groups: I can give 2 groups the same name, but that doesn’t cause them to combine. I can even give 2 objects the same name, but not have them be grouped if they are at different levels in the group hierarchy:



However, if I Ungroup the 2nd "foo" the 2 objects named "sphere" get combined into a name group, which might not be what I intended:



An additional benefit of doing away with grouping objects by name involves "Unnamed". Now, every object that I make goes into the name group called Unnamed unless I take the trouble to give it a unique name. I can only easily assign it a name if the operation that created the object left the object selected. Many operations don't do that, so then I have to run a script to select the last created objects, or I have to visually find the object that I wish to rename in one of the viewports, select it, and then go over to the properties panel to rename it. Unnamed acts like a junk drawer that's not only disorganized, but locked. If a junk drawer is necessary, a group called something like "Unnamed" might be better. Or, newly created objects could just be thrown into the top level of the group hierarchy as is done in Illustrator and Corel. I'm not sure which is better.

Newly created objects that have not yet been renamed by the user could even get descriptive default names based on the operation that created them such as "Plane", "Loft", or "Name of Script".

I'm sure that deprecating grouping by name would have consequences that I don't understand. Using v4 to open the 3dm file associated with the screenshots above has both objects named "sphere" get combined into a name group, so killing name grouping in v5 seems like it would be tolerated by v4. Opening a v4 file with v5 would require that a name group be converted to a hierarchical group which is not a function that exists now. Another immediate consequence that comes to mind would be the question of what scripts containing moi.geometryDatabase.selectNamed(‘name’) should do. I imagine this method would need to be changed so that it accepts group names if there are scripts in the wild using this method.

Are there severe insurmountable problems that will arise if grouping by name is deprecated? Will there be ongoing value from keeping the group by name mechanism?

Seems for have no troubles best is all name with different name! ;)

Hi Peer, thanks very much for the feedback and clear descriptions.

I'm doubtful that deprecation of object names working as a simple group-like mechanism would be good. There is still value in having a simple "tags" like functionality that doesn't change in-viewport selection behavior like grouping does.

But compatibility is an even bigger issue. This part here:

> "Opening a v4 file with v5 would require that a name group be converted to
> a hierarchical group which is not a function that exists now."

That just doesn't seem viable since there would be a major change in selection behavior when working on those objects. I don't want to have a v4 file opened in v5 to have very different behavior than v4 when working inside the viewport.

There should be other possible solutions than deprecating name groups. One method that I had thought about doing previously is to pop up a menu when you clicked on a name label that could have entries for "Assign here" and "Rename". That also provides a natural expansion point for more stuff in the future. A right click on the name could work as a shortcut for directly assigning with no menu popping up.

Another possibility would be to have left click on the object name do inline renaming and introduce some kind of button for assignment like something to the left of the selection dot. I don't really like that very much though it will be hard to convey the meaning of the "assign" button visually and I've tried very hard to not have a lot of internal narrow columns inside the scene browser.

It would also be good for renaming to be easier to access, it's a bit awkward right now.


re:
> I think I’ll come to like clicking on a group name to add a selected item to that group.
> In Illustrator and Corel I often have problems dragging an item through a long list in
> the Layers Palette so that I can drop it on another item for the purpose of grouping.
> Click to group avoids that problem.

Yes I have been trying pretty hard to not use drag and drop which can be awkward in a few different ways. Not only with traversing a long list but also it can be tricky indicating whether you want something as a sibling to a current item or as a child to it.


re:
> In addition to the disappearing object problem that new users like me may stumble over, it
> creates an inconsistency when coexisting with groups: I can give 2 groups the same name,
> but that doesn’t cause them to combine.

Yes, this is a consequence of the desired behavior for copying a group which is that the original group and the new copy of the group should be independently addressable in the scene browser.

Earlier I had considered making a separate section in the scene browser for groups but I think it's worked out better to have object names and groups work together in the same section.


re:
> I can even give 2 objects the same name, but not have them be grouped if they are at
> different levels in the group hierarchy:

Yes, but I think that's desirable, basically once you place an item inside of a group that object becomes part of the group and it's appropriate that the controls for it are scoped within the group.

It's consistent in that object (other then groups) name grouping only happens to objects that are siblings within the same direct parent. They can be siblings because they're at the root and not in any group, or they can be siblings within the same direct parent group.


re:
> However, if I Ungroup the 2nd "foo" the 2 objects named "sphere" get combined into a
> name group, which might not be what I intended:

Yes, but if it's not what you wanted the other "sphere" object is not selected while the one you just ungrouped is so you can reassign or rename or whatever you need to do to get your desired end result right now.


re:
> Newly created objects that have not yet been renamed by the user could even get descriptive
> default names based on the operation that created them such as "Plane", "Loft", or "Name of Script".

This is something I've deliberately avoided - having auto generated names causes the scene browser list to become very large and it's hard to wade through them all to find the names that are significant to you that you've specifically assigned.

I'll experiment some with a pop up menu when clicking on a name label and see how that feels.

Thanks,
- Michael

Hi Peer, so the popup menu method could go like this when you click on a name:



That should solve the disappearing name problem that you experienced because it doesn't do anything immediately if you just click on a name label.

Like other popup menus in MoI it would possible to use it by a press / drag / release over menu item instead of click + click. And also a right click on the name could do an immediate assign.

Another thing is that it would make it easier to rename something as well.

- Michael

Michael,

Re:
> it can be tricky indicating whether you want something as a sibling to a current item or as a child to it.

Hadn’t thought of that problem, having gotten used to one convention, but totally true.

Re:
> Like other popup menus in MoI it would possible to use it by a press / drag / release over menu item instead of click + click.

I didn’t know that, though I also don’t remember encountering any popups in MoI.

Re:
> I don't want to have a v4 file opened in v5 to have very different behavior than v4 when working inside the viewport.

Yeah that would be a significant problem for long-time users.

Re: video demo of popup

Thanks for whipping up a prototype! I expected from your written description that clicking or releasing while having the pointer over “Assign here” would cause “Unnamed” to become a child of “Group02” near the start of the video, but that doesn’t happen. Is the video showing a nonfunctional mock-up of the popup, or am I missing something?

The more I've thought about groups, the less sure I've become about what the problems are that I, as a user, need solved by the scene browser. Here's a list of the problems that come to mind, but there must be more.

Another view

- Providing a 5th view of the scene that shows relationships that aren't obvious in ortho or 3D. Like a hierarchical BOM.

Instancing

- Keeping track of instances of a part in case I change something about the base part and need to go through and replace all instances.

History

- To quickly delete recently created objects that I'm not happy with.

- As a history mechanism to allow reversion to a backup duplicate of an object or set of objects so that I can redo a sequence of edits on the object(s) in a different way. Here's an example from Illustrator where I'm doing destructive edits on the group "edges" and have a backup copy "edges bk" that I can revert to in case I don't like how my edits on "edges" turn out:

Selections that are hard in viewports

- As a history mechanism to retrieve previous selections and select a similar or identical set. This is either to bring back a selection that was difficult to make in the first place, or to bring back a selection that was easy to make at one time (e.g. right after a set of objects was created and could easily be selected), but no longer is (e.g. because the scene has gotten more complicated).

- Objects are overlapping in viewport space in such a way that it is not possible to draw a marquee (of either marquee type) that includes all of the wanted objects and excludes all of the unwanted. This is a problem that arises if I didn’t anticipate what I would need to select at the time that the objects were created or if ad hoc selections are needed because the sets that I desire aren’t disjoint. Maybe a lasso tool (freeform marquee shape) could help here.

- I want to select multiple objects, but there are too many to select individually, such as the result of Transform > Array. This is solved by the v5 implementation of groups where, if the objects resulting from Array are grouped then, clicking one of the group members in a viewport selects all group members. This also can be done in v4 by assigning the same name to all objects created by Array, selecting one of the objects, and then running a script to expand the selection to all objects with name matching that of the selection. Would it be a good idea to group results of Array by default, or at least have all objects resulting from Array including the original object, but not the curve of Array > Curve, be selected after Array runs to afford grouping?

- Objects aren't visible in viewports because they're behind or between other objects. A simple example is something like a painting canvas behind a frame. Say I want to select the edges of the canvas and extrude them toward the frame to make a shadow box sort of thing. I can't select the edges because they're hidden by the frame and a cover over the back of the frame:



Ok I could solve this by toggling visibility or orbiting the view, but maybe there are situations when it would be nicer to select the canvas and drill down into a tree in the Scene Browser to select the edges there.

- I want to select one object, but the ray in object space defined by the click point and the viewport projection encompasses more than one object. In KiCad this is solved by a popup context menu asking me which of the items under the click I wish to select and a preview of the selection on hover:



- Objects are outside of the viewport field of view, but I need to select them to perform an operation. This is something I do every day when projecting points through the cameraPt, which is unusual, but maybe there are other cases.

- I want to change Visible or Locked attributes of an object or set of objects, but can’t make the selection in a viewport because Visible = false or Locked = true.

Summary

Which of the problems above are already solved or should be solved in a different way? What other problems should be solved by the browser? Are there any examples of these problems being solved particularly well that I can play around with to refine my understanding?

Hi Peer,

re:
> Is the video showing a nonfunctional mock-up of the popup, or am I missing something?

It was just a nonfunctional mock-up, but I've almost got it working now and I think it should solve the "disappearing name" problem.

The "Rename" allows editing a name without needing to alter the selection so that should be helpful too.

re:
> have all objects resulting from Array including the original object, but not the curve of Array >
> Curve, be selected after Array runs to afford grouping?

I'll see about setting that up.

Thanks, - Michael