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

[Nathan Vegdahl]

> It's not a trivial change, which is why it shouldn't have been made so
> trivially in the first place.

Uh... okay.  What I'm saying is that removing the concept of protected
layers entirely is not trivial.  It would be trivial, of course, to
allow protected bones to be transformed and animated again, which
would be a good idea, and I think would alleviate your issue, would it
not?

I am merely pointing out that the larger petition you are making (to
remove the concept of protected layers entirely) is not so simple as
that, and will require some real coding/design work.

--Nathan


On Thu, Jun 30, 2011 at 4:04 PM, Bassam Kurdali <bkurdali at freefac.org> wrote:
> I understand the issue, but the solution is worse than the problem.
> On Thu, 2011-06-30 at 15:38 -0700, 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.
> This has been a long standing issue. But you're taking problems with one
> specific project's workflow (Sintel) and applying it across the board.
> In our case this is creating severe issues. I'm working with many
> animators remotely, many of whom have never used blender before. Due to
> time constraints, it's not possible to wait till the rig is done. As a
> result, I'm having to juggle many tasks with actually directing the
> project: Rigging, scripting, fixing scripts that break every now and
> then due to api changes, animating my own shots, trying to build a
> pipeline that won't break, and actually trying to direct the project.
> The result of this is that I lose between an hour or more a day
> babysitting every rig change on every shot, and trying to get it to
> animators remotely. So you took 'annoying' (I agree, it is) and made it
> 'horrifically frustrating'
>>
>> 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).
> I'm agreed it should be fixed. Along with the dependency graph, various
> issues with libraries/linked data/proxying, and some other underlying
> problems of long standing. But the fact is, there's nobody working on it
> right now and it's unlikely to get fixed soon.
>>
>> But just sayin' that it's not a totally trivial change.
> It's not a trivial change, which is why it shouldn't have been made so
> trivially in the first place.
>>
>> --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
>