[Bf-committers] Component Group Proposal

Tue Aug 17 22:05:55 CEST 2010

I'm bumping this thread, was any consensus ever reached on this topic?

On Thu, Jul 8, 2010 at 2:58 AM, Nathan Vegdahl <cessen at 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 <cessen at 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
> > <zanqdo at 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
> >> <mikejamesbelanger at 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 <
> >>> zanqdo at 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 <
> >>> > zanqdo at 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 <
> ktbluear at 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" <zanqdo at gmail.com>
> >>> > >> Subject: Re: [Bf-committers] Component Group Proposal
> >>> > >> To: bf-blender developers <bf-committers at blender.org>
> >>> > >> Message-ID:
> >>> > >>     <AANLkTilmAVQruRz6nq-M4G2Os-N4hWy58BdUrxSk6qKC at 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 <
> ktbluear at 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 at blender.org
> >>> > >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >>> > >> >
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >>
> >>> > >> _______________________________________________
> >>> > >> Bf-committers mailing list
> >>> > >> Bf-committers at blender.org
> >>> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>> > >>
> >>> > >
> >>> > >
> >>> > _______________________________________________
> >>> > Bf-committers mailing list
> >>> > Bf-committers at blender.org
> >>> > http://lists.blender.org/mailman/listinfo/bf-committers
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> www.watchmike.ca
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers at blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >>>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>