[Bf-animsys] Bones mirroring properties

Paolo Acampora palucam at gmail.com
Fri Nov 13 13:32:55 CET 2015


though using names we can avoid unwanted edits when mirroring, the problem
stays on copy/paste, so I think the conversation you started is indeed
worth attention. Having read-only properties to store values that only
should be generated might be a good idea

Paolo

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

On 13 November 2015 at 12:18, Juan Pablo Bouza <jpbouza at hotmail.com> wrote:

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


More information about the Bf-animsys mailing list