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

Nathan Vegdahl nathanvegdahl at gmail.com
Wed Oct 28 12:05:57 CET 2009


I'm sending this to Campbell too, since he's not on the animsys mailing list.

> 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.

    Fair enough.
    In that case, could we instead get an api function or operator
that sets the current mode:  bpy.ops.set_mode("POSE_MODE")
    Or something like that?  That way scripts can easily guarantee
that they are in the mode they need to be in.  Trying to toggle all
the modes to get things where you need them to be is kind of nasty
from a scripting standpoint.
    (Incidentally, this would also open up more possibilities for the
UI too, if people want to set hotkeys for setting modes rather than
toggling.  And it's also more robust from a macro standpoint.)

> 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...

    Well, the important point is just that things shouldn't fail
silently.  They should fail loudly and annoyingly.  Whether we do this
by making things read-only or through hiding the properties isn't so
important.  But failure should always throw an exception.  Otherwise
how is a script supposed to know that it failed at what it was trying
to do?

> 3)

    Ah, okies.  objects[n].data is things like mesh data, etc.  And
armatures (excepting pose channels) are like that too.  Makes sense.

> 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)

    Yeah, makes sense.  Scratch the request.

> 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,

    Fair enough.

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

    Convenience.  But it's not critical by any means.  Feel free to
ignore this one. :-)
    I can accomplish the same stuff through the bone's matrix.

> 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 :)

   Well, it's just that the ones that are actually called "head" and
"tail" don't seem to do anything, or at the very least aren't what I
expected from the names.  Intuitively I expected "head" and "tail" to
actually be what "armature_head" and "armature_tail" are (in fact, I
think I even complained to Campbell about them not working).
   So it actually ends up making it less clear, IMO, because it's not
what the user expects (though maybe I'm not so representative of a
typical user in this case).

   (Ultimately I think the real issue is just that armatures are way
more complex than they ought to be, even from just a normal user
standpoint.  IMO bones should be objects, and armatures shouldn't
exist.  But that's a discussion for another year...)

--Nathan V

On Wed, Oct 28, 2009 at 7:11 AM, Joshua Leung <aligorith at gmail.com> wrote:
> 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 ;)
>
>
> Joshua
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>



More information about the Bf-animsys mailing list