I'm bumping this thread, was any consensus ever reached on this topic? On Thu, Jul 8, 2010 at 2:58 AM, Nathan Vegdahl <ces...@cessen.com> wrote:
> Hmm... I shouldn't skim threads to quickly. It seems all my points > have already been addressed. In that case, I second the gist of the > proposal. ;-) > > On Thu, Jul 8, 2010 at 11:56 AM, Nathan Vegdahl <ces...@cessen.com> wrote: > > I agree with this. But I'd also like to point out that in complex > > rigging the rigger often also wants to make distinctions that are not > > inherent in the software, as well as associate things that are not > > inherent in the software. I wouldn't want to be stuck with one set of > > vertex groups that are only for bones, and another that's only for > > particle emission, and another that's only for something else, etc. I > > may want to make a vertex group serve a dual purpose for a bone weight > > and something else, for example. Or I might want two armature deform > > modifiers, but operating with different weighting. Or who knows what. > > Rigging is a crazy thing. > > > > So if we head in this sort of direction, I would rather have a system > > that lets me organize vertex groups myself (perhaps with some sane > > defaults) than a system that enforces upon me distinctions and > > similarities that may not fit how I've constructed a rig. Maybe > > something like vertex group groups. Ha ha. ;-) > > > > --Nathan > > > > On Tue, Jun 22, 2010 at 9:45 PM, Daniel Salazar - 3Developer.com > > <zan...@gmail.com> wrote: > >> That proves my point, there is a need for a distinction, and its not > that > >> simple. You would need to also name all your bones starting with RIG > because > >> vgroups are linked to bones by the names > >> > >> Daniel Salazar > >> www.3developer.com > >> > >> > >> On Tue, Jun 22, 2010 at 1:42 PM, Mike Belanger > >> <mikejamesbelan...@gmail.com>wrote: > >> > >>> In current ( 2.49b) to make a distinction between modifier and rigging > vert > >>> groups, I just prefix names with RIG or VERT. Does this help? > >>> > >>> On Tue, Jun 22, 2010 at 2:03 PM, Daniel Salazar - 3Developer.com < > >>> zan...@gmail.com> wrote: > >>> > >>> > Also I want to mention this would help on the tasks of deleting all > >>> vgroups > >>> > used on an armature without deleting the ones used on hair or similar > >>> > stuff. > >>> > Currently I use a simple py script with an exclusion list for this > >>> > repetitive task. Would be nice if we could do this kind of operations > for > >>> > the relevant set only > >>> > > >>> > Daniel Salazar > >>> > www.3developer.com > >>> > > >>> > > >>> > On Tue, Jun 22, 2010 at 12:58 PM, Daniel Salazar - 3Developer.com < > >>> > zan...@gmail.com> wrote: > >>> > > >>> > > Yah I mentioned this is a visual separation I'm proposing > >>> > > and completely optional. A group belonging to one set or another > >>> woudn't > >>> > > have any effect on the group's usage all over blender. > >>> > > > >>> > > Daniel Salazar > >>> > > > >>> > > > >>> > > > >>> > > On Tue, Jun 22, 2010 at 8:49 AM, Brandon Phoenix < > ktblu...@yahoo.com > >>> > >wrote: > >>> > > > >>> > >> Hey Daniel, > >>> > >> Just to clarify: "Maybe you can expand this concept to include > Group > >>> > >> Sets? This would be bags of data groups that could > >>> > >> classifyvertes/edges/groups for their usage". Here you're > essentially > >>> > >> suggesting groups of groups? So that all of the vert groups used > in > >>> > rigging > >>> > >> are kept separate from, say, the groups used to emit hair etc.? > >>> > >> I'm not sure I agree with this though: "example the set of vertex > >>> > >> groups that an specific armature modifier uses should not be > visually > >>> > >> mixed with the ones that are just used to feed another modifier". > I > >>> can > >>> > >> think of cases that it may be beneficial to use the same edge > group > >>> for > >>> > >> multiple things. For example, it is often beneficial to seam UVs > along > >>> > hard > >>> > >> normal edges, so the sharp marked edge group could just be passed > into > >>> > the > >>> > >> UV set, if that makes sense. Perhaps if it was at the user's > >>> discretion > >>> > to > >>> > >> separate the group sets. I'll need to speak to matt_e about a UI > >>> > >> implementation of this, because I'm not sure I've seen something > like > >>> it > >>> > >> (outside of the outliner). I like the idea though, I'll see what I > can > >>> > draw > >>> > >> up. > >>> > >> Thanks, > >>> > >> -Brandon Phoenix > >>> > >> (I realized in my initial e-mail, I signed my name "Brandon > Phoenix?". > >>> > >> Oops.) > >>> > >> -----------------------------------------------------------Date: > Sun, > >>> 20 > >>> > >> Jun 2010 21:11:04 -0600 > >>> > >> From: "Daniel Salazar - 3Developer.com" <zan...@gmail.com> > >>> > >> Subject: Re: [Bf-committers] Component Group Proposal > >>> > >> To: bf-blender developers <bf-committers@blender.org> > >>> > >> Message-ID: > >>> > >> <aanlktilmavqrurz6nq-m4g2os-n4hwy58bdurxsk6...@mail.gmail.com > > > >>> > >> Content-Type: text/plain; charset=UTF-8 > >>> > >> > >>> > >> This is something that has been a real need since the introduction > of > >>> > >> modifiers. Maybe you can expand this concept to include Group > Sets? > >>> > >> This would be bags of data groups that could classify > >>> > >> vertes/edges/groups for their usage, example the set of vertex > groups > >>> > >> that an specific armature modifier uses should not be visually > mixed > >>> > >> with the ones that are just used to feed another modifier > >>> > >> > >>> > >> cheers > >>> > >> > >>> > >> Daniel Salazar > >>> > >> www.3developer.com > >>> > >> > >>> > >> > >>> > >> > >>> > >> On Sun, Jun 20, 2010 at 9:05 PM, Brandon Phoenix < > ktblu...@yahoo.com> > >>> > >> wrote: > >>> > >> > This proposal is aimed at expanding the functionality of vertex > >>> groups > >>> > >> and unifying the UI by adding both vertex and face grouping. This > may > >>> be > >>> > a > >>> > >> bit late for the 2.6 release, but should probably be considered > for > >>> the > >>> > >> future. I would like to solicit as much discussion on the topic as > >>> > possible. > >>> > >> The document is here: > >>> > >> > > >>> > >> > http://dim.blenderge.com/Documents/componentGroupProposal.pdf > >>> > >> > > >>> > >> > Thank you, > >>> > >> > > >>> > >> > -Brandon Phoenix > >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > _______________________________________________ > >>> > >> > Bf-committers mailing list > >>> > >> > Bf-committers@blender.org > >>> > >> > http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> > > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> _______________________________________________ > >>> > >> Bf-committers mailing list > >>> > >> Bf-committers@blender.org > >>> > >> http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> > >>> > > > >>> > > > >>> > _______________________________________________ > >>> > Bf-committers mailing list > >>> > Bf-committers@blender.org > >>> > http://lists.blender.org/mailman/listinfo/bf-committers > >>> > > >>> > >>> > >>> > >>> -- > >>> www.watchmike.ca > >>> _______________________________________________ > >>> Bf-committers mailing list > >>> Bf-committers@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers