[Bf-committers] petition to remove 'protected' layers from armature

[Ton Roosendaal]

Hi Nathan & Bassam,

I suggest to bring back how it was in 2.49 then. The feature you  
requested makes sense but it's related to how you designed rigs as  
well. Instead of forcing this as a proxy feature, there could be an  
additional "do not pose this bone" property too for riggers.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 1 Jul, 2011, at 0:38, Nathan Vegdahl wrote:

> IIRC the reason for the protected/unprotected distinction is because
> of the way Blender updates bones in a linked+proxy armature: it
> completely overwrites the bone, including all pose information.  This
> doesn't matter for properties/transforms that are animated, since
> actions are stored separately from the pose bones.  But if a pose bone
> is moved without being keyed, those transforms are completely lost
> upon saving and loading the file.  Same with other properties on pose
> bones.
>
> This was extremely annoying on Sintel, for example, when an animator
> would change an IK/FK slider, or tweak a bone that wasn't animated,
> and that would be completely lost if they forgot to key it.  So to
> keep people from shooting themselves in the foot, we made it so that
> bones on protected layers (e.g. bones that get updated with the linked
> armature) couldn't be transformed in the first place.
>
> I agree that this situation completely sucks and needs to be changed
> at some point.  Updating of bones in proxy armatures should be more
> intelligent, instead of just overwriting, or Blender should be more
> intelligent about preserving changes made to proxy poses/properties,
> so that we can lose the whole protected/unprotected distinction
> altogether and have everything Just Work(tm).
>
> But just sayin' that it's not a totally trivial change.
>
> --Nathan
>
>
> On Wed, Jun 29, 2011 at 6:13 PM, Bassam Kurdali
> <bkurdali at freefactory.org> wrote:
>> Hello
>>
>>  Behavior of protected armature layers has changed a couple of  
>> times at
>> least, to the point where the original design intent is unclear at  
>> best.
>>  I propose the option be removed entirely, and revert armature  
>> behavior
>> to that of *protected* layers, as it was in blender 2.49b.
>>
>>  Link to bug:
>> http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=27501
>>
>>  Rationale:
>> In 2.49 we had a good option and a bad option: good was protect,  
>> bad was
>> 'don't protect'. As a result, riggers had to click on 'protect' for
>> every layer in the (proxy) armature. Protect as an option is  
>> effectively
>> useless, since there is only one real choice. Note that the  
>> behavior of
>> protection has changed during it's existence even prior to 2.5. I'm
>> currently unaware of a design document that adequatly specifies what
>> it's for.
>>
>> In 2.5 we have two (in my opinion, and others) bad choices.
>>
>> Don't protect: rig changes don't propogate to animators (things like
>> constraints, drivers, transform locks, bone groups, etc.. the rig  
>> just
>> breaks) on this layer.
>>
>> protect: you can't pose the rig on this layer.
>>
>> So what happens if the rig changes? well, you can either:
>> -delete and remake the proxy
>> -protect the layer(/s) save the rig, load the anim file, save it,  
>> open
>> the rig, unprotect...
>>
>> BUT: in either case you will lose custom constraints, parenting in  
>> the
>> anim file... so you are left chosing between not getting rig changes,
>> losing animation data, or fighting to get both working... given that
>> production rigs change quite a bit, this is a workflow killer,
>> especially for a small team.
>>
>> I believe the change happened during Sintel, so I'm CCing Nathan to  
>> see
>> if he has insight into the change. I'm hoping for a small, calm
>> discussion between those who understand the issues (coders, and  
>> riggers/
>> TDs in medium to largish projects) to either come up with a good
>> design/workflow, or just remove the feature.
>>
>> PS I was initially going to email Nathan individually, but then  
>> thought
>> this might just contribute to how opaque this feature has gotten ;)
>>
>>
>> _______________________________________________
>> 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
>