People who’ve worked with me already know my attitude towards groups and why I always tell people who collaborate with me NOT to use them. But they never bother investigating why I tell them so. I agree that it is easy to condemn something right away, however, believe me, I have very good reasons for doing so.
The thing with groups in Max is that they are a special form of a hierarchy which isn’t transparent enough for a general user. They’re fast to create, but mainly, groups are a very convenient way for creating selection sets that are persistent (i.e. they get saved with the file) and you can return to them anytime you want and select a bunch of objects immediately just by clicking on any of the members in the group. These are all great advantages of gropus. The huge disadvantage is their transparency (by that I mean the way they work is hidden from the general user). A user can quickly and easily get carried away and make complex nested group assemblies which can become a REAL pain in the ass in the production pipeline if not taken care of properly. I personally don’t use groups at all (as you can easily substitute them for a different, pipeline friendly, workflow) and very strongly recommend anyone who shares files with me or any other member in our production environment, NOT using them as well.
So, what is so special about groups in Max? As I said, they’re a special kind of a hierarchy called “ObjecSet” in Max. They can be accessed as a selection array from within MAXScript, but the objects inside a group AREN’T actually the group’s children as the property “.children” doesn’t exist for groups. This can cause a lot of problems if you didn’t count with groups inside your scripts! Also, I’ve seen quite a few examples of people leaving group assemblies in your model sets and animating with them as if they were regular objects. This is almost tragic, because once you’ve animated such structure you’re pretty much screwed modifying anything in the group assemblies and as soon as you “ungroup” any of the object sets the hierarchy gets broken and you loose your animation data. Many times I’ve been asked to “fix” such scenarios (well, it is my job after all, but still it pisses me off when somebody does exactly the oposite you’d told them and then you have to fix their mess) with scripting. Of course it is absolutely possible to script tools bearing gropus in mind, however, this puts quite a lot of work on the scripter/TD as they have to write different functions for dealing with these as well as take extra measures to not break anything in somebody’s work that took hours to do. For the user, it’s a no brainer, well, the TD will fix it anyways, so why bother. But, that isn’t a very bright idea to carry on. Usually, TDs, as expressed in my earlier articles, are quite busy working out some more complex tasks as well as TDs are usually being paid more than a general user at studios as this position requires a more thorough knowledge of the system the team works with. So, counting on a TD in a case when a TD told you NOT TO DO THAT isn’t fair.
Anyways, back on topic. Users always ask me “Hey, what else should I use instead of gropus?” when I tell them not to use gropus. It’s simple. You have quite a few, pipeline friendly, tools that you can and SHOULD use instead of groups. For example standard hierarchies, i.e. linking (parenting) object sets to another object, preferrably a point helper (remember, double clicking on a parent’s object selects the whole object set). Or, very powerful, Named Selections, which are especially great and pipeline friendly as they are also persistent (get saved with the file), don’t require another object introducet for linking to (parenting to) and are very easily modified, including nesting, which isn’t possible in a standard hierarchy (an object can only have one parent). Also, you can use layers for arranging object sets into logical groups. All in all, you actually don’t need groups for productive and fast workflow, just get used to the other concepts.
For the first named example, there are number of tools and scripts that you can use to streamline the creation of a parent node and linking all the selected nodes to it. I personally recommend mGroup (Maya-like grouping written by a great TD, Paul Neale), it’s easy to setup, easy to maintain and easy to use so that even the jr.s can be instructed for using it in no time.
If you, for whatever reason, want or must use groups anyways, let me, at least, explain to you, what groups are and how they work internally in Max so that you, perhaps, pay a bit more attention before hitting the “Group” button. When created, groups are stored as a Dummy object (a null helper in Max) and all the selected objects will become the Dummy’s children. The Dummy is then set as the “head” of the group, which is very important as it makes the object invisible to the user and all of its properties inaccessible in the modify panel. Through scripting, you can mess things up quite a lot and make some strangely behaving object sets, so be careful and read the user documentation properly. So, after this, the group becomes an enclosed entity that reacts to user input in a different way than you’d expec, for example, clicking on any of the group members (objects) will select the whole group. Animating the group actually sets keyframes on the group head’s controllers instead on all the group member controllers, thus when “exploded” (ungrouped) you loose all the animation data, because the group’s head gets automatically deleted. When you start linking (parenting) groups to other objects (i.e. adding them to a hierarchy) and then you decide to ungroup the given groups, the objects within the groups will get re-linked to the previous group’s parent. This can cause some very strange behavior because, as I glanced in the past, all of the objects’ transformations always get calculated in the parent space, so, in effect, if the group head had a different orientation than the group head’s parent and you ungrouped the object set all the objects within the group snap to reflect their new parent space orientation, especially if the objects carried some animation or worse yet, you controlled the objects within scripts (but this usually doesn’t happen as TDs, usually, know these issues and know how to avoid them ). So if you’re not 100% sure what you’re doing, rather don’t do it! On the other hand, if you really know what you’re doing, then by all means, use groups as they are really fast and convenient for quick selection placeholders and scene management, but never forget to clean your scenes up after you’re done with them and ready to send them down the pipeline, because there are people that might not be aware of a group presence and this can cause a lot of trouble to them.
So, this was a sum of what the group assemblies are, how they work and why you should avoid using them. So, please, for the sake of the sanity of your TDs at your company, whenever you’re tempted to press tha magical “Group” button, think twice and try using some of the alternatives mentioned in this article, learn your way with Layers, Named Selections or standard, regular, hierarchies, you’ll save you and the TDs a lot of time, pressure and frustration and keep your scenes pipeline friendly and less prone to incompatibility issues with tools, scripts and plugins.