The script will create a set of box props for selected vertices, then adjust a selected morph's deltas as the boxes are dragged or translated.

Here's how it works:

1)  Zero all rotations for the actor on which the script will be used.  If rotations aren't zeroed, you'll get offsets between the boxes and the corresponding vertices.  (If anyone knows the matrix math to overcome this, please tell me how to do it!)

2)  Zero all morphs which you don't want to include in the new morph target.

3)  Press "create selection box" to create a bounding box.  Creation and deletion of the vertex boxes can be slow, and Poser may lag or lock up if too many are in the scene.  So you need to isolate an area of the mesh by positioning the bounding box.  Any vertices on the destination actor which fall within the bounding box will have vertex boxes created.  Meshes with a higher density may work better with smaller bounding box areas.

4)  The vertex selection can be screened further by materials.  To use this option, check the "screen materials" checkbutton.

5)  Indicate the name of the morph which will be affected.  If the named morph does not exist, it will be created.  If it does exist, you will edit the deltas of that morph directly.  Newly created morphs will inherit include the deltas of any morphs which aren't zeroed when the script is run, making it easy to edit a copy of a morph.

6)  Select the actor you want to affect and press the "start morphing" button.  If you've selected materials screening, you can now select which materials to include in or exclude from the selection.  If vertex boxes already exist for the actor, they will be used in the run.  If they don't exist, the script will now create them. 

7)  Now you can position the vertex boxes using the parameter dials or by dragging them in the 3D view.  The corresponding vertices will move with the boxes, setting the deltas in real time for the morph which is being edited.  This is accomplished using a worldspace callback loop.

8)  You can end the callback loop at any time by pressing "end callback loop".

9)  The vertex boxes can be deleted by pressing "delete boxes".

10)  Press "quit" to exit the script.  If you exit by pressing the "x" in the corner of the gui, the callback loop may be left running when the script exits.  (Again, if anyone has hints about overcoming this, let me know....)

That's it.  The vertex box sizes should vary depending on the overall density of the mesh, hopefully making it easier to see what you're doing when the polygons are quite small.  Box creation and deletion can be slow, as I said, so be careful and/or patient.  The script will not run unless there is a selection bounding box positioned for the destination actor.  And the rotations need to be zeroed.  Many limitations.

But it works nicely in my tests, otherwise.  I'm curious about how close this sort of functionality comes to the Poser 7 morphing tool.  I only have P5, so I don't know if I'm recreating a wheel, here.  I'm trying to work out somthing sort of like the Wings "tweak" tool with this, or like what I expected the morph putty tool to be in Poser 5.

If anyone has any problems, questions, comments (or suggestions for fixing the things I mention above) let me know.

Quote - If you've selected materials screening, you can now select which materials to include in or exclude from the selection.  ... I'm curious about how close this sort of functionality comes to the Poser 7 morphing tool.

Being able to filter by material groups sounds useful, and Poser 7's morph tool cannot do this; you can choose to show only the selected actor, which is useful also but not as flexible as being able to filter material groups within an actor.

Can your script span a morph across multiple actors?  It sounds like not.  That would be a huge plus, although if it can't then I don't expect it would be worth your time to try to build in.  The P7 morph brush can only affect one actor at a time, and EF has stated that as far as they are concerned, it isn't feasible for them to try to make the tool span morphs across multiple actors, which is a shame.  

Stability and performance while using the P7 morphing tool are very good.  The parameters the tool offers:
General parameters:
Radius
"Strength" (not quite the right name but basically how much mouse movement is translated into how much pull/push/smooth in one operation)
Relative to Surface
Relative to Screen

Brush shapes:
Single point
Small, high-intensity center with large low-intensity outer falloff
Large, high-intensity center with small low-intensity outer falloff
Solid circle with 100% -> 0% edge (no smooth falloff)

