I know people have asked for a complete object outliner in the past ala Maya/Blender et al where you can see every individual object.
I think a more useful/realistic thing would be for something siilar, but in respect to groups. In the same way layers are so essential, groups are too. I think Groups should have their own panel (Eto style) so you could see all groups in a 3DM file. The group names tool is okay but quite manual. I think a UI similar to layers would be nice so that you could add objects into a group via buttons, remove, combine groups into one, collaps and expand subgroups and so on.
In the age of “data”, “Big data” and data everywhere, Rhino lacks heavily in ways to organize, structure and export data from geometry. Projects are becoming more complex with many people involved and everyone needs the different piece of data presented in a certain way. Not to mention how primitive and old school is making 2d drawings from the 3D - another big part to represent data.
Agree, I think that a panel to manage groups won’t be a big work or something dangerous for other tasks (the only issue I can think is if there are thousands of groups to visualize… in this case rhino could slow down).
Another panel I think is missing is the block manager (the same thingh we have in block manager but on a panel).
The only place I wonder if it could be dangerous is maybe in Layouts. Rhino does allow us a lot of flexibility such as having an object in a group but the objects tied to different layers, that must be quite complex when it comes to visibility and so on.
Regardless I would see having a persistent panel as an easy win and progression from the group names window command. I actually always forget the name of the window, so i had to map an alias for it because it wasn’t so intuitive.
If not, I will perhaps try and make a python go of it… but I’m sure it would probably be easier work for someone else to prototype!
Well, in my opinion the most dangerous thing is that, at the moment, you can put the same object in different groups and that is something difficult to identify and can cause a lot of problems (for example I use groups to keep toghether curves that I have to laser cut and if a hole changes it’s position all the production is garbage).
Also nested groups are very annoying… I have to ungroup several times to be sure to have everything ungrouped and then group again…
Obviously I could make some scripts to automate that procedures but I would like to see that implemented directly in Rhino.
That’s true regarding same thing in different groups. and sub objects.
Nested groups, so imagine if it was as simple as moving up one level like in the layers panel?
It was just a spitball anyway. Personally I think an all objects outliner would be overkill, but groups can be considered in my opinion close to layers in an organisational sense. So why not have a nice panel to visualise them. Not to mention the actual names themselves of the groups.
Hi Jonathan - this is really very nearly the same as NamedSelections - right now that panel, well, last I checked, is a little harder to use than it might be, but groups and named selection sets are pretty much the same thing, and I hope, will eventually be just one thing that you can get at from the panel.
Hmm, unless I’m mistaken when you select an object that is in a named selection, all the other objects in that selection do not get selected… so it’s not really like groups in that sense for the moment.
Hi Mitch - what I mean is that groups are really just selection sets, and it seems to me that the two could be merged. I dislike having features that are almost the same, but not quite…
You mean… merge in the same panel groups and selections?
Sorry but I don’t see that similitude (I understand the structure you can use to show a selection and a group but can’t understand how to manage selections and groups in the same tree).
Probably, if I have to merge something, I would compare groups with blocks (groups are the “poor relation” of blocks)
I understand your direction, but to me they are not the same at all. Selection sets are just sets of objects you might want to select at the same time, but they are not geometrically linked, you can operate on the objects independently and still have them stay as part of the selection set (as long as the operation doesn’t cause the object to lose its ID). If they are not visible they do not get selected.
Groups are objects that you want to keep in a constant geometric relationship within the group, and to be able to operate on them together. They stay grouped and can be moved, scaled even if some of the members are not visible or locked.
For me those are two different things for different purposes - I don’t see the general utility in combining them and potentially adding some hoops to jump through or losing some functionality.
Hi Mitch - you may turn out to be right - for now, to my mind these are very nearly identical, the main difference is that groups can only be accessed in the viewport or by special commands and selection sets in the panel. If selections could be set, and unset, to be treated as groups, for example, it seems they could be usefully combined. That, at least, is one direction I am thinking @trav might explore…
Yeah a good point. It seems almost the stuff inside of SelGroup could be displayed in named selections. It was mainly the idea of having the SelGroup window as a panel instead. I see what you’re saying, there’s definitely a closeness, only difference being sub objects in named selections I suppose?