Hi,<br><br>Sorry for extra spamming, but I seem to have fixed all of the appending issues. Patch has been updated accordingly.<br><br>Regards,<br>Joshua<br><br><div><span class="gmail_quote">On 5/19/07, <b class="gmail_sendername">
Joshua Leung</b> <<a href="mailto:aligorith@gmail.com">aligorith@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>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.<br>
<br>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.<br><br>I haven't checked on the state of library linking in this yet. <br><br>Patch and sample script(s) available from:
<br><a href="http://aligorith.googlepages.com/pyconstraints2" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://aligorith.googlepages.com/pyconstraints2</a><br><br>Regards,<br><span class="sg">
Joshua</span><div><span class="e" id="q_112a2996f299262d_2"><br><br><div><span class="gmail_quote">On 5/19/07, <b class="gmail_sendername">joe
</b> <<a href="mailto:joeedh@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">joeedh@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[Moving thread to bf-committers btw]
<br><br>Ok I added the code necessary for library linking, however it's not<br>working. I can't seem to figure out what's wrong; I call expand_doit<br>in all the right places and everything. When I lib link the armature,
<br>the armature doesn't seem to have the constraint applied. When I<br>proxy-afy the armature, it *does* then get the constraint applied, and<br>all seems to work. However, when I save and reload, the pyconstraint
<br>
script reference is set to NULL.<br><br>Its especially weird, because the pyconstraint Text buffer *is* being<br>lib-linked in; I can see it in the text editor menu.<br><br>Updated patch at <a href="http://joeedh.googlepages.com/pyconstraint.patch" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://joeedh.googlepages.com/pyconstraint.patch</a><br><br>On 5/18/07, joe <<a href="mailto:joeedh@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">joeedh@gmail.com</a>> wrote:<br>
> I'd have to ask Ton. At the moment I don't think it'd work. It should
<br>> be possible to code it so it works, I think, but I'm not completely<br>> familiar with how to do this. I'm not sure if anyone has ever needed<br>> to library link Text buffers before, so I don't know if it works very
<br>> well :/ Of course you wouldn't append the text buffers manually, the<br>> constraints inside the armature *should* do it for you.<br>><br>> I'll have a look at the library linking code and see if I can understand it.
<br>><br>> Joe<br>><br>> On 5/18/07, Claudio malefico Andaur <<a href="mailto:malefico@manosdigitales.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">malefico@manosdigitales.com
</a>> wrote:<br>> > Would this work in proxy armatures ? I mean, linking a rig using
<br>> > pyconstraints into a new scene (blend file), and making a proxy of it<br>> > would still have the same pyconstraint functionality working ?<br>> ><br>> > Regards and thanks in advance<br>> >
<br>> > malefico<br>> ><br>> ><br>> ><br>> > joe wrote:<br>> > > [sent this twice, as the first one I sent to<br>> > > <a href="mailto:bf-python@projects.blender.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
bf-python@projects.blender.org
</a>, and I thing that's the wrong address]<br>> > ><br>> > > Patch link:<br>> > ><br>> > > <a href="http://joeedh.googlepages.com/pyconstraint.patch" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://joeedh.googlepages.com/pyconstraint.patch
</a><br>> > ><br>> > > This patch implements python-defined constraints.<br>> > ><br>> > > Pyconstraints are python text buffers that begin with #BPYCONSTRAINT.<br>> > > No loading of
<br>> > > external pyconstraints is supported (deliberately), the idea being<br>> > > that forcing people to<br>> > > include the constraints in the .blend is the best way to avoid<br>> > > compatibility issues.
<br>> > ><br>> > > Pyconstraints must define 2 functions: doConstraint(inmatrix,<br>> > > targetmatrix, idproperty) and<br>> > > doDraw(x, y, idproperty).<br>> > ><br>> > > For doConstraint, inmatrix is the owning object/posebone's world-space
<br>> > > matrix, and<br>> > > targetmatrix is the world-space matrix of the target object/posebone.<br>> > > doConstraint must<br>> > > return a 4x4 Mathutils.Matrix() object, representing the new matrix
<br>> > > of the owning<br>> > > object/posebone (in world space). Note that inmatrix and targetmatrix<br>> > > are copies, so<br>> > > modifying them won't affect anything.<br>> > >
<br>> > > doDraw is used to define the UI of the constraint. At the moment this<br>> > > UI is placed in a<br>> > > popup block, due to limitations of the interface code. doDraw works<br>> > > exactly the same way
<br>> > > as if it were called with Draw.UIBlock(doDraw) (except that doDraw is<br>> > > passed the x and y<br>> > > coordinates to start at), and has the same rules/limitations.<br>> > >
<br>> > > Note that pyconstraints are handled in much the same way as normal<br>> > > script with UIs; e.g.,<br>> > > their global namespace dictionary is kept alive unless an error happens.<br>
> > ><br>> > > Several issues with scoping in the Draw module came up while I was<br>> > > working on this,<br>> > > which I solved. The most annoying one is no local copy of button<br>
> > > tooltips were made (in<br>> > > violation of the python design guidelines, btw) which meant if you<br>> > > didn't use a global string<br>> > > variable for a tooltip, you could get garbarge or even a crash. Also
<br>> > > not putting the result of<br>> > > Draw.String() in a global variable would cause garbage or a crash.<br>> > ><br>> > > This issue turns out to be part of a bigger problem, where blender's
<br>> > > UI would internally hold<br>> > > references to python objects without somehow increasing their<br>> > > reference count. To solve<br>> > > this, I modified the Draw.c code where each script area and each
<br>> > > pyconstraint instance<br>> > > internally cache Button objects in a python list. This solves the<br>> > > problem of having to place<br>> > > each button in a global variable, and also allowed solving the
<br>> > > tooltip problem by copying<br>> > > the tooltip from the python string to a 256-long char array in Button<br>> > > (using strncpy of<br>> > > course).<br>> > ><br>> > > This allows for the following code form for pyconstraints:
<br>> > ><br>> > > def doDraw(x, y, idprop):<br>> > > def callback(id, val):<br>> > > if id == 0:<br>> > > print val<br>> > > idprop['bleh'] = val
<br>> > > if idprop.has_key('bleh')==0: idprop['bleh'] = ""<br>> > > Draw.String("Bleh:", 0, x, y, 100, 22, idprop['bleh'], 32, "tooltip")<br>> > >
<br>> > > . . .which as you can see is very clear and compact.<br>> > ><br>> > > One other small change I did was to extend Campbell's UIBlock code<br>> > > changes to also work with pyconstraints (which only required adding
<br>> > > one small function, Set_UIBlock(), to Draw.c).<br>> > ><br>> > > Due to time limitations and prior commitments with bmesh, I will not<br>> > > have any more time till after summer for large changes to this patch.
<br>> > > If approved and committed, I can do maintenance work on it, fix bugs,<br>> > > etc, but spending days rewriting it just because someone objects to<br>> > > part of the design is definitely out. :)
<br>> > ><br>> > > Joe<br>> > ><br>> > ><br>> > ><br>> > ><br>> > > _______________________________________________<br>> > > Bf-python mailing list<br>
> > > <a href="mailto:Bf-python@blender.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Bf-python@blender.org</a><br>> > > <a href="http://lists.blender.org/mailman/listinfo/bf-python" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.blender.org/mailman/listinfo/bf-python</a><br>> > >
<br>> > ><br>> > ><br>> > ><br>> > ><br>> > ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> > _______________________________________________<br>
> > Bf-python mailing list
<br>> > <a href="mailto:Bf-python@blender.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Bf-python@blender.org</a><br>> > <a href="http://lists.blender.org/mailman/listinfo/bf-python" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.blender.org/mailman/listinfo/bf-python</a><br>> >
<br>> ><br>> ><br>> ><br>> ><br>><br><br><br><br><br>_______________________________________________<br>Bf-committers mailing list<br><a href="mailto:Bf-committers@blender.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Bf-committers@blender.org
</a><br><a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.blender.org/mailman/listinfo/bf-committers</a><br><br>
<br><br><br></blockquote></div><br>
</span></div></blockquote></div><br>
!DSPAM:18,464e815336371513515811!