[Bf-animsys] Bones mirroring properties

[Joshua Leung]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20151113/014ae1fd/attachment.html>