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

Mon Mar 5 16:55:19 CET 2012

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