Operations:
Push
Pull
Smooth
Restore (revert what's under the brush to un-morphed state)

Neat concept, I had no idea this kind of thing could be done strictly with PoserPython.

cool - this looks like a very interesting tool !! can't wait to test it :)
Many thanks.
[BTW: I am watching the other thread at the technical forum for a while.
allthough I only understand 1% of what is said there. but I am very interested.
I hope - one day - it will be possible to transfer a beautiful face shape from
V3 to Posetta ...]

*"Can your script span a morph across multiple actors?  It sounds like not.  That would be a huge plus, although if it can't then I don't expect it would be worth your time to try to build in.  The P7 morph brush can only affect one actor at a time, and EF has stated that as far as they are concerned, it isn't feasible for them to try to make the tool span morphs across multiple actors, which is a shame."

*Hmm.  I could check the actors which are welded to the current actor, to see if any of them lie within the bounding box.  I'll have to think about that.  I have some of the basic code in place for TDMT....  The trick would be identifying which actor has been tweaked, to set the correct morph.  It seems like this wouldn't be too difficult.  Easier than trying to split UV seams....  :-P

Basically, it sounds like this isn't so much like the P7 morphing tool at all.  A different and more limited creature, this.  Perhaps dragging or translating the vertex boxes may allow more control than using a brush, I don't know.  I assume the P7 tool may be sort of like Amorphium, with a bit more control.  

*"Neat concept, I had no idea this kind of thing could be done strictly with PoserPython."

*It does have limitations, but it also does real-time deformations.  The trick to that seems to be parenting the vertex boxes to the destination actor, so the worldspace callback loop updates more readily.  But parenting means troubles with offsets and inherited rotations.  I'm sure this sort of thing can be done even more effectively, but I lack the math....

*"cool - this looks like a very interesting tool !! can't wait to test it :)"

*Let me know if your tests reveal any new possibilites or shortcomings.  This is kind of a quickie spin-off script, but I'd like to refine it where it may be useful to do so.

Hi. This is nothing like the P7 tool. I have very much wanted something like this for doing things like fine changes on the lip edges, eyelid edges, or nose openings. Thank you so much!

*"Hi. This is nothing like the P7 tool. I have very much wanted something like this for doing things like fine changes on the lip edges, eyelid edges, or nose openings. Thank you so much!"

*I'm kind of wondering how well it might work for creating JCM correction morphs for bad bends in areas like, say, the Buttocks, where that ugly fold develops.  I haven't tested the idea, however, so there may be troubles with the bend zones.  And, actually, you'd suffer from vertex box offsets due to the rotation of the destination actor when you bent it to be able to see what you need to correct.  Hmm.  The rotation issue is really a problem.  If anyone has any idea how to subtract the parent's rotation matrix and return the corrected vertex box positions, this script could be greatly improved.  All the code samples I've seen are for Blender armature bones, and they only return the child rotations after the parent is factored out.  I'm sure it's a similar problem, but I'm not sure how to adapt the overall idea for this case....

I hope the script is helpful. 

You should use this script in frame 1 of your document.  Because it parents the vertex boxes, you can end up with odd results if the script is applied in any frame other than the first frame of an animation, because the re-positioning into the parent's localspace will be based on the parent's position in frame 1, not the current frame.  This seems consistent with Poser's normal parenting behavior, so it doesn't seem to be anything Python can readily work around.

This is a small update which adds the ability to create a blank morph target rather than one which includes the delta positions from all the currently set morphs.  This is useful if you want to edit the shape which results from having several morphs set together, but you don't want to have the combined result embedded in the correction morph.  It also corrects a potential problem with selection box naming, thereby opening up the possibility of having multiple selection boxes in use at one time.  Selection boxes can be set up symmetrically (on a symmetrical actor) using the same methods for mirroring magnets.

I've also started setting up the basics for multiple actor support.  It looks like it should work.

What about creating a copy of the currently selected actor including his welded parents and working on this "static geometry" first? After hitting a Button "make permanent" the difference between the static geometry and what is actually there is computed (deltas). This differences are now the morph parameters that must be attach to the original actor(s).

Or I'm completly wrong with this way?

*"What about creating a copy of the currently selected actor including his welded parents and working on this "static geometry" first? After hitting a Button "make permanent" the difference between the static geometry and what is actually there is computed (deltas). This differences are now the morph parameters that must be attach to the original actor(s).

Or I'm completly wrong with this way?"

*You mean as a way of factoring out the parent actor's transforms, right?  A copy of the geometry would have zeroed transforms.  Hmm.  I'm not sure whether that would be more efficient than trying to subtract the rotations, or not.  I think I may be able to remove the rotation offsets by keeping track of the pre-parented box locations and comparing those to the post-parented offsets which are used to create the deltas.  I'll try making a copy geometry if that doesn't pan out....  

Or are you suggesting that as a script feature?  The benefit might be that the deltas would not be made permanent until the button was pressed.  That outcome can be had by working with a blank morph or a copy of a morph and simply deleting undesirable results....

Hmm.

Thank you.  I'll think about that.

Thank you.

mybookmark

There are still some limitations, although fewer than before.

1)  Vertex selections should still be minimized using the bounding boxes.  Too many vertex boxes can lock up Poser.  On my system, too many is all of the verts in Posette's head's skin material.  That may amount to just the nose on V4, for all I know, so be careful.  Test the script before you fully trust it.  Learn its limitations on your own system.  Back up your Poser file before running the script, at least until you have some sense of how far you can take it.  Better systems than mine can presumably handle more boxes in a scene, and P7 may be more capable in this regard than P5.

