[Bf-committers] Weekly developer meeting minutes, march 4 2012

Tue Mar 6 02:40:30 CET 2012

> To make it flexible and predictable/simple would probably
> take re-engineering a bit- for instance, pulling transform out as
> independent 'thing' that is stackable (or in the future nodable) along
> with constraints,

Yeah, this is what I'm hoping for in the future (I think we've
discussed this before?).

In any case, I think I've changed my mind.  Particularly since it
sounds like this patch also organizes things more cleanly code-side,
which will probably actually make things less likely to break in the
long-run.  And I can always just keep ignoring the option if I don't
want to use it. ;-)

A cleaner system is a larger project anyway, as Bassam notes, so I
probably shouldn't worry about short-term special-case features within
our current more limited system.

--Nathan

On Mon, Mar 5, 2012 at 7:55 AM, Bassam Kurdali <bassam at urchn.org> wrote:
> The original hinge option was added by Ton as a simplifier for users;
> the idea was to avoid using multiple bones and constraints when a
> simple option could take care of it.
>
> This fell down almost instantly, because animators asked for a 'global'
> parent bone. had there been an option to limit the hinge length - like
> in IK constraints - it would have been possible to use.
>
> Complexity in dealing with the Hinge during transform is probably
> similar to constraint offsets - which, (and this supports the
> naysayers) was broken until very, very recently, until somebody (maybe
> Bastien himself) fixed it.
>
> >From a python perspective, my code always works with hinge options and
> I'd support this, but I throw up my arms in frustration if there's
> constraints on a bone (I want to affect).
>
> My final comment:
> the complexity of this system is not fixable by removing options. That
> will just make it rigid (in general, not talking about this specific
> situation). To make it flexible and predictable/simple would probably
> take re-engineering a bit- for instance, pulling transform out as
> independent 'thing' that is stackable (or in the future nodable) along
> with constraints, which eliminates the need for specific offsets in
> constraints, dx,dy,dz graphs, parent offsets, heck, maybe parenting
> itself becomes a constraint and a transform.
>
> However, until that, or something similar happens, why not make this
> option actually usable? it would eliminate some level of complexity in
> rigs, which can't be a terrible thing after all.
>
>
>> I don't know about code complexity, but about usability, the hinge
>> option has the disadvantage of being toggleable only. A setup based
>> on constraints lets you decrease or increase the influence of the
>> effect, in the case that you need to.
>>
>> But well, you have to admit that having the hinge option available
>> might be useful for people who don't like or don't know much rigging.
>>
>> If this modification promised not to affect the performance of
>> complex armatures I wouldn't mind having it, I think I'd never use it
>> anyway, hehe, but that's just me, many people might be comfortable
>> with the hinge option. But well, if it depended on me, the only
>> condition would be that this didn't affect performance. So I guess it
>> should be tested with complex rigs.
>>
>>
>>
>> > Date: Sun, 4 Mar 2012 22:05:22 -0800
>> > From: cessen at cessen.com
>> > To: bf-committers at blender.org
>> > Subject: Re: [Bf-committers] Weekly developer meeting minutes,
>> > march 4 2012
>> >
>> > > However, at the other end of the spectrum, you
>> > > don't want the rigger doing too much stuff over
>> > > and over.
>> >
>> > I agree.  But I would still rather see hinge deprecated than
>> > improved. I guess we just have different thresholds for "added
>> > back-end complexity" vs "shorter workflow".  To me, this has a very
>> > minor workflow benefit, but appears to make quite a lot of changes
>> > and add a fair amount of complexity to the transform code base.
>> >
>> > When a short-cut feature is very localized to a small area of code
>> > (e.g. the head/tail slider on copy location constraints) I am much
>> > more comfortable with it.  But to my eyes this looks like overkill.
>> >
>> > Quoting again:
>> >
>> > > you
>> > > don't want the rigger doing too much stuff over
>> > > and over.
>> >
>> > The other thing is that this doesn't actually reduce that much
>> > repetition.
>> >
>> > Maybe I'm biased because of Rigify, but improving the hinge feature
>> > to reduce repetition in rigging seems to me like giving someone a
>> > hand warmer when they're stuck in a violent snow storm.  It helps a
>> > little, I guess, but... not much.  There are so many sources of
>> > repetition in rigging.  Making this single specific case easier--at
>> > the expense of a lot of code complexity--doesn't really seem worth
>> > it to me.  It's not really a "sustainable" way to make rigging
>> > easier/faster.
>> >
>> > --Nathan
>> >
>> >
>> > On Sun, Mar 4, 2012 at 7:22 PM, Mike Belanger
>> > <mikejamesbelanger at gmail.com> wrote:
>> > > This new feature looks like it might re-validate Hinge.  From
>> > > what I understand from the wiki, a bone inheriting from not its
>> > > immediate parent, but from its earlier parent *could* be useful.
>> > > Sure, like Nathan says, the behaviour can be done with trivial
>> > > rig setups.  However, at the other end of the spectrum, you don't
>> > > want the rigger doing too much stuff over and over.  In theory,
>> > > the rigger *could* 'flatten' the entire hierarchy (minus the ik
>> > > arms) and have basically no child bones, and define all
>> > > relationships with constraints - but that'd be a lot of work.
>> > >
>> > > Interested in this feature.
>> > >
>> > > On 2012-03-04, at 7:53 PM, Nathan Vegdahl wrote:
>> > >
>> > >>> - Bastien Montagne worked on new/better definition for "Hinge"
>> > >>> bone:
>> > >>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
>> > >>
>> > >> In no way do I intend to disparage Bastien's work on this, but is
>> > >> improving the hinge feature even necessary?  In my mind, the
>> > >> hinge feature is deprecated.  I never use it.  You can
>> > >> accomplish the same behaviors (including the behaviors that this
>> > >> patch would enable, and beyond) with trivial rig setups.  This
>> > >> just feels like unnecessary UI clutter and code complexity to me.
>> > >>
>> > >> I'm not saying we shouldn't have *any* shortcuts in Blender's
>> > >> rigging features.  I just think we should be selective.  Perhaps
>> > >> my selectivity threshold in this case isn't calibrated that same
>> > >> as other's...?
>> > >>
>> > >> --Nathan
>> > >>
>> > >>
>> > >> On Sun, Mar 4, 2012 at 9:23 AM, Ton Roosendaal <ton at blender.org>
>> > >> wrote:
>> > >>> Hi all,
>> > >>>
>> > >>> Here's the notes from today's meeting:
>> > >>>
>> > >>> 1) current projects
>> > >>>
>> > >>> - Today BCon2 starts, which means we should freeze the release
>> > >>> targets now. http://wiki.blender.org/index.php/Dev:Doc/Projects
>> > >>>
>> > >>> - Lukas Toenne finished group nodes patch, awaits review still,
>> > >>> added to release targets.
>> > >>>
>> > >>> - Cambell Barton fixed BMesh docs as agreed last week. Check
>> > >>> his week report here:
>> > >>> http://wiki.blender.org/index.php/User:Ideasman42/WhatImWorkingOn#Week_80_.28Feb_27.29
>> > >>>
>> > >>> - Lukas also is working on custom nodes: (similar to pynode, as
>> > >>> first step towards plugins)
>> > >>> https://www.gitorious.org/~lukastoenne/blenderprojects/blender-lukastoenne/commits/custom_nodes
>> > >>>
>> > >>> - Bastien Montagne worked on new/better definition for "Hinge"
>> > >>> bone:
>> > >>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
>> > >>>
>> > >>> - Nicholas Bishop: sculpt masking is getting closer to
>> > >>> finished, there are patches and documentation links here:
>> > >>> http://nicholasbishop.net/wordpress/?p=44
>> > >>>
>> > >>> - Sculpting partial-visibility patch has been reviewed and is
>> > >>> ready. http://codereview.appspot.com/5695043/
>> > >>>
>> > >>> 2) Google Summer of Code
>> > >>>
>> > >>> - End of this week is deadline for submitting Blender
>> > >>> Foundation as Google Summer of code organization. Tom Musgrove
>> > >>> will be handling this, Ton Roosendaal will coordinate the
>> > >>> day-to-day GSoC duties.
>> > >>>
>> > >>> User wish list;
>> > >>> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Wishlist
>> > >>>
>> > >>> Official page for developers:
>> > >>> http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Ideas
>> > >>>
>> > >>> - The target is to get the official ideas page to only mention
>> > >>> ideas that: a) are commonly accepted projects, fitting in
>> > >>> roadmap b) are being backed up by the module owners
>> > >>>  c) are likely to get a mentor who can also review code and
>> > >>> help migrating code to trunk
>> > >>>
>> > >>> Thanks,
>> > >>>
>> > >>> -Ton-
>> > >>>
>> > >>> ------------------------------------------------------------------------
>> > >>> Ton Roosendaal  Blender Foundation   ton at blender.org
>> > >>> www.blender.org Blender Institute   Entrepotdok 57A  1018AD
>> > >>> Amsterdam   The Netherlands
>> > >>>
>> > >>> _______________________________________________
>> > >>> 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