[Bf-animsys] Durian Requests Page - In response to 'Scripting' Section issues

Joshua Leung aligorith at gmail.com
Wed Oct 28 07:11:21 CET 2009

Hi Cessen,

I just thought I'd discuss/respond to the points you made under that
section, since there are a few issues there that need attention I think.

1) Unfortunately, this is hard to guarantee, since the types exposed via the
Python API directly correspond to the actual state of the data internally.
That is, there are 3 types of "bone entities" in Blender :
- Bone (Armature Data - Form optimised for evaluation + storage but tricky
for manipulating, and as such cannot be edited natively)
- EditBone (Intermediate form that is easier for creating + manipulating,
but which must be converted back to Bones to have any effect)
- Pose Channel (Poseable Bones - this is where all animation occurs, and
defines what I like to think of as a user/instance of the armature data)

For the first 2 forms, we might be able to get away with code that does not
implicitly assume either type of bone to exist. For that, perhaps we should
rely on the context iterators to deal with this for us. At least for
EditBones and PoseChannels, this is feasible, since I've defined a few
(involving combinations of selected, visible, editable) that are valid for
the 3D-View. (This brings up a gripe I have with the context iterators, in
that they usually only work in a single spacetype. This usually leads to
trouble with some rather generic things like selected objects, selected
bones not being available in the Properties Window, etc.)

Still, it'd probably be nice to be able to make this seem less disjointed...

2) Personally, I hate functions throwing exceptions. If making them read
only solves the problem, then great. Or perhaps just hiding all the invalid
types in certain modes will do will be sufficient. I have a feeling that
hiding the data may be the most effective way...

3) Datablock linkages. Bones/EditBones are Armature-block data, and armature
block data gets linked to an Object to have an Object that "is" an Armature
(erm... if this is confusing, just ask Ton about the whole datablock concept
;). If you removed this, you increase the potential for namespace conflicts
- there's probably something somewhere that will do it at some point

4) Getting back to my point about Pose Channels being like an
instance/window/user of the Bone data - you can in theory have more than one
rig using the same Armature block (though hardly anyone does for reasons
unknown). So, it's not that great to create such links IMO. However, links
the other way do exist (i.e. PoseChannel -> Bone)

5) Probably a resonable request, though something more general for getting
the ID-block at least may be nicer. I tend to think that it's probably
better to keep track of the way you got there, unless there is no way to
keep track of that (i.e. ask api function to get a bone, but where it got it
from you don't know exactly). But if it was something like nested structs,
then yes it would be convenient to do it, but we don't actually have that
data available to us when working with PointerRNA's in the background :/

6) Any reason not to just read it from the EditBones?

7) The tags in the names were really to make it "clearer" where in the
evaluation pipeline those values were used. Maybe we could drop them :)

8) Agreed.
9) Agreed again.
10) Strange... I thought this existed... maybe only in C then ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20091028/e556266c/attachment.html>

More information about the Bf-animsys mailing list