2)  There are some bad interactions between the worldspace callback loop and the changing of frames.  Changing animation frames while the script is running has caused problems in my tests, but I'm not yet sure why (the callback loop prevents PoserPython from printing out the error messages).  As such, I've disabled the callback loop except in the frame in which it is initialized.  So it will simply do nothing right now if you switch frames.  It might be nice to be able to animate this script's effects, so I'm going to try to fix this if I can.

3)  The selection bounding boxes can be scaled and translated, but rotating them will not change your vertex selection.  This is due to the rather simple in-bounds check which is in use.

The overall process can be simplified and expanded now, with some of the updated changes.  You no longer need to zero the figure or do any prep-work beyond deciding in which frame to work and which morphs to zero before starting.  If you use the "blank morph" option, you can create a correction morph which can be used with any morph or combination of morphs on the actor.  You can now create morphs which span body parts, although this should probably be done in parts, bearing in mind the warnings above about the size of the vertex selection.  Now that the rotation offset problem is solved, this could (hopefully - I haven't tested to see how this interacts with bend zones...) be used to create JCM bending correction morphs.  Kind of neat.

Tried it in P7 SR1. Recieved the following errow when trying to create the bounding box. Exception in Tkinter callback Traceback (most recent call last): File "H:PoserRuntimePythonliblib-tkTkinter.py", line 1345, in call return self.func(*args) File "H:PoserRuntimePythonposerScriptsScriptsMenuVert Boxes Morphing Utilityvertboxes6e.py", line 744, in okay_select self.verts1 = vertexPos(app.a1.Geometry()) File "H:PoserRuntimePythonposerScriptsScriptsMenuVert Boxes Morphing Utilityvertboxes6e.py", line 164, in vertexPos verts = Numeric.array(verts,Numeric.Float) NameError: global name 'Numeric' is not defined

Cage,

This looks really interesting, though the complexities of Python are beyond me. ;-))
It got me thinking laterally, would it be possible to create a version of your script which locks the selected vertices in place (or remembers and resets their coordinates) ? This would I think be very useful in adapting existing morphs which move vertices which you would prefer stayed put. For example an Elven face morph which includes altering the ears shape,. if it was possible to 'lock' the position of the ear vertices with a modified version of your script, could produce  an attractive human face.

