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

[Joshua Leung]

Hi,

Sorry for extra spamming, but I seem to have fixed all of the appending
issues. Patch has been updated accordingly.

Regards,
Joshua

On 5/19/07, Joshua Leung <aligorith at gmail.com> wrote:
>
> 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,464e815336371513515811!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070519/83e84f69/attachment-0001.htm