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

Mon Mar 5 14:50:39 CET 2012

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