[Bf-committers] [Bf-python] Fwd: Pyconstraint patch

[joe]

[Moving thread to bf-committers btw]

Ok I added the code necessary for library linking, however it's not
working.  I can't seem to figure out what's wrong; I call expand_doit
in all the right places and everything.  When I lib link the armature,
the armature doesn't seem to have the constraint applied.  When I
proxy-afy the armature, it *does* then get the constraint applied, and
all seems to work.  However, when I save and reload, the pyconstraint
script reference is set to NULL.

Its especially weird, because the pyconstraint Text buffer *is* being
lib-linked in; I can see it in the text editor menu.

Updated patch at http://joeedh.googlepages.com/pyconstraint.patch

On 5/18/07, joe <joeedh at gmail.com> wrote:
> 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.
>
> Joe
>
> 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
> >
> > malefico
> >
> >
> >
> > 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
> > http://lists.blender.org/mailman/listinfo/bf-python
> >
> > 
> >
> >
> >
>

!DSPAM:211,464e4a9736379047836120!