[Bf-animsys] Bones mirroring properties

[Juan Pablo Bouza]

Hi Joshua! Ok, now that you pointed this out, I made a test and can confirm that the copy / paste pose tool is the one that does the thing.
PS: my rig is not more sophisticated than rigify, I'm a freaking caveman trying to write code! :D

From: aligorith at gmail.com
Date: Fri, 13 Nov 2015 17:07:55 +1300
To: bf-animsys at blender.org
Subject: Re: [Bf-animsys] Bones mirroring properties

I suspect the copy/paste pose tool is probably the one causing these issues. IIRC, last time I checked (and I didn't check the details carefully), from the API call name at least, I think it was just doing a simple copy over all the custom properties. All the other tools which do touch custom properties (e.g. propagate, breakdowner, etc.) don't try to do any mirroring magic, so should be fine.


At risk of derailing this thread (perhaps this should be in a new thread?), I'm aware that there have been problems where sometimes Blender's tools are operating on custom properties that shouldn't be touched. AFAIK, the problems here stem from the fact that custom properties are being used for 2 things in Blender:
1) Custom controls for artists/animators to manipulate (e.g. for controlling shape keys, or adjusting the behaviour of the controls)
2) Internal metadata, that gets used by addons/etc. to store their settings/data

Currently, all the pose tools that do things with bones end up assuming that all properties fall into the first category, since that's all there were initially (at least with rigify rigs from 2.5/6). However, with the rise of addons and more sophisticated rig systems such as blenrig, we're seeing that much more metadata is getting stored now, some of which really shouldn't be touched by the tools.

So, where to from here? We clearly need some way of distinguishing between the two cases. The question is how we should go about this:
  A) Add a flag of some sort that needs to be set when defining custom properties to say whether they're for "internal" use
  B) Adopt an informal convention (similar to the "DEF_" and "GEO_" prefixes used already in many rigs) for tagging properties
  C) Have all addons store their settings under a designated "__INTERNAL__" or "__SETTINGS__" namespace/property. So, instead of having
              pose.bones["Bone1"].my_addon.my_internal_data_prop, 
       we now have 
              pose.bones["Bone1"].__INTERNAL__.my_addon.my_internal_data_prop


Comments? Thoughts?

Regards,
Joshua






On Fri, Nov 13, 2015 at 4:37 PM, Juan Pablo Bouza <jpbouza at hotmail.com> wrote:



Hi guys! I stumbled across a small problem here, and I wanted to listen to everybody's thoughts before I ask someone to change this.
The thing is that Blender is kind of mirroring the data inside custom properties of bones.
For example, if I have bone called 'xx_L' and another one called 'xx_R', and both bones have a property that has the same exact name, Blender tries to mirror the data inside the property. 
In  my opinion, this shouldn't happen. For instance, I want to store  a list of bones inside the property, but in the bone 'xx_L', the list has all bones with the '_L' suffix, while in the 'xx_R' bone, the list has bones with '_R' suffix. Now, I don't know how or when, but some times Blender mirrors the property's content, so the list inside 'xx_L' is copied into the list of 'xx_R'. 
This shouldn't happen, mirroring the inner data of the properties is like too much for me. It becomes messy and unpredictable, and it breaks custom things you might want to store in the properties.
The solution for my case would be that the property shouldn't have the same name in 'xx_L' and 'xx_R'. So I know I can work it out, but I think this kind of mirroring attempt is way too intrusive, not to mention that the behavior is not too consistent, as the mirroring doesn't always occur.
Let me know what you think! 		 	   		  

_______________________________________________

Bf-animsys mailing list

Bf-animsys at blender.org

http://lists.blender.org/mailman/listinfo/bf-animsys





_______________________________________________
Bf-animsys mailing list
Bf-animsys at blender.org
http://lists.blender.org/mailman/listinfo/bf-animsys 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20151113/0631f356/attachment.html>