[Bf-taskforce25] PyConstraints V.2 - Proposal + Unresolved Issues

[Brecht Van Lommel]

Hi Joshua,

There's similar design decisions to be made in the future for nodes,
modifiers, etc, would be good to have a consistent design for this.

There's two use cases, one is writing constraints that look just like
regular ones, i.e. that are always available and can show up in the add
constraint menu. The other is writing constraints for a specific rig, to
be bundled with the .blend file. The same thing goes for nodes.

Pynodes and pyconstraints currently cover the second use case, but it
would be good to take the first one into account too even if it doesn't
get implemented immediately. Ideally you could handle these two use
cases with nearly the same code, with the same subclassing and
callbacks, so you can convert a pyconstraint you wrote for one rig into
a plugin you can always get available or distribute.

On Mon, 2009-07-27 at 00:38 +1200, Joshua Leung wrote:
> However, I think it is important to still maintain a few other
> characteristics
> - constraint instances still must reference text buffers/datablocks
> instead of some magical global list that is maintained at startup...
> The main benefit here is that in productions where multiple versions
> of the constraints may be used, you don't need to register all the
> pyconstraints for every machine that you work on, leading to problems
> with version control...
> - keeping the text buffers, we can also easily edit the scripts and
> test without having to click on too many 'refresh' buttons

Yes, I agree with this.

> The example above is incomplete in some ways though. Notably, there
> needs to be some way of checking for (and initialising) missing but
> required custom properties - probably a initSettings() call that
> checks if a setting exists already (creating a new prop if
> non-existant) that gets called at certain points? Getting this feature
> working is currently dependent on having bpy/RNA methods available for
> doing this (TODO #1)

RNA properties have default values, so perhaps no initialization is
needed in many cases. But some callback for this is possible of course.
We are still missing some code to do the same as you can do now with
python operators, adding own RNA properties __props__ (python operators
are not using generic RNA register functions yet).

> Technical issues 
> - supposing that we compiled scripts containing such code, how would
> we go about executing the constraints that are defined in this way?
> How are changes such as number of targets going to cause changes?

I think this can work just like render engines do now. They don't keep a
compiled script, but a reference to the python class. I think the RNA
register system is suitable for this.

Instead of e.g. RenderEngine/RenderEngineType, you can add
bPythonConstraintType to go along with bPythonConstraint.
bPythonConstraintType then contains C callback and ExtensionRNA, and
further you could just to the same thing as is happening in
rna_render.c. The difference being that you don't store the types
permanently in a global list, but temporarily in bPythonConstraint.

There's some docs on this here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNATypeRegistration

One issue I'm not sure about is how to get the bPythonConstraint pointer
in the register function, probably need some global in the python code
to pass to the register function.

Brecht.