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

[Daniel Salazar - 3Developer.com]

+1

Obviously (as the report in tracker is mine) this has struck me too. I
just don't get this.. This behavior only makes me do a whole lot of
monkey work that wasn't necessary before. Every time I update a rig it
means dozens of pointless save and reloads. And working on SVN makes
it more complicated. Terrible for production

Daniel Salazar
3Developer.com



On Wed, Jun 29, 2011 at 7: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
>