Quote - Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?message_id=2622055&ebot_calc_page#message_2622055

Quote - "Poser doesn't allow geometries to be updated on a per-frame basis ..."

Oh yes it does!

Well at least the internal renderer does, I don't know if the external version of Firefly honours the Python callback required to do the geometry change (I have a strong suspicion that it doesn't, but haven't tried it).

To get a taste of the issues involved with fluid dynamics, play with the stuff in Blender.

Wow!  I had no idea this was possible.  :woot:

It looks like the old P4-style rendering engine is gone, in versions after Poser 7, unfortunately.  So if the trick won't render with Firefly, it can't be rendered.  :sad:  Possibly a sketch render.  I suppose one could render the preview and try to work some kind of compositing, but at that point it may be better to use a more robust platform to render the fluid portion, to be composited.

I'll have to try this trick.  Thank you.  :laugh:

Quote - Well, I went silent too, but that was because I was busy playing with Mr. Looper. :-) And I don't have nearly as much to show for my silence as you do for yours.

However I did think of a possible application for the loop making script - or more likely a loop-making script. I'll be in touch when I've had a bit more of a think about it.

A loop-making script?    The mind boggles, it does.  :lol:

 As for the meta balls, that reminds me of MetaForm.. Dunno if the program (add on or whatever you'd call it, it works in Poser) is still available and I can't even recall where I bought it - but it does create a sort of fluids, I know I made a spluttering volcano with it back when I got it. My cave props here in Free Stuff is also made with it, as is IIRC my little Doggie... so metaballs can be a lot of fun. If you can get a better "fluid" engine than what was in MetaForm, then you've got an absolute winner!  (also the material zones MetaForm made was a tad confusing, something with a lot of layers I think.. I wonder if it works in newer Poser versions at all? I think it was for Poser 5 or possibly 6 - or perhaps it even worked in Poser 4 Pro Pack... hmm... it was a lot of fun L Now I miss it...

goes on an archaeological expedition in her Runtimes

It looks like MetaForm was the fluid-handling portion of the Weird Juice package.  I know that the free Drops script - the Poser metaballs modeler - only works in Poser 6-.  When the Python version was changed, it made the .pyd which is the operative portion of Drops incompatible.  The .pyd would need to be recompiled for Python 2.4.

So Drops has been gone for some time now, although perhaps MetaForm has been updated. 

[Googles a bit more....]

I found MetaForm for sale at Daz, where the listing only states compatibility with Poser 5 and Poser 4 Pro Pack.  Presumably this means the program hasn't been updated.  :sad:

Here's the metaball script, however (for what it's worth), for all of you to try.

It's potentially rather slow, using straight PoserPython and Numeric for the calculations (and not using one of the faster metaball functions, my tests of which haven't been promising, so far).  The Weird Juice stuff was compiled, and this can't hope to live up to the speed seen there.

This version is also incomplete.  The Tkinter bug in Poser 8+ which was discovered a week or two ago leaves me uncertain how I could best drive a fully-functional version of the script.  It needs to be able to add metaballs, create the isosurface geometry, and stay active so the user can keep adding balls.  But Tkinter can't be used for this until it's fixed, and the callback method I've been using for the loop scripts develops problems when used for more than one script run.  I'm trying to work out the best way to assemble a final version, and so far I'm not happy with the known options.  So there are delays with a final version due to conceptual problems.

At any rate, this one can't make the actual metaballs and it will shut down after one run.  To use this script:

• Add three Poser ball props to a scene.  These should end up being named "ball_1", "ball_2", and "ball_3" (minus the quotes).

