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 <[email protected]> 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 [email protected] 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 >> <[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 >> > > _______________________________________________ > 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
