Maybe the solution is to have easy access to property flags, hopefully in the same UI where properties are created. We already have some *useful* flags like ['HIDDEN', 'SKIP_SAVE', 'ANIMATABLE'] but they can only be set on creation time from py. It makes more sense to to set them on the fly, here an 'SKIP_PROXY_REFRESH' (working tittle!) seems like the obvious way to go?
cheers Daniel Salazar 3Developer.com On Thu, Jun 30, 2011 at 4:38 PM, Nathan Vegdahl <[email protected]> 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