• Position the balls as desired.  Use translation and global actor scaling.  (I haven't figured out how to enable rotation or axial scaling.  :sad:)

• Run the script.  This will create and select a bounding box around the balls.  The bounding box will have parameter dials for the script settings.

• "Mesh resolution" controls the density of the marching cubes grid used by the script.  Higher values give a higher-density mesh, but take longer to process.

• "Threshold" is the value which will be used to determine where the metaball surface is found.  A higher value will inflate the meta form (until it reaches the boundary of the cube grid, where it will develop holes).  A lower value will shrink the surface.

• RUN SCRIPT will start the script, but only if operated using the dial.

• END SCRIPT will end the script, but only if using the dial.

Some cases may crop up, particularly with lower mesh resolution and balls which have been scaled down, in which polygons end up being skipped.  I haven't found a way to avoid this problem yet, unfortunately.

Sorry this is a bit klunky.  :lol:  It looks like the GUI situation will be a bit of a head-scratcher for me, so I wanted to get this out so people could try it, and not get their hopes up too high while waiting. 

Poser 8 and up have wxPython, which is 8,642.57 times better than TK, both for the user and for the developer. Plus, you'll have a skill you can use to build real programs, as I've written some serious apps in wxPython.

I'm interested, but that solution lacks backwards compatibility with earlier Poser versions.  I'm interested in supporting P8+, but until Poser 8 is finished (many bugs remain :sad:), I'm not interested in supporting it at the expense of earlier versions.  Primarily because I'm still using Poser 7, myself, for most things.  :sad:  :sad:

But the bug which interferes with Tkinter is actually a bug with PoserPython.  Scene.ProcessSomeEvents() no longer allows the parameter dials to have input while a Python script is running.  This breaks the only method I know for having a Python script with a GUI running while still permitting user interaction with the Poser interface.  If there are other methods, I'd like to know of them.  

The attached script illustrates the bug, and is what I submitted to SM when reporting the bug.  Used in a Poser version before P8, this will create a box and allow the user to move it using the parameter dials, while the script runs.  Used in Poser 8, the parameter dials will not recognize any user input and will not allow selection of the box prop, although the box can be manipulated in the 3D view using the Editing Tools.

Is there a known method of achieving results similar to those which this script can provide in P7, without relying on Scene.ProcessSomeEvents()?

Edit:  My brain kicks in and it occurs to me that WxPython could be attempted for P8+, while Tkinter is used for earlier versions.  Hmm.  :unsure:

I think you're off to a great start with the MetaBalls, granted there are issues/limitiations to deal with.

MetaForm was a great plugin back in it's day, certainly was great for animated fluid/smoke/flame effects. I keep thinking it used a basic directional particle(sphere) emitter prop or emitted from the surface of a figure, with particle lifetimes, direction/spray radius controls, plus collision witn non particles etc.

Looking forward to seeing what you manage to come up with.  I'm not expecting another MetaForm, I think the scripts you've already created are awesome contributions, still amazed these are free.

Would be cool if some of the other gurus joined you and pooled resources(I see you caught BB's eye there), wonder if PhilC or face_off could offer any input.

So, whats next after MetaBalls?!  Perhaps a fracture system for dynamicly destructable objects/scenes.. Hah.

oh boy this looks like fun!  i'm looking forward to getting back home to my computer & trying this out.  amazing how far the loop-making script has brought you.  good work, Cage!!

Quote - I think you're off to a great start with the MetaBalls, granted there are issues/limitiations to deal with.

MetaForm was a great plugin back in it's day, certainly was great for animated fluid/smoke/flame effects. I keep thinking it used a basic directional particle(sphere) emitter prop or emitted from the surface of a figure, with particle lifetimes, direction/spray radius controls, plus collision witn non particles etc.

Looking forward to seeing what you manage to come up with.  I'm not expecting another MetaForm, I think the scripts you've already created are awesome contributions, still amazed these are free.

Would be cool if some of the other gurus joined you and pooled resources(I see you caught BB's eye there), wonder if PhilC or face_off could offer any input.

So, whats next after MetaBalls?!  Perhaps a fracture system for dynamicly destructable objects/scenes.. Hah.

I think a couple of fracture system scripts already exist, actually.  Ockham has Exploder, and PhilC may have something as well, IIRC.  Assuming I've understood your suggestion. 

Some of what MetaForm does seems feasible to me.  I started exploring isosurfaces because I wanted to be able to remesh an existing geometry, which would be something like what MF does with the field generation.  I'm not sure whether that would be using a distance field (which potentially could be quite slow, from what I've read), or some kind of particle system.

I could also see developing the basic process into a formula object generator, to create primitives from isosurface algorithms.  I could imagine implementing boolean operations between objects, assuming some kind of distance field method can be worked out.  I'm less confident about animation and dynamics, which are still mysterious to me right now.

The main problem I could foresee in trying to develop anything really complex from what I have would be speed.  With only three balls contributing, the processing takes three to eight seconds on my system, at a resolution level adequate to avoid holes in the resulting mesh.  A distance field or particle field of any kind could involve the equivalent of hundreds or thousands of contributing balls.  That could be quite slow, using interpreted Python instead of a compiled extension for the calculations.

I've thought about it a bit, and I can see two or three ways I can try to optimize my current metaball process for speed.  I'm not sure how much that might help.  The ultimate capabilities of the script, or any derivatives, would be dependent on how fast or slow the process ends up being, as well as my limitations as a script-writer and my more profound limits with respect to understanding complex math. 

Really, it's a bit remarkable that I've gotten this far.  :lol:  I'll certainly see where else things can lead.

Quote - oh boy this looks like fun!  i'm looking forward to getting back home to my computer & trying this out.  amazing how far the loop-making script has brought you.  good work, Cage!!

Thanks, jancory.  There's clearly potential in the process, if I can develop it further.  I'm hopin'.  :lol:

I set out to try to recreate the potential of the Drops freebie script, in order to try to understand the meshing process in use there, with the ultimate goal of trying to create better mesh structures for the skinning script.  Once a suitable GUI method is in place and the script is optimized for speed, it will pretty much approximate what Drops could do.  It is kind of neat that the processes open up a new range of possibilities.  :laugh:

I definetely have something different in mind from Ockham's and PhilC's exploding methods, but I don't want to distract you from MetaBalls :)

Wish I could say I was a great scripter/programmer or mathematician, as I would certainly help if I could in that area.  If I'm understanding correctly, I see what you mean about the speed when not using a compiled extension.  Hmm. 

If you can get around the speed problem and IF you want go for animation/dynamics , it might be better to start off by looking at some 2D pixel based particle systems, I think many of the principals still apply to 3D if you're using spheres. 
  Let me know if any of my ideas are getting too far fetched, but for animation in a particle system, think of a sphere as just one of those pixels/points, where as the point is the center of the sphere. You could probably generate spheres from scratch based on that center point with varying size options, etc.  So when you go to animate, instead animating geometry directly, you're just animating those points(dummy objects?).  Generating the spheres and isosurface for them would still present speed issues though I suppose.

Forgive me, I realize this is probably much more complicated than what you had in mind, but if you pulled it off, I'd pay for it for sure

I think I can speed it up a bit.  By applying the 3D grid screening process odf introduced for TDMT Match, the time was cut almost in half.  The marching cubes code requires eight calculations for each corner of a "box" in the marching cubes grid, and I can speed things up more if I pre-compile the corners and do lookups for the shared points.  Unfortunately I'll slow things down again when I apply rotations and axial scaling for each ball, which will require a matrix transform of the entire grid, per ball.

I'm trying to find a way to speed things up using Numeric functions on large arrays, but so far I haven't come up with a fully feasible approach.

I've tested four different falloff formulas for the metaball surface blending.  Of the two that worked, one had apparently well-known (but undisclosed, in most mentions of the process) flaws which prevent it from returning a smooth surface.  The other one seems to have all balls/particles int eh field exerting influence on one another even if they're out of range, which means all balls have to be processed for each box corner.  Unless I can find another function which works.

So the speed problems may be significant, ultimately.  Calculating the particle positions for animation wouldn't be the problem, assuming I can come to understand the math required.  The trouble would be creating the geometry once the particles were calculated.  If the idea is to recalculate the geometry on the fly during animation, there would be problems if each frame took several minutes or longer to generate the geometry.

Hmm, hmm.  Working at it, anyway.

Attached Link: http://en.wikipedia.org/wiki/Verlet_list

Basically you need to implement a cut radius for the influence, see attached link.

http://code.google.com/p/py-lepton/

Description:
"Lepton is a high-performance, pluggable particle engine and API for
Python. It is designed for creating graphical special effects for
games or other visual applications. The engine is designed to be very
flexible and does not rely on any other libraries directly. You can
use it either with OpenGL (via pyglet, PyOpenGL, wxPython, etc), or
with pygame by selecting the appropriate renderer. Examples are
provided using pyglet and pygame."

Interesting.  I've switched to pre-compiling the cube corners and doing lookups, and this seems to have removed the trouble I was seeing with unwanted influence which prevented the screening of out-of-range balls.  With all of this screening in place now, the script will process ten balls in about a second, at a mesh resolution setting of 12 (which ends up generating a 24 X 24 X 24 box grid for the marching cubes).  So it's looking better, but still not particularly fast, if cases with hundreds or thousands of balls (or particles) are truly being considered.

I think I can get more speed with an octree scheme of some sort, although I'm not yet sure how that will impact the new pre-compiled data method.  I also have an idea of how to better control the final mesh density while avoiding any processing of empty spaces without any ball influences.  I'll see what I can do with that.

Thanks for the links, nruddock and ADP.  :thumbupboth:  I'm not prepared to commit to trying particle simulations, but more information and examples can definitely help me think about the idea more effectively.

I've also been working on a metaballs script. Cage and I have been in communication however I had not realized that this looper thread had morphed into one on metaballs.

Here is what I have so far:-

Here is a link to an animation:-
http://www.philc.net/images/7balls_animated.avi

I'm only stuck because my algorithm sometimes leaves holes in the mesh. I feel it is due to a numbers rounding issue but for the life of me I can not find it. Also uses the same publicly available marching cubes code.
 
I think that since each of us is so nearly there I would like to collaborate.

I'm also sending response by private message so hopefully my "netiquette" will be correct.

Quote - I'm only stuck because my algorithm sometimes leaves holes in the mesh. I feel it is due to a numbers rounding issue but for the life of me I can not find it. Also uses the same publicly available marching cubes code.
 
I think that since each of us is so nearly there I would like to collaborate.

I'm also sending response by private message so hopefully my "netiquette" will be correct.

Nice one, PhilC!  :woot:  You've obviously gone much further than I did.

The approach I'm using can also generate holes, unfortunately.  I'd reached a conclusion similar to yours, but had no luck in trying to solve the problem.

Apparently a switch to marching tetrahedra could give better results.  I've ported some C code for that to Python, but haven't tested implementing it.

How does your script GUI work out, in Poser 8?  There's a bug with the new version of the parameter dials which prevents them from responding to scene.ProcessSomeEvents(), which has kept me from further development of metaballs.

I'll email you :)

I saw the metaballs mentioned at Phil's forum, it will be great if these Titans of Python can get together and make it work.

Oh, and I hardly like to mention it, but if a collaboration is on the cards, I'd like to request a way of making cuts in a mesh according to where a 3D surface intersects it - a bit like the Scissors module in Phil's Clothing Designer Suite, but not limited to working in one plane. I can wish, can't I?

;-)

incidentally, tetrahedrons are also ideal for a volumetric fracture system as well, or soft body simulations, hmm. would be neat if there was a way to trick the cloth room into doing soft body simulation.  (which also makes me think, anyone use cloth for deforming metal simulation yet?)

Nevermind fracture though, glad to see you guys are working together. 

Hey Cage, hows it going?

Any news? 

Quote - Hey Cage, hows it going?

Any news? 

Umm.  Not on my end.  I spent ten days or so studying academic papers, trying to work out how to handle signed distance fields.  At the end of it, I just needed a break from trying to think about math which is over my head.  :lol:  So I haven't really carried forward any of the scripts covered in this thread since the last time I posted here. 

If you're wondering about metaballs, you might check with PhilC.  I haven't heard from him for some time.  Given that he's already worked out animating the isosurfaces, which seems to be what folks really want, while I'm mainly interested in various re-meshing schemes, I think his script should be favored over mine.  So I'm not really working in that area at this time.  If I can work out the signed distance fields, though, I'll pick that up and see where it can lead.

As far as how it's going, I've been getting some nice stuff (well, I think it's nice stuff, at least :lol:) together for Antonia, and that should be ready for release in the next couple of days, hopefully.

But I think I may have another script to add to the basic set begun with the loop-making sript.  :laugh:  So far it looks like I may have a working path extrusion script.  Some of the test objects it's generated are pictured here.  Could be useful for one thing or another.  :unsure:

At any rate, if no disastrous bugs crop up, I may have a version of this to post in a day or two.  :laugh:

Looking forward to it cage. The loop script is a favourite of mine.

Ooh - this is grand - wanna play... How does one define the path to extrude along?

I know what - I'll just wait patiently for the script to appear. :-)

i still use MrLooper quite a bit--this one looks like fun too. also waiting patiently.....

What a nifty way to make wires!

Quote - Ooh - this is grand - wanna play... How does one define the path to extrude along?

The path is defined by placing marker points.  A spline path is then generated to fit those points.

The spline handling is done by a nice Python package found here:

http://urchin.earth.li/~twic/splines.py

(Okay, can I say that I HATE HATE HATE these new reply editor boxes?  It won't let me add a link to the URL.  :cursing:)

So far the path handling seems pretty flexible.  You have to place multiple markers close together to get a sharp transition, but it's possible.  None of the tubes pictured above used more than seven marker points.

Anyway, so far, so good....  :unsure:

Could this do flattened objects like a leash etc?  Or is it only tubes/wines (rounded objects) basically?

Trying to do a pic with a couple dogs being walked and trying to find a good leash that will bend the way I am picturing in my head is giving me fits

Quote - Could this do flattened objects like a leash etc?  Or is it only tubes/wines (rounded objects) basically?

Right now it could extrude a one-sided line (which Poser won't render), a two-sided strip, a three-sided tube, or a four-sided tube.  The latter three of these would involve flattened sides.  The current setup won't flatten or squash each ring of the geometry along one of its relative axes, but that sounds like a good feature to try to add.  I'll see what I can do.  :laugh:

Quote - Right now it could extrude a one-sided line (which Poser won't render), a two-sided strip, a three-sided tube, or a four-sided tube.  The latter three of these would involve flattened sides.  The current setup won't flatten or squash each ring of the geometry along one of its relative axes, but that sounds like a good feature to try to add.  I'll see what I can do.  :laugh:

It would be wonderful if it could, I know I would appreciate it.  In essence a leash is a very thin rectangular prism, the option to adjust the thickness of the created item would also be great.  (I need to read back some more and see if this is already there lol, I am trying to multitask too many things at once today)

Quote - (Okay, can I say that I HATE HATE HATE these new reply editor boxes?  It won't let me add a link to the URL.  :cursing:)

I always switch to HTML mode to add links: Explaining text

Quote - I always switch to HTML mode to add links: Explaining text

Ooh, many thanks!  :laugh:  'Cause these things are so buggy, I might as well have written the code for them.  :lol:

Quote - > Quote - I always switch to HTML mode to add links: Explaining text

Ooh, many thanks!  :laugh:  'Cause these things are so buggy, I might as well have written the code for them.  :lol:

Yep, that reply box reminds me of working with Word Perfect 20 years ago. Except that the internal representation was not even anything halfway sane like HTML.

Attached Link: http://www.renderosity.com

 See my link to rendo? easy

Quote - I don't understand - under the reply box is a great thing called "Link Name & Url".

 See my link to rendo? easy

Hey, wow.  I never bothered to look at that.  :lol:  I guess I assumed it was for use when you have an attachment. 

The link-chain icons for these reply editors often fail to respond to my mouse clicks, so I'll start using this new technique.

But that doesn't fix the new (-ish) reply editors.  :lol:

Basic instructions (also at the top of the script):

Use:

• Run the script.  A controller prop (EXTRUDER BOX) is created.
• Move the "Add marker" dial on the controller box to create a path marker.
• Translate each marker as desired.  Place at path transition points.
• Place multiple markers (at least 3) close together to specify a sharper transition.
• Each marker will point at the previous one.  This is for display purposes only.  Marker rotation has no effect on the final path.
• The control box can be positioned and rotated to specify the Origin and Orientation of the final tube prop.
• Set "Spline type (0,1,2)" to define the type of spline used for the path.
      0 = NaturalCubicSpline ---> smooth path
      1 = Polyline ---> straight lines, sharp corners      
      2 = BlendedQuadraticSpline ---> similar to 0, with different handling of ends
• Set "Keep markers" to any non-zero value to retain the marker props at the end of  a script run.
• The other options work the same as those for the loop-making script.
• When the markers are placed, move the "RUN SCRIPT" dial.  The tube will be created.
• Move "END SCRIPT" to quit.

Notes:

• The script may print the message, "Finding vertical vector for [ring number]".  This is for testing.
    Please let me know of any case where this runs for an extended period, or the script gets stuck at this step.
• Some functions and classes below are adapted from various sources online.  See function notes for details.

I'm learning more about these scene.EventCallback thingies.  They're perfectly safe and stable.  As long as you don't use them.  :lol:  :cursing:

I've managed to add all of the features I'd hoped to add, but now I've discovered a strange crash bug in the script, which is connected in uncertain ways to the event callback.  Earlier versions of this script did not have these problems, yet I haven't made any alterations within the callback function which should have changed callback handling.  Other of my scripts which use the scene event callback are fine.  But now... Blammo!

If anyone out there has been using the loop script or the skinner script, have you had any Poser crash problems with the scripts?  What happens on your end if you delete the control prop?  I'm wondering if this is peculiar to my system or Poser installation.  Any reports could help.

So I think I may have to port the loop scripts to Wx Python for P8+ and Tkinter for P7 and below.

I purposefully refrain from calling Poser a haphazard heap of something which should probably begin with "H", if I want the alliteration.  But, man.  Bugs, more bugs, things that aren't fixed, things that were seemingly never fully implemented.  It gets me down, even if Larry and Steve and the lot are good folks.

So, yeah.  I'm going to try to fix the GUI situation, but the script is otherwise ready.

Basic instructions, also at the top of the script:

Use:

• Run the script.
• Press "Add marker" to create a path marker.
• Translate each marker as desired.  Place at path transition points.
• Place multiple markers (at least 3) close together to specify a sharper transition.
• Each marker will point at the previous one.  This is for display purposes only.  Marker rotation has no effect on the final path.
• Set "Spline type (0,1,2)" to define the type of spline used for the path.
      0 = NaturalCubicSpline ---> smooth path
      1 = Polyline ---> straight lines, sharp corners      
      2 = BlendedQuadraticSpline ---> similar to 0, with different handling of ends
• Set "Keep markers" to any non-zero value to retain the marker props at the end of a script run.
• Set "Close path" to any non-zero value to create a loop instead of an open-ended tube.
• "Flatten X" and "Flatten Z" can be set to non-zero values, to squash or stretch the tube along its relative X and/or Z axes.
• Negative values will squash the tube; positive values will stretch.
• "Flatten dot value" specifies the angle of inclusion for Flatten (as a dot product result).  0.0 = 180 degrees of inclusion; 1.0 = only vertices which are aligned with the axis.
• The "Flatten smooth reps" can be set to specify an amount of smoothing to apply to the flattening results.
• Examples:
      A broad, flat tube:
          Flatten Z = -0.3
          Flatten X = 2.0
          Flatten dot value = 0.9
          Flatten smooth reps = 3
      An indented tube, similar to an electrical cord:
          Sections = 20 (for adequate resolution)
          Flatten Z = -1.0
          Flatten X = 1.0
          Flatten dot value = 0.9
          Flatten smooth reps = 3  
• The other options work the same as those for the loop-making script.
• When the markers are placed, move the "RUN SCRIPT" dial.  The tube will be created.
• Move "END SCRIPT" to quit.

Notes:

• Some functions and classes below are adapted from various sources online.  See function notes for details.

Thanks! Another busy weekend for me, so no time to play, but you can bet I will. This point from your previous post is probably superfluous in view of the GUIs in the new script?

Quote - If anyone out there has been using the loop script or the skinner script, have you had any Poser crash problems with the scripts?  What happens on your end if you delete the control prop?  I'm wondering if this is peculiar to my system or Poser installation.  Any reports could help.

• But I'll answer it anyway, because I can. I've used Mr.Looper a lot, Mr.Skinner not so much, and never had any trouble with them in Poser 7. This includes pulling tricks like shutting down Poser while the control plane is still in the scene. Of course the dials had stopped working when I re-opened, but it's never crashed. I've never tried deleting the control plane from under an unfinished script run, but you've tempted me now. :D

...

I just tried it, and the results were unspectacular. The dials disappeared when I deleted the plane (duh), I re-ran the script and all was well. Nothing caught fire or exploded or anything exciting. Ho-hum. :)

Quote - I just tried it, and the results were unspectacular. The dials disappeared when I deleted the plane (duh), I re-ran the script and all was well. Nothing caught fire or exploded or anything exciting. Ho-hum. :)

Thanks, EB.  :thumbupboth:  Interesting.  In testing, I found that deleting the runner prop (the parameter dials for which are linked to the scene callback) would crash Poser 7 and Poser 8, for all of the loop scripts.  Worse, the "END SCRIPT" dial for the new extrusion script crashed Poser as well.  Yet my old "Make Sphere" script, the first to use the runner prop with callback concept for user input, never caused any crashes at all.

Which, I guess, just illustrates that the scene callback shouldn't be relied upon to handle anything complex.  It can work fine, but it's too easily thrown into disastrous recursion to be trusted with much.  Testing results are inconsistent, presumably, because there are so many factors which can affect the outcome.

I think the new, double-GUI process may be better, ultimately.  It was just a matter of Cage needing to break down and learn how to work with wxPython.  It's not so bad.  Cleaner than Tkinter, and easier in many areas.

(Don't know if an unclothed wireframe counts as nudity, but I'm checking the flag just to be safe.)

I've also done my best to correct the spline handling when creating a closed path.  The spline now carries through all the way back to the start, but the join where the end meets the start is not quite 100% perfect.

Finally, I added the option to create an open tube without caps.  One might want to model something with tubes in Poser, working with the scene, then weld together open ends of various tubes in another application to create a final geometry.  Or create a tunnel or something.

This reminds me of Gordian Knot: a little program used on my older WinXP machine.  Could never get the app to run under Windows 7, EVEN from XP mode.

-Rªnce

I haven't heard of Gordian Knot, but I'll check it on Google, now that you mention it.  I wanted something with which I could create tubes within Poser, working with the elements in the scene.  The script does what I wanted from it, so I'm pleased.  :laugh:

It troubles me to learn that Windows 7 breaks programs, just like Vista did.  I'm still not happy with Vista.  I'd hoped W7 would be better.  Dang.

Attached Link: http://www.eurus.dti.ne.jp/~masasi/index.htm

Poser ++
http://www.eurus.dti.ne.jp/~masasi/index.htm

Like I said, doesn't seem to want to work under Windows 7.  A neat little app though, if you have an old WinXP machine about ...

Quote - Like I said, doesn't seem to want to work under Windows 7.  A neat little app though, if you have an old WinXP machine about ...

Ooh!  You know, I've seen that, I've probably downloaded it half a dozen times over the past five or ten years, or however long it's been up.  :unsure:  I recall seeing it, now, perhaps as long ago as 2003?  Hmm.

Anyway, I never, ever tried it.  One of those neat things I've downloaded and forgotten about completely.  :lol:

Does it (or did it) ever run within Poser?  Or is it standalone? 

It's a stand alone.  You may import .OBJ, bend the strings around any objects you can dream of, and then export the finished string.  The strings easily import back into Poser.

I can't remember how UV mapping work, but I use UVMapper anyway.  It was neat little program it just doesn't want to work in the new Windows.  Even tried it under both XP Pro and Business modes.

The video on the site pretty much says it all.  You can be bending strings in no time at all. -R