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

[Nathan Vegdahl]

> 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