Modular UI: driver namespaces and custom types

[PiOverFour]

In order for my cutout rigs to work, I need to add functions to the driver namespace, as well as register custom Blender types.

This PR enables both these possibilities. It doesn't change anything for the current rigs.

I don't know if it's too specific...

This PR is based on and includes #8.

[angavrilov]

About the bpy.types thing, I'm not sure how prudent adding that is, given that 2.8 actually removed non-UI non-builtin stuff from there:

https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Addons#Access_.28bpy.types.29

[PiOverFour]

I saw that, but I thought it only applied to new types, and not properties, e.g. bpy.types.Object.rigify_something = bpy.props.IntProperty().
I looked at the blender2.8 branch in addons, and it looks like it is still done this way.

I figured I'd wait for more add-ons to be updated to see how it's done, but I'd be glad to know if you have the answer.

[angavrilov]

Is that for properties? It's not obvious from the code what it's for - it's just "%s".

[PiOverFour]

Yes, for properties. My script looks like this:
[('Object.pantin_members', 'bpy.props.CollectionProperty(type=PantinMembers)')]

I don't really know how to make this more concise and readable, since properties can be registered in many bpy.types, and different props can be used, including PointerProperty and CollectionProperty which need to specify a property type.
I could at least rename ui_register_types to ui_register_props. Maybe add a comment:

# ui_register_props contains ('Type.name', 'TypeProperty()') tuples, e.g.:
# [('Object.my_prop', 'bpy.props.IntProperty()')]
ui_register_props = []

[angavrilov]

Yes, I think renaming would probably make the intended purpose clearer. With the original naming I thought you were adding your classes there for some reason.

Out of curiosity, what kind of driver functions are you adding?

[PiOverFour]

The cutout rigs are flat, all bones are on the same plane in rest mode. In order to Z sort them, I use a driver on each DEF bone's location, which depends on the Rig as well as individual bones, and a specified offset for those components. There is also a way to flip the whole character by rotating it 180° in the vertical axis, but then the Z sorting has to be inverted, so it's one of the function's arguments.
Having a driver function means I don't have to change the driver in each bone if I need to change the spacing between bones.

def z_index(member_index, flip, bone_index, extra_offset=0.0):
    """This bone changes sides when the rig is flipped (eg. limbs)"""
    if flip:
        return member_index * MEMBER_OFFSET - bone_index * BONE_OFFSET - extra_offset * MEMBER_OFFSET
    else:
        return member_index * MEMBER_OFFSET + bone_index * BONE_OFFSET + extra_offset * MEMBER_OFFSET

[angavrilov]

Btw, in 2.8 simple expressions in drivers are evaluated without Python, so expression drivers aren't nearly as slow.

What do you think about my utilities in #11?

[PiOverFour]

Oh yes, I saw the simple expressions. Great job on that!
One reason I used the driver function was to overcome the limited (256) number of characters in the expressions while still keeping them legible, but I guess it's not really needed.

About #11, this structure is much easier to understand and more logical, including your point about drivers: I can't think of a situation where it would make sense not to create them at the same time as the constraints. But then again I don't know the rigs' code inside and out.