Cheers

Ian

@bwldrd:
Open the script with a texteditor and insert the line

import Numeric

P7 does not include Numeric automatically.

import Numeric. Ok, did that, now as making the nodes, poser locks up and crashes :( Guess fate is telling me I'm not supposed to use the script. Hehe. :D

*"import Numeric. Ok, did that, now as making the nodes, poser locks up and crashes :(

Guess fate is telling me I'm not supposed to use the script. Hehe. :D"

*Oh, dang.  I completely forgot about P7 and Numeric.  I'll add that.  What are you doing when it crashes?  How does it crash?  Creating the boxes may take several minutes, depending on the size of your selection.  If I try to do anything with Poser or the script GUI during the box creation/deletion loops on my system, Poser gives all the indications of having frozen up - but waiting a few minutes for the loop to finish running usually reveals that everything was fine and I was merely impatient.  :-P  Reducing the size of your vertex selection may help.  Anything you can tell me about the symptoms of your probelm may help me correct it....

*"For example an Elven face morph which includes altering the ears shape,. if it was possible to 'lock' the position of the ear vertices with a modified version of your script, could produce  an attractive human face."

*Ockham has a couple of script which can remove deltas from a morph based on group assignment, and TDMT has a similar feature which removes deltas using the same bounding box and materials selection/screening methods used in this script.  I assume that sort of functionality is what you want.  In this case, vertices are selected when a box is created for them and positioned based on the boxes' positions.  "Locking" a vert in the context of this script involves either screening it out of the box creation process or not moving the box once it exists.

Here's the link to the latest version of TDMT, which has morph trimming and smoothing....  

http://www.kuroyumes-developmentzone.com/~Cage/TDMT/TDMT_module_v1.zip

If a new box is created, the callback event is generated. This slows down anything.

I did the following: Wenn the start button is pressed, callbacks are disabled. If anything is set up, callbacks are re-enabled.

Using the standard Tk-mainloop from within Poser should be avoided for scripts like this.
Better use an infinitive loop and call poser.Scene().ProcessSomeEvents() from your script. This keeps Poser living without loosing control. If your script is very busy, don't let Poser do something. If you don't, Poser needs a lot of time to check if anything is changed in the meantime, including screen-refreshs.

Basically:

class PoserApp(Toplevel) :<br></br><br></br>    def __init__(self, master) :<br></br>        Toplevel.init(self, master)<br></br>        self.verybusy = False<br></br>        self.stopped = False<br></br><br></br>    def mainloop(self) :<br></br>        while not self.stopped :<br></br>            if not self.verybusy :<br></br>                poser.Scene().ProcessSomeEvents(10)<br></br><br></br>            self.update()<br></br><br></br>class MyApp(PoserApp) :<br></br>...<br></br>

From your app set self.verybusy = True to stop Poser. As a side effect, nobody is able to delete something your script needs to work with as long as self.verybusy is True ;)

What are you doing when it crashes? Watching it make the vertex point boxes. Looks like it finishes making them then poser just freezes. How does it crash? Poser just freezes. I'm using vista (which could be the problem but so far all my other scripts are working.. E.g. Wardrobe Wizard, Light Probe, etc.) and normally I get a popup asking to wait for the program to finish or to close it if a program is taking a long response time. But not with this. It just flat out crashes telling me "Poser executeable has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."

Verified. P7 crashes. P6 works.

Seems that P7 has some memory issues. It also crashes silently here if I use the clothroom with a complicated set.

*"If a new box is created, the callback event is generated. This slows down anything.

I did the following: Wenn the start button is pressed, callbacks are disabled. If anything is set up, callbacks are re-enabled.

Using the standard Tk-mainloop from within Poser should be avoided for scripts like this.
Better use an infinitive loop and call poser.Scene().ProcessSomeEvents() from your script. This keeps Poser living without loosing control. If your script is very busy, don't let Poser do something. If you don't, Poser needs a lot of time to check if anything is changed in the meantime, including screen-refreshs."

*I'm afraid some of your terminology is over my head.  What is an infinitve loop?  There is a function in the GUI to allow Poser to process events.  It's probably not well implemented, but it's the best I've been able to come up with, lacking any good examples.  I'll see what I can come up with, however.  If you can maybe clarify any of what you suggest, it would help....  Sorry I'm kind of slow.  I'm learning Python as I go and your ideas are new to me.

And Poser 7 has problems with it.  Dang.  Any idea what part of the process could be causing the Poser 7 issues?  Hmm.

Quote - And Poser 7 has problems with it.  Dang.  Any idea what part of the process could be causing the Poser 7 issues?

What sort of problems are your experiencing ?

*"What sort of problems are your experiencing ?"

*ADP and bwldrd seem to have independently verified that there are problems with Poser 7.  See their posts, above.  I only have P5, unfortunately, so I can't test to see what's going on.

I've tried setting up the ersatz mainloop suggested by ADP, but it not only locked up Poser, it forced me to reboot my system.  I don't think I know enough about Python and Tkinter to implement the approach.  I've studied the ADP Poser Console script, but succeeded only in getting rather confused.  :-P  Moreover, I can't seem to get the Poser Console itself to run in P5.  Hmm.  Unless the use of tk.mainloop() is actually causing the script to fail, I'm going to consider this issue outside the scope of my involvement with this effort.  Anyone with more sophisticated coding skills should feel free to alter/revise/improve/build upon the posted script.  I'll be happy to hand the project over to someone more capable, or welcome anyone's contributions to helping make a better tool for Poser.

In the meantime, I note that the last posted version has offset issues with actor scaling.  I'm trying to see what I can do about that.

Well, as usual, I got excited with limited results, stopped testing too early, and posted incorrect assumptions with the last version.  It looks like scaling affects the process, creating mis-positioned boxes.  And creating boxes to correct bend zones can't really work because the actors need to be zeroed when the boxes are created, to keep the local displacement delta offsets correct.  So rotations work with props, but not with bend zones on body parts.  And actors need to be scaled to 100% when working with the script, or the vertex boxes aren't properly aligned with the corresponding vertices.

These problems relate to parenting, and I'm still confused by some of the effects of parenting the boxes, particularly with the scaling.  So far, I don't see any way of working out the problems.  And I note that PoserPython's scripted parenting doesn't seem complete.  Normally, a prop parented to a figure will be deleted with that figure.  That doesn't seem to happen when parenting via Python.  Similar problems seem to exist with the "inherit bends" option for parenting with Python.  It doesn't seem to work.  Hmm.  

I'm not sure how many of these problems I may be able to overcome.  Frustrating and disappointing.  My apologies.  This isn't as nifty or as useful as I believed at first.  :(

It's not your fault Cage.

The work you and Spanki are doing is nothing short of phenomenal. Who would have thought it would be possible to swap morphs and UV's between different meshes in Poser with just a few mouseclicks a few months ago ?

As for Poser 7, I've yet have to find a Python script that this "%$§*# software doesn't brake.
Not even a rather simple script like the magnet mirror works correctly.

That's why for figure creation I still keep Poser PP and P5 installed.
They might be primitive, but at least they work.

*"The work you and Spanki are doing is nothing short of phenomenal. Who would have thought it would be possible to swap morphs and UV's between different meshes in Poser with just a few mouseclicks a few months ago ?"

*Well, that's kind of a limited success, too.  But thank you.  The UV transfer isn't useful yet because I can't work out how to split the target mesh seams effectively.  And morph transfer is only partially successful - I have yet to get a good head correlation including eyelashes on any two meshes that aren't identical.  The frustrating thing about the script in this thread is that I hoped some of the functions might be the foundation of a method to tweak and correct the mesh correlations by defining new raycasting directions for certain verts (Spanki would absoultely hate that idea, mind you...).  But if it doesn't work at all in Poser 7, I hesitate to introduce the approach into TDMT.

I think a lot of this can be made to work, and more efficiently than in my limited implementations, if approached by a coder who grasps the math involved.  I'm kind of stuck with gimmicky workarounds for a lot of things.

Ah, well.  I'll keep at it. 

Hmm, I wouldn't call a fully functional reduced resolution version of MIKI that weights less than half than the original "limited
 success".

She wouldn't have been possible without your scripts !

:thumbupboth:

Nice one.  :)  I should have clarified and said that the success is limited to certain contexts, so far: situations where the mesh shapes are identical, whether the vertex structures match or not.  The process doesn't quite seem to be fully there yet for meshes with dissimilar shapes are well as vertex counts.

The thing with the eyelashes really kind of drives me nutso.  :-P  Have you ever had any success with heads when both meshes don't have the same shape?  You may have tested the morph transfer more thoroughly than anyone, thus far....

I'm dragging my own thread OT.  Heh.

I know what you mean, but please don't underestimte the importance of beeing able to go from a highrez mesh to a lowres one.
The current mainstream Poser meshes are ridicoulusly polygon heavy, and your's is the only effective method to reduce the meshes while still keeping full morphing functionality.

The most "different" meshes I used were V3 and V4, and morph transfer between them worked quite well.
I was able to transfer all V4 expression morphs over to V3RR with only a bit of manual cleaning.

I haven't tried more extreme pairings yet, because if I'd ever need let's say the MilDog's head on M3's body I guess I would do just a head swap.

BTW, even if your UV-swapping would only work for single bodyparts (like a head), this would open up a lot of possibilities for hybrids:

Like a V3 head on a V4's body that uses all V4 mapping, or a "V4toV3" with a real morphing V3 body that uses V3 textures !

So please keep up the good work, but don't underestimate what you both have already achieved.

Quote - I know what you mean, but please don't underestimte the importance of beeing able to go from a highrez mesh to a lowres one.
The current mainstream Poser meshes are ridicoulusly polygon heavy, and your's is the only effective method to reduce the meshes while still keeping full morphing functionality.

The most "different" meshes I used were V3 and V4, and morph transfer between them worked quite well.
I was able to transfer all V4 expression morphs over to V3RR with only a bit of manual cleaning.

I haven't tried more extreme pairings yet, because if I'd ever need let's say the MilDog's head on M3's body I guess I would do just a head swap.

BTW, even if your UV-swapping would only work for single bodyparts (like a head), this would open up a lot of possibilities for hybrids:

Like a V3 head on a V4's body that uses all V4 mapping, or a "V4toV3" with a real morphing V3 body that uses V3 textures !

So please keep up the good work, but don't underestimate what you both have already achieved.

Sorry but I can't help but ask. Is that the script called "geom_test4g.doc" and is the one in your picture the V3 or is it V4?

I reduced MIKI-1's head by manually deleting vertices in a modeller while the body was reduced in Polytrans.
Then I used Cage's geom_test script to transfer the expression morphs from regular MIKI-1 to my reduced resolution version.
(I think I used even an earlier version than "geom_test4g.doc", but the later versions of course work faster and even more precisely.)

Any of the old WIP morph transfer scripts named "geom test" or "test geom" have been replaced by TDMT.

http://www.kuroyumes-developmentzone.com/~Cage/TDMT/TDMT_module_v1.zip

*"BTW, even if your UV-swapping would only work for single bodyparts (like a head), this would open up a lot of possibilities for hybrids:"

*If the seams can be split correctly, the process should be useful for any body part.  If It gets that far, I'll try to work out transfer using the unimesh geometry for the full figure.  But the seams aren't splitting well yet, unfortunately....

@cage:
If you want I can spend a few days deceloping a kind of Framework and a Userinterface for scripts like yours next week. With this you can concentrate on the "real important" parts :)

I just tested my Poser Console with P5: works for me. This little tool is of great help while developing interfaces because Poser has no chance to hold or hide script output :)

bookmark

*"I just tested my Poser Console with P5: works for me. This little tool is of great help while developing interfaces because Poser has no chance to hold or hide script output :)"

*I don't mean to suggest that it has flaws - just that I can't seem to get any of it to work enough for me to test any implementation.  I get terribly frustrated with my own limitations and stupidity.  :(  

*"If you want I can spend a few days deceloping a kind of Framework and a Userinterface for scripts like yours next week. With this you can concentrate on the "real important" parts :)"

I would - and others undoubtedly would - appreciate that!  It might be a boon for the community.  But don't waste your time on something just because I kind of freaked out a little yesterday.  And, ah, it's less a matter of concentrating on the "important" parts than it is concentrating on the things I can understand.  :-P  I can grasp the basics of what you're doing, but somewhere in the middle your process becomes too complex for me or integrates too many new ideas for me to get it.  :(  I was kind of wondering if a disagreement between tk.mainloop() and the callback loop might be what crashes P7.  I believe Spanki was testing for TDMT using P7, and we were using the same box creation code in that as I'm using for the vertex boxes.  Or the crash may be due to the parenting step.  Hmm.

If anyone can test this is Poser 7 and try cancelling out a couple of lines of the script, to see what happens, that might help isolate the problem.  I can point out which lines to test, in the last posted version if anyone can spare a bit of time for such a test.

Event driven programs in a multithreaded/multitasking environment tend to end in a deadlock somewhere :)

Something similar can happen with Poser and Python. Poser starts your scripts (better: asks Python to execute your script). Under normal circumstances Poser holds anything until your script ends. But if your script starts Tkinter, you give control back to Poser. If something is changed, Poser may report this to your script (Callback Events). If you like to live with risk, you may call "ProcessSomeEvents()", handing control back to Poser. Poser may generate the same event another time, before the first call became a chance to end.

Another nice way is this: To make a dialog stay on top, some people are using a timer interrupt to get control back. If only the screen is updated, anything may work fine. If callbacks are used there is a great chance to end in a crash (sooner or later).

Uncountable similar scenarios are possible and I would be able to declare most of them - but not in english, sorry :)
Errors caused through wrong event driven programming concepts are often hard to find. Because such an error may not occure if your testmachine runs faster (because you have more RAM, no other apps running at the same time, you BS does mutitasking smoother, or while it is cloudy weather).

I think you are right with:
I was kind of wondering if a disagreement between tk.mainloop() and the callback loop might be what crashes P7

And I think the problem is not the tk.mainloop/callback, but the wrong handling of this :)

Ok, a framework for Poser Python scripts is a bit longer on my To-Do list now. Some sort of infrastructure any script may use. With this it would be possible to run several different scripts at the same time. And writing scripts for Poser would be a lot easier.

*"Ok, a framework for Poser Python scripts is a bit longer on my To-Do list now. Some sort of infrastructure any script may use."

*Thank you.  Even if this current script doesn't work out, what you have planned will benefit everyone.  :)

I think I may have found a problem that could be causing the P7 crash.  The indentation on the line which actually sets the deltas is incorrect, so it may be called in cases where one of the variables on which it depends hasn't been defined.  I hadn't noticed this in my tests, because it's set up in a try-except case, so when it errors due to the bad structure, it simply skips over it.  But P7 has a different version of Python and it may have different exception handling, so I suspect this may be the cause of the crashing.  I hope.

But the parenting offset problems continue to confound me.  Among other troubles, WorldVertex coords can't be used as a point of reference to set deltas within the callback loop.  Trying this causes bizarre fluctuations of the delta position.  Weird.

"But P7 has a different version of Python and it may have different exception handling, so I suspect this may be the cause of the crashing.  I hope."

Nope. Exception handling works perfectly well. There are not mutch known errors in Python that could bring your script in trouble. But, it is a bad idea to have a try/exception that is very often executed. For any entry into this block Python has to generate debugging code etc. Python is an interpreter, not a compiler.

Among other troubles, WorldVertex coords can't be used as a point of reference to set deltas within the callback loop.  Trying this causes bizarre fluctuations of the delta position.  Weird.

Perhaps this is one of this nice things I described above. Changing something inside a callback function shouldn't generate another callback! Perhaps this is the case in your script.

Maybe I find the time to look a bit deeper inside your script tomorrow, surely monday.

*Well, bummer.  It was a definite error, at any rate.  The try-except within the callback seems to be common practice.  It's used in the various sample scripts for Poser callbacks which I was able to locate.  I think it may be done to prevent Poser Python from trying to print out any errors - the callback seems to break the print functions, and you just get a blank console popping up.

*"Changing something inside a callback function shouldn't generate another callback!"

*Interesting.  I seem to be confused, then, about what is and what isn't a callback.  I'm generally confused about a lot of things at any given moment....

*"Maybe I find the time to look a bit deeper inside your script tomorrow, surely monday."

*Ahh...   if you really want to.  Prepare yourself for spaghetti!  :-P  I don't write code on your level, understand.  I'm sure you could maybe get a good laugh from it, anyway.  :)  But any assistance or pointers could only improve the script.

*"Another nice way is this: To make a dialog stay on top, some people are using a timer interrupt to get control back. If only the screen is updated, anything may work fine. If callbacks are used there is a great chance to end in a crash (sooner or later). "

*That's kind of the method currently in use.  It works, mostly, but I have had some lockups and I do see evidence that it may not be the best way....  Perhaps that is ultimately the cause of the lockups from too many vertex boxes?  Hmm, hmm.

This update fixes the Numeric omission and the incorrect line in the callback loop.  Beyond that, it only makes minor, behind-the-scenes tweaks.  I spent two days trying to get the methods to cooperate with scaling and rotation of body parts and ultimately ended up realizing that the code I'd posted previously was the best of my various efforts so far.  It looks like all the body part scaling and rotation issues are due to interactions with joint parameters.  In the body part bend and scaling zones, you will end up with mis-positioned vertex boxes if your actor is bent or scaled.  This seems unavaoidable, short of switching to some method which works with props or proxy figures somehow.  The script can be used when you have scaled or rotated body parts, if you can work with the box offsets. 

Still crashing in P7 SR1. From what I can tell, same as before.

*"Still crashing in P7 SR1. From what I can tell, same as before."

*Thank you.  I guess that's not unexpected.  :(  It looks like ADP's idea about altering the way the gui runs its update loop may be the only hope for getting this to go with P7.  If that fails, the earlier conclusion that this is simply one of the memory problems associated with P7, like the continuing clothroom crashes, would seem to cover the situation.  I hope that isn't the case.

This does not parent the boxes, so they won't move along with the affected part.  A new button has been added to place the vertex boxes in the current position for the corresponding vertices.  That works nicely, and without parenting the script doesn't need to do all of the figure or actor zeroing at the outset.

However, this one suffers from the positional offsets with target actor rotation which beset the first posted version of the script.  In addition, deforming a figure (possibly applying deformations while any figure is in the scene) breaks body part welds - or at least causes Poser not to draw those welds.  So as you move a vert box, body part welds will seem to break and be restored.  This obviously indicates that Poser doesn't like the method very well, but it doesn't seem to break anything in my tests.

This type of error does make me wonder, however, if the very premise of trying to get real-time vertex deformations using a callback may be what foils Poser 7.  If that is so, it seems unlikely that any changes to GUI updates will reconcile the script with P7.  I hope that is not the case.  On the other hand, this one is untested with P7 and it may (althouogh this seems unlikely) not cause the same problems as previous versions.