[Bf-animsys] Bones mirroring properties

[Juan Pablo Bouza]

Yeah, I don't know, maybe Paolo is right, if this is used in other softwares and it is kind of a convention it might be just ok. Maybe it should be documented somewhere, I really had no idea Blender did this. So, I don't know if it is worth making things more complicated in the Blender code, I guess I should fix the namings of the properties.
In other words, that's why I started this conversation, if there are users using this feature, let's just keep it, I'll adapt to it :)


Date: Fri, 13 Nov 2015 10:44:21 +0000
From: palucam at gmail.com
To: bf-animsys at blender.org
Subject: Re: [Bf-animsys] Bones mirroring properties

Just adding my two cents, in my experience I've never seen this as a problem, and the standard practice (not just in blender but also in maya and any other software) is keeping the same name on properties which you wish to be mirrored, and using side prefix/suffix on the ones that should be left alone. I don't think blender is being too intrusive in trying to mirror these values, as while you can just avoid it with proper naming but there would be no way to make it happen if the software would just stop considering custom properties, leaving the users who need such behavior in the wild for no really good reasons. Also what is being proposed in the end is for blender to mangle with names internally, i.e. doing the most simple thing (proper naming), in the hardest possible way (hard coded values).

Cheers
Paolo Acampora, palucam at gmail.com
M +44 (0) 7474 009566
uk.linkedin.com/in/paoloac


On 13 November 2015 at 10:17, Sybren A. Stüvel <sybren at stuvel.eu> wrote:
On Friday 13 Nov 2015 17:07:55 Joshua Leung wrote:

> 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



I would never use the word "internal" for this. It implies a certain

perspective, a point of view from which you observe things. Does "internal"

mean "internal to Blender" or "internal to some addon"? In the former case an

addon developer shouldn't touch it/go there/read about it, whereas in the

latter it is extremely useful.



If I were to choose between a label "internal" and "external" I would even

suggest "external" for the use you describe, so there you have a nice example

of the term's subjectiveness.



>   B) Adopt an informal convention (similar to the "DEF_" and "GEO_"

> prefixes used already in many rigs) for tagging properties



This has the advantage that we don't need extra flags in the GUI. The downside

is that people have to know more by heart to make things work. That means it

needs to be documented well, and lots of things need to point to that

documentation in order for people to actually read it.



>   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



A designated namespace might be the best way to go. Let's not use dunder

names, though, as they have a very specific meaning in Python. Something like

"addon_settings" or "addon_data" would be fine I think.



Then there is the question of attribute vs. keyed access:



    bone.addon_settings.my_addon.my_internal_data_prop

    bone.addon_settings['my_addon'].my_internal_data_prop



Lots of data access in Blender works with keyed access for collections, so I

feel this might be a logical choice for this situation as well.



Cheers,

--

Sybren A. Stüvel



http://stuvelfoto.nl/

http://stuvel.eu/


_______________________________________________

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/b1750151/attachment.html>