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

Bassam Kurdali bkurdali at freefactory.org
Sun Jul 3 21:42:24 CEST 2011


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 <ton at 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   ton at 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
> >> <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
> >>
> >
> > _______________________________________________
> > 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




More information about the Bf-committers mailing list