+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 <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
