[Bf-python] Fwd: Pyconstraint patch
joeedh at gmail.com
Sat May 19 00:35:41 CEST 2007
I'd have to ask Ton. At the moment I don't think it'd work. It should
be possible to code it so it works, I think, but I'm not completely
familiar with how to do this. I'm not sure if anyone has ever needed
to library link Text buffers before, so I don't know if it works very
well :/ Of course you wouldn't append the text buffers manually, the
constraints inside the armature *should* do it for you.
I'll have a look at the library linking code and see if I can understand it.
On 5/18/07, Claudio malefico Andaur <malefico at manosdigitales.com> wrote:
> Would this work in proxy armatures ? I mean, linking a rig using
> pyconstraints into a new scene (blend file), and making a proxy of it
> would still have the same pyconstraint functionality working ?
> Regards and thanks in advance
> joe wrote:
> > [sent this twice, as the first one I sent to
> > bf-python at projects.blender.org, and I thing that's the wrong address]
> > Patch link:
> > http://joeedh.googlepages.com/pyconstraint.patch
> > This patch implements python-defined constraints.
> > Pyconstraints are python text buffers that begin with #BPYCONSTRAINT.
> > No loading of
> > external pyconstraints is supported (deliberately), the idea being
> > that forcing people to
> > include the constraints in the .blend is the best way to avoid
> > compatibility issues.
> > Pyconstraints must define 2 functions: doConstraint(inmatrix,
> > targetmatrix, idproperty) and
> > doDraw(x, y, idproperty).
> > For doConstraint, inmatrix is the owning object/posebone's world-space
> > matrix, and
> > targetmatrix is the world-space matrix of the target object/posebone.
> > doConstraint must
> > return a 4x4 Mathutils.Matrix() object, representing the new matrix
> > of the owning
> > object/posebone (in world space). Note that inmatrix and targetmatrix
> > are copies, so
> > modifying them won't affect anything.
> > doDraw is used to define the UI of the constraint. At the moment this
> > UI is placed in a
> > popup block, due to limitations of the interface code. doDraw works
> > exactly the same way
> > as if it were called with Draw.UIBlock(doDraw) (except that doDraw is
> > passed the x and y
> > coordinates to start at), and has the same rules/limitations.
> > Note that pyconstraints are handled in much the same way as normal
> > script with UIs; e.g.,
> > their global namespace dictionary is kept alive unless an error happens.
> > Several issues with scoping in the Draw module came up while I was
> > working on this,
> > which I solved. The most annoying one is no local copy of button
> > tooltips were made (in
> > violation of the python design guidelines, btw) which meant if you
> > didn't use a global string
> > variable for a tooltip, you could get garbarge or even a crash. Also
> > not putting the result of
> > Draw.String() in a global variable would cause garbage or a crash.
> > This issue turns out to be part of a bigger problem, where blender's
> > UI would internally hold
> > references to python objects without somehow increasing their
> > reference count. To solve
> > this, I modified the Draw.c code where each script area and each
> > pyconstraint instance
> > internally cache Button objects in a python list. This solves the
> > problem of having to place
> > each button in a global variable, and also allowed solving the
> > tooltip problem by copying
> > the tooltip from the python string to a 256-long char array in Button
> > (using strncpy of
> > course).
> > This allows for the following code form for pyconstraints:
> > def doDraw(x, y, idprop):
> > def callback(id, val):
> > if id == 0:
> > print val
> > idprop['bleh'] = val
> > if idprop.has_key('bleh')==0: idprop['bleh'] = ""
> > Draw.String("Bleh:", 0, x, y, 100, 22, idprop['bleh'], 32, "tooltip")
> > . . .which as you can see is very clear and compact.
> > One other small change I did was to extend Campbell's UIBlock code
> > changes to also work with pyconstraints (which only required adding
> > one small function, Set_UIBlock(), to Draw.c).
> > Due to time limitations and prior commitments with bmesh, I will not
> > have any more time till after summer for large changes to this patch.
> > If approved and committed, I can do maintenance work on it, fix bugs,
> > etc, but spending days rewriting it just because someone objects to
> > part of the design is definitely out. :)
> > Joe
> > _______________________________________________
> > Bf-python mailing list
> > Bf-python at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-python
> Bf-python mailing list
> Bf-python at blender.org
More information about the Bf-python