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

[Joshua Leung]

Hi,

I've been working on this as well, using joeedh's initial patch (from a few
days ago) as a base to work from. I had originally thought that joeedh had
stopped working on this, so I picked up the code.

What is presented in my version is a slightly cleaned up buttons layout, and
also a different approach to the custom-buttons/settings thing. The python
script is responsible for defining/getting/setting  the settings by using a
Draw.pupblock. That way, all of the clunky globals,etc. can be kept out of
the bPythonConstraint sdna struct.

I haven't checked on the state of library linking in this yet.

Patch and sample script(s) available from:
http://aligorith.googlepages.com/pyconstraints2

Regards,
Joshua

On 5/19/07, joe <joeedh at gmail.com> wrote:
>
> [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
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
> 
>
>
>


!DSPAM:18,464e813e36371630112793!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070519/0eb73705/attachment.htm