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

Nathan Vegdahl cessen at cessen.com
Tue Jul 5 00:08:44 CEST 2011 

Huh.  Fair enough.  I still am very much in favor of ridding Blender
of the "protected layer" concept entirely.

But having said that, the proxy system has a lot of more pressing
limitations anyway.  It works okay for the specific case of a single
armature that someone needs to animate, but especially as we saw on
Durian with simulation, etc. it really would be good for it to be more
general.

So it probably makes sense to hold off making non-trivial changes like
that to the proxy system anyway, until we're prepared to look at it
more big-picture.  (Campbell, Brecht, and I had some discussions about
this on Durian.  Perhaps it's time to start putting together some
proposals...)

--Nathan


On Sun, Jul 3, 2011 at 12:42 PM, Bassam Kurdali
<bkurdali at freefactory.org> wrote:
> 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
>
>
> _______________________________________________
> 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