[Bf-committers] Component Group Proposal

Thu Jul 8 11:58:55 CEST 2010

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
>>
>