The Groups in MoI is a great idea but it looks like a little confusing for many users here including me.
I have been using ArchiCAD for years.
For me the grouping in ArchiCad is the most intuitive and user friendly way of dealing with them.
Particularly after I had to deal with them in AutoCAD, where as most things related to editing is a nightmare,

You select objects, then Ctrl+G - group them.
And one command is crucial here - Suspend Groups (Alt+G).
After you execute it, all groups are open and then you just can select any object in particular group, then Shift+Ctrl+G and this object is not a member of this group any more.
And now you can make any changes in all groups you want - adding (Ctrl+G), deleting (Shift+Ctrl+G).

Alt+G and groups are closed again and all changes for just edited group or groups are implemented.

HI Marky, I'm sure the ArchiCAD method works well but that is fairly different from how groups are handled in 2D vector editing programs like Adobe Illustrator, Affinity Designer, Inkscape, Microsoft Office, etc...

There is near universal treatment of groups in that class of programs and so I wanted to make MoI's grouping mechanism behave similar to those so it would have the greatest chance of being familiar to most people.

There is no concept in any of those programs for having a "suspend groups" / "resume groups" mode so that type of operation would be less familiar for a larger number of people.

- Michael

Just a little thing...
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!
Does it make sens to permit or forbid this? ( put something like 2 cube or never same name ...)
Permit seems very cool!
Say you have a group a 100 cubes (each cube is named box) maybe 100 box will be cool to have in the vertical list ?
Useful when you copy something for example! ;)
You are directly informed that there are 24 glasses named crystal on the table! ;)

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.