How many CP groups do you use?

[nemyax]

How many CP groups do you guys usually have in your models? What's the most groups you've had? How many of your groups are solely for material assignment?

[robcat2075]

I can't give a count but aside from material assignment I often have Groups that are there purely to makes selections I often need to hide or lock particular portions of the mesh, either while modeling or rigging.

If you feel you have too many Groups to look at you can do New>Folder and put the less frequently needed ones in that.

[nemyax]

robcat2075

Would you say 32 non-material groups was plenty? Or would that be too tight a limit?

[Shelton]

Like Robert posted I have groups for rigging and groups for a reason like material or to decal. I have tried to use folders but it seems they don't transfer well after and action and export. 32 doesn't sound too many

[robcat2075]

robcat2075

Would you say 32 non-material groups was plenty? Or would that be too tight a limit?

 

 

I would not limit myself. If i need a Group... I need it.

[largento]

You can put them into folders if you want to have them more organized and not see so many at once.

[Fuchur]

I'd say he is talking about something programming relevant. If you have to limit it, limit it to at least 64 groups. 32 is a litte bit to tight.

Best regards

*Fuchur*

[robcat2075]

Nemyax, tell us more about why you might wish to limit groups.

[Guest]

My steam locomotive is assembled in an action from two models. The chassis and wheels model has 169 groups, the boiler and cab model has 200 groups. I would find a 64 group limit to be unusable.

[nemyax]

robcat2075

I may be working on a little modeller of my own. Slapping on a 32-bit bitmask for group membership tracking is the easiest thing to do, but from the answers here it looks like such a limit is artificial.

[Rodney]

Slapping on a 32-bit bitmask for group membership tracking is the easiest thing to do, but from the answers here it looks like such a limit is artificial.

 

It may be low but it would certainly cover basic modeling requirements.

I suppose one question might be what might happen to extra groups the modeler encounters.

Presumably they would simply be ignored.

[Wildsided]

When I make a model I use as many groups as it takes to make it. Then, once it's finished, I tend to go through and delete or consolidate any groups I don't need for the sake of tidiness. Also, I find that having lots of groups can bog down A:M. I sometimes find that it will take forever for a CP to be placed or a spline to delete, but once I thin out the groups those issues go away. That probably has more to do with the power of my machine than the software though.

[Rodney]

Dan brings up a very good point.

With every Copy/Paste of Groups in a model those Groups get duplicated... so that alone can lead to a very large number of Groups.

As Dan suggests however, most of those Groups are not important and can be removed.

As I tend to be a lazy modeler I often don't do that.

Then there are the Groups that don't have anything assigned to them.

Those can be removed too.

 

A:M does have a Purge Empty Groups option but it can't think for us and Merge groups intelligently.

For instance, one hundred rivets on multiple metal sheets found throughout a model that each have their own Group assigned to them might be served just as well with one Group.

They just need to be combined.

 

In the case of Groups it is the geometry that is most important.

The Groups are just a means of organizing that geometry.

 

Perhaps using your suggested approach of 32bit bitmask multiple bitmasks could allow for reference to a sequence of bitmasks... each containing 32bits.

This would be a near equivalent of what we do now with Groups that are nested inside of other Groups or geometry that belongs to more than one Group.

In other words, your approach could form the underpinnings of an improvement to the way we deal with Groups.

[nemyax]

Perhaps using your suggested approach of 32bit bitmask multiple bitmasks could allow for reference to a sequence of bitmasks... each containing 32bits.

I think I'll go with binary trees of pointers to item as the representation of groups. That doesn't impose silly limits and should make querying and merging reasonably fast.