Given the title of this thread the following will be a bit funny: I don't really want protected layers removed, and the current solution from Ton works for me (as well a 'do not pose' flag) I just had issues with the not-posability of protected layers in the end. and a larger problem, which is just being hazy as to the design intent, ton explained it quite well on irc, however: Protected Layers-> refreshed from rig file. Allows pose in scene file (such as adding keys/local constraints) UnProtected layers-> Not refreshed from rig file. Allows adding local bones (and presumably deleting bones?) In addition to adding pose to any bones that may have originally came from the rig.
As a rigger, here's how *I* would use this: While the rig is 'in progress' leave an empty unprotected layer for local bones in scenes, if needed. Once a rig is done, unprotect all the animator layers-> this is mainly to allow animators to not lose poses on unkeyed bones (this is probably a workaround to a bug, but hey) A do not key flag per layer would be useful, but not critical for me. On Sun, 2011-07-03 at 11:15 -0700, Nathan Vegdahl wrote: > For the record, I don't think I ever requested for protected bones to > be un-transformable. I could be mis-remembering, of course (maybe I > had a brain fart back then). But it doesn't provide mcuh benefit to > me as a rigger, and I don't see much benefit to animators, since I can > just put controls on unprotected layers anyway. I was just relating > what I recalled the justification to be (i.e. a 'safe guard' so that > animators wouldn't transform protected bones expecting them to stick). > > And, again, I totally agree with the larger petition as well. > > > there could be an additional "do not pose this > > bone" property too for riggers. > > I would love to see a more broadly-applicable and finer-grained > property locking mechanism, yes. But that has little to do with the > issue at hand, I think. > > --Nathan > > > On Sun, Jul 3, 2011 at 11:05 AM, Ton Roosendaal <t...@blender.org> wrote: > > 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 t...@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 > >> <bkurd...@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@blender.org > >>> http://lists.blender.org/mailman/listinfo/bf-committers > >>> > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers