Best way to name and manage groups

[magneto]

Are there any best practices/guidelines for this?

I see people just naming them to anything, while others always prefix with points_something, prims_something, etc. I feel prefixing would be useful because you know what type of group it is from its name. Is it a good practice?

Is it a good practice to replace a group down the network tree? For instance something like prims_top, where later you need a similar name, and you don't need prims_top. Is it ok to use the same name and thus override it?

What about using $OS, or opname for the group name field? I always use this too but it creates a problem if you are replacing an existing groups because 2 nodes can't have the same name in the same object so you end up with points_top, points_top1, which you can't use as the group name if you want to replace the group.

What do you guys recommend to manage groups most optimally? Should one delete them right after we are done with them?

Thanks

[hopbin9]

What ever works for you. At the end of the day, it's how good the render looks and not what the groups are called that are important.

I've often had groups lingering around in the SOP network that were no longer used. Never really bothered me. Sometimes I get a bunch that cause a little confusion, but it's like 2 seconds to throw in a clean to remove them. Less time then writing this post

[magneto]

lol yes, but I just want to follow the best practices if possible. Because the way I see it, one doesn't take more time than the other, so might as well use the best method IMO.

I have seen some people using group1, 2, etc but this would get confusing for someone who will need to work on that file. prims_innerglass, points_glassedge, etc is more user-friendly.

Just my 0.01 cents

[hopbin9]

I have seen some people using group1, 2, etc but this would get confusing for someone who will need to work on that file. prims_innerglass, points_glassedge, etc is more user-friendly.

You see, you're a smart guy and figured it out on your own.

I think these sort of things fall more into the category of laziness then effective practices. You can tell when someone was rushing or just not paying attention by how organized their work is, but with that said. I'll take the work done by a lazy disorganized VFX artist who produces great looking results over someone who's work is organized and fast but doesn't render that great.

Just my 0.02 cents (0.01 is a cent by the way, but you see I still understood what you meant, cause it's the results that matter). lol

Edited March 4, 2012 by hopbin9

[hopbin9]

Just my 0.02 cents (0.01 is a cent by the way, but you see I still understood what you meant, cause it's the results that matter). lol

Actually, that's not correct. 0.02 cents is actually 2% of a single cent. I should have said, my 2 cents.

[thinkinmonkey]

Magneto,

I use a lot the $OS to name my groups and I name the group nodes according their function:

group_pnt
group_prim
group_pntToDelete
grp_pntToConvertToPrim

In this way if I have to use a group in a formula of some other op, I have only to see the network to know the exact name of that group, saving a lot of clicks.

I prefer always to leave "group" as prefix, a behaviour I do with all ops, to tell the truth (copy_sphereToPoints, xform_topPart...), at least I put "grp" if the name is too long.

Cheers.

[magneto]

Thanks guys, good points all around.

Also reason I asked about group deletion is because I remember reading here that groups are slow and creates additional overhead so if they are removed after they are done, they speed things up. I guess this would only be apparent if the data set was very large, but still.

[thinkinmonkey]

Well,

the new H12 geometry core is fast enough to handle them, for what I understood, anyway, I think it's always a better idea to delete what you don't need, especially if you are exporting bgeo/simulation in order to have lighter files.

[magneto]

Btw since you mentioned the new geometry engine, in the new features page, it says "Vertex & edge groups (stored as attributes)". Does it mean we finally have actual edge groups?

If so that should be put as #1 feature IMO.