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

[Bassam Kurdali]

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 ;)