Hi Michael.

And why groups should follow 2D programs in 3D program?
Problems with understanding this concept seen here don't confirm that's the best way.
But, I assume that's for sake the majority of users used to groups in those 2D applications.

Marek

Michael,

Direct selection with ctrl+click sounds handy.

Swiping is great on a graphics tablet!

Thank you for the bug fixes and generally being so responsive to criticism and questions.

A small question.

In the V5b, when I try scripts where the script crawls the objets like opencurves or SeparateObjectName with a moi.geometryDatabase.getObjects() or moi.geometryDatabase.getObjects().getCurves()
The grouped objects are not crawled, I think.

For exemple, SeparateObjectName verifies if objects have same name and then rename duplicate names with a "_NN" suffix.
I seems for V5b groups are objects and objects included in groups are not crawled as objects.
When I have two groups with same name, the two groups are renamed but objects in the groups with same names are not renamed.

For Opencurves, the scripts is now useless because with v5b we have the Menu Types/Curves/open

Have those scripts to be modified to scan objets in groups ?

HI Pilou,

re:
> When 2 objects (in the same group with or not the same type) have the same
> name only one object appears in the list of the group!

Yes, that's intentional. It's been a longstanding feature in MoI that you can give multiple objects the same name and then control them all as a set using the same label in the scene browser.

So named objects inside a group will have just one label inside that group, same behavior as named objects that are not inside of a group.

If you want to control them individually inside the scene browser you need to give them unique names.


> You are directly informed that there are 24 glasses named crystal on the table! ;)

You are already informed of that currently in the properties panel:



If those 24 glasses would have 24 individual name labels inside of the scene browser, that would not help to determine the number.

- Michael

Hi Marek,

re:
> And why groups should follow 2D programs in 3D program?

Because those 2D programs have had a feature called "Groups" for probably the longest time of any software and as a class of software they have the greatest consistency between them for how groups function.


> Problems with understanding this concept seen here don't confirm that's the best way.

It's incorrect to jump to that conclusion. The main response from people who understand it fine is just silence.


> But, I assume that's for sake the majority of users used to groups in those 2D applications.

Yes that's correct.

- Michael

Hi Phiro,

re:
> In the V5b, when I try scripts where the script crawls the objets like opencurves or SeparateObjectName
> with a moi.geometryDatabase.getObjects() or moi.geometryDatabase.getObjects().getCurves()
> The grouped objects are not crawled, I think.

In the current (May-22-2022) v5 beta they are crawled by moi.geometryDatabase.getSelectedObjects() but not by
moi.geometryDatabase.getObjects().

This has been updated for the next v5 beta so that they will be crawled by getObjects() too.

getSelectedObjects() (and getObjects() in the next v5 beta) can also take an optional true/false parameter for whether
to return objects inside groups or not. By default they will and will have both groups and all the objects inside
the groups within the returned list to help with compatibility with scripts.

So hopefully those scripts should be working ok after the next beta without the scripts needing
any adjustments for group handling.

The main kind of script that the "group crawling" causes problems with is ones that transform objects because
they try to transform the group and also additionally the group's contained objects. So that particular kind
of script needs an adjustment to get only the groups and no crawling which can be done by the true/false
parameter for .getSelectedObjects() and .getObjects() or by calling .excludeGroupChildren() or
.excludeGroupChildrenInPlace() on the object list which will remove objects in an object list that are contained
inside of any group also in the list.

- Michael

<< You are already informed of that currently in the properties panel:
Yes you right but it's some limited! ;)
Seems this is more informative! You see in a glance composition of any group!

Hi Pilou,

re:
> Seems this is more informative! You see in a glance composition of any group!

That is true. But what is it that you are gaining from knowing that information?

- Michael

> Problems with understanding this concept seen here don't confirm that's the best way.

It's incorrect to jump to that conclusion. The main response from people who understand it fine is just silence.

- I'm sorry, Michael for that, my bad.

I tried a little to understand the groups in Mol and it wasn't that hard at all, I have to admit that once it's caught it is not that complicated and it really has logic and consistency which makes it very useful on a daily basis.
I will never again doubt your talent and passion to make MoI such wonderful tool for us.

Marek

Thanks Marek!

<< what is it that you are gaining from knowing that information?

A total speedy knowledge of any grouped piece(s)!
Number (& composition) of screws, bolts, bricks, gears, beams, truss ...anything...
Very useful for estimate cost, surface, volume, weight ...etc...of somethings
Seems very useful for a minimum place on the screen for a maximum info!







etc...

Hi Pilou,

re:
> Very useful for estimate cost, surface, volume ...etc...of something
> Seems very useful for a minimum place on the screen...

These types of uses can be handled fine by something like generating a report with that information in it. In general it's not good to display too much information all at once on the screen all the time because it contributes to making a noisy and busy UI.

Really that type of thing is better handled by a more developed instancing mechanism though and not just by having a name property that is the same on each object. It's too easy for there to be 2 different objects that have the same name and would be mistakenly counted as the same object when they are not. Instancing would ensure they are copies of a common base template.

So maybe something like that could be appropriate in the instancing UI, we'll see.

- Michael

New Instancing in the V5 ?

<< It's too easy for there to be 2 different objects that have the same name and would be mistakenly counted as the same object when they are not.

so forbid a same name for a strict politic of structured data ?

Hi Pilou,

re:
> New Instancing in the V5 ?

I don't know when instancing will be ready, I think I'll probably be shooting for groups and folders in v5 and instancing probably won't be in the v5 timeframe.

- Michael

Hi Pilou,

re:
> so forbid a same name for a strict politic of structured data ?

MoI has supported having the same name on multiple objects as a simple way to make a type of one level group for a long time now, so no forbidding that would not fit in very well for MoI.

Instancing would be the way to make that type of structured data.

- Michael

OK thx for the infos!

Hi Michael,

Thanks for your Answers

P.

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