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

[Daniel Salazar - 3Developer.com]

Maybe the solution is to have easy access to property flags, hopefully
in the same UI where properties are created. We already have some
*useful* flags like ['HIDDEN', 'SKIP_SAVE', 'ANIMATABLE'] but they can
only be set on creation time from py. It makes more sense to to set
them on the fly, here an 'SKIP_PROXY_REFRESH' (working tittle!) seems
like the obvious way to go?

cheers

Daniel Salazar
3Developer.com



On Thu, Jun 30, 2011 at 4:38 PM, Nathan Vegdahl <cessen at cessen.com> 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
>