You don't have to dial exactly to 1.0.  You should only have to move the dial, either way, to activate the script.  But I've used sloppy coding on that bit.    I'll fix it in the current version of the script.

You've helped me realize that I need to clarify the instructions.  :lol:  I forget to mention things, like the fact that typing in the value for RUN SCRIPT and END SCRIPT doesn't seem to work, to activate the script. 

So it created the new geometry object, but didn't get to the prop-creation step.  That's troublesome.  The geometry is an internal Poser Python geometry object, which has to be created as a prop, but we don't seem to be getting that far.

Here's another attachment, with new print statements in that section.  It could be failing to create the actual prop, in which case the bad UV's in this 4e version of the script might be bothering it.  Possibly the older versions of PPy don't like something about the process of adding the new material.

Hopefully we're close to finding the problem.  Apologies for the hassle. 

I don't mind helping to debug this, if I can get it working it should be very useful, but right now the sun is starting to rise, and I must crawl back into my coffin before I turn to ashes. I will check back this evening. Running your latest script I got:

Created plane
Callback started
Starting callback
Callback is running
RUN SCRIPT 0.0
END SCRIPT 0.0
Callback is running
RUN SCRIPT 66.0
Starting loop generation
Making loop
Getting actors
cyl_1
Found vertices
Convex hull generated
Perimeter markers placed
Ring vertices placed
Verts, polys, sets created
UV mapping applied
New Geometry() instantiated

Quote - I don't mind helping to debug this, if I can get it working it should be very useful, but right now the sun is starting to rise, and I must crawl back into my coffin before I turn to ashes. I will check back this evening. Running your latest script I got:

Thanks, Les!  Sleep well!  I'll be following suit before long, myself.  :lol:  Sorry to put you through all of this, but it is quite helpful.  :thumbupboth:

I'll try to work out what could be happening.  Maybe I'll have something tomorrow.  :unsure:

I'm sort of wondering if the script worked for me in Poser 5 yesterday because I'd already been running it in Poser 7 and 8, earlier.  I'm not sure that's possible, actually, but it might explain why it worked before and not now, and not for others.  :unsure:

At any rate, it seems to be fixed.  :laugh:

Please let me know if you encounter any problems with the script. 

Quote - Mister Looper: a loop-making script
- Script only operates on visible actors.  To prevent actors from contributing verts to the loop path, hide them before running.
- Position the MR.LOOPER PLANE prop to define the plane in which your loop will be created.
- Reduce scale of plane as much as possible, for best results.
- If no vertices are found, try moving the plane closer to some vertices on your actors.  If only edges are intersected, it won't run.
- Move the RUN SCRIPT dial to run.  Typing the value into the entry field won't activate the script.
- Move the END SCRIPT dial to end.  Typing the value into the entry field won't activate the script.
- Any non-zero dial value will activate either RUN SCRIPT or END SCRIPT.  The dial can be turned to positive or negative.
- Change Sections setting to alter number of radial divisions of main loop.
- Change Slices setting to alter number of divisions in each cross-section ring of loop.
- Change Thickness setting to vary radius of cross-section rings.
- Set Apply smoothing to > 0.0 to smooth the resulting loop, <= 0.0 to disable smoothing.  Smoothing may shrink the loop slightly.

The above are the revised/updated instructions for running the script.  I'll see if I can get typed input to activate the RUN SCRIPT and END SCRIPT portions.  That might be a flaw in the way I'm running the callback, or a shortcoming of how Poser runs its callbacks.  At any rate, right now the dial needs to be moved, to run or end, and it can be moved to positive or negative, either way.  My apologies for having left that unclear, previously. 

Aw Cage, you always go whole-hog with these scripts, even when there's problems. You're wonderful :o).

Laurie

Quote - Aw Cage, you always go whole-hog with these scripts, even when there's problems. You're wonderful :o).

Thanks, LaurieA.  There are days when one can really use some warm fuzzies.  :lol:

new script runs properly in my P5; now i can put that clunky program away for another year or two. 2010 is soooo much better.
i'm starting to get some cool rendering ideas using this script....

i wonder if you could label the Run Script dial with something like 'Move Me to Run Script' or whaddever???  i don't understand it enough to try it on my own.

Quote - new script runs properly in my P5; now i can put that clunky program away for another year or two. 2010 is soooo much better.
i'm starting to get some cool rendering ideas using this script....

i wonder if you could label the Run Script dial with something like 'Move Me to Run Script' or whaddever???  i don't understand it enough to try it on my own.

I hope to disuse P5 for some time now, too.  :lol:  Hoo boy.

That's a pretty good idea, about the dial naming.  Perhaps "RUN SCRIPT (Use dial)", or something.

It's looking like the trouble relates to how Poser handles the event callback.  It won't recognize entries, only dial alterations.  If you enter 1.0 for the RUN parameter, then use any of the other dials, the script will run, but possibly not when you want it to.  This is one of those times when I wish Poser Python opened up more options for the script writer.  :sad:

Thanks very much for this script, and for all the work you did making it compatible with P6. 

I have not had time to give it thorough testing as yet, a couple of times my loop turned into a "D" shape, but I have been successful in making some loops, and that's the main thing.

Quote -
  It Worked!

Thanks very much for this script, and for all the work you did making it compatible with P6. 

I have not had time to give it thorough testing as yet, a couple of times my loop turned into a "D" shape, but I have been successful in making some loops, and that's the main thing.

Right on!  :woot:

Thank you for your patience in helping me debug it for the older versions of Poser.  I knew exactly where to look for the problem, when I tested it on my P5 this morning and encountered the same errors you'd been having.  Sorry to have required beta-testing for the release, though. 

It turned into a "D"?  was the plane edge embedded within any geometry when this happened?  That would cause that result.  There can be some shaping distortion if the sections setting is too low, as well.  Because the script places the rings evenly (which it does for use with tiled texturing), areas near a corner or sharp-ish curve may end up with vertices which aren't ideally placed.  The loop can collapse into itself in such areas.

I'm concerned because I'm trying to counteract some acknowledged but undisclosed bugs which apparently exist in the convex hull code.  If you get misshapen results when the plane position and sizing definitely weren't the causes, that would probably mean I need to try to do more to counteract any convex hull errors.  I'll look at the rest of the process, to see if such an error could creep in somehow for other reasons.

I hope the script can be useful for you!

Cage,

I had an idea  (Cage puts hands to head and sobs). The looper has been working well for me, but never being satisfied, I want more out of it. It seems that I often want to mirror a loop I made on the right side of a figure, on the left side of the figure.

Now it is a fairly trivial thing to set up some ERC in the prop to mirror its position and rotations in respect to left/right. I have in fact done that and the prop is attached above. However several questions arise as how, and whether, this can be tied in with your py script.

1.  Will this still work if the MR LOOPER plain has been moved via ERC?

1. Could the script be made to write the necessary code into the plain prop?

2. If it is not possible to write the code with the script, could the script and prop be divorced, so that the prop is loaded from the Props palette, and then the script is run to create the loop. Separating the prop and script might be a good thing in other ways. It might be useful to be able to save the prop set-up in various ways for future use.

Whether the script is separated from the prop or not, this idea would require the same plain prop to remain through two runs of the script.

Don't know if my idea is practicable. There are probably other, possibly simpler ways to mirror the prop, but I don't know what they are.

The above prop has a new  "Mirror" dial that can be used to mirror its position and rotations.

P.S.
MR LOOPER was been working well for me for quit a while now. I want to thank you again for this wonderful script.

Quote - I had an idea  (Cage puts hands to head and sobs).

Well, I mean, I'm not anti-ideas.  Love ideas.  Ideas are great!  Sometimes the delivery system for the ideas can be a bit obnoxious, IMO, but I think you're safe there, Les.  :thumbupboth:

Your idea is interesting, with some possible complications.  The main one being that my efforts to use Poser Python to set the min and max values for a dial didn't work out so well.  I'll have to tinker with that and see if I can get it to work.  Possibly the ApplyLimits() call needs to be used along with SetMin() and SetMax().  After that, there's the matter of inserting the ERC into the prop.  That would require at least a pose, possibly with a proxy figure loaded by the script if none is present in the scene, to permit the pose to be applied.  Alternately, one could write out or save the plane as a prop file, edit it in place, then re-load it to install the ERC.  Replacing the existing prop with a new one loaded from a file would create complications with the callback, which is linked to the existing prop, so all of this would have to be done prior to setting the callback.

Right now, you can mirror these like magnets.  Copy the plane settings before you run, then paste onto the next one and mirror the transforms appropriately.  It might be more straightforward to try to write that capability into the script, rather than trying to use ERC.  I'll have to see if Python offers a tool to write controlled data to the clipboard.  If possible, the data could be pre-mirrored and then just pasted into place on the next script run.  I'm not sure whether that's a sloppier way to to things, trying to involve the clipboard.

One might create a virtual clipboard somehow, using some constant scene element, if valueparm dials are added to that element.

Or!  The callback already in use could be linked to a "Mirror" dial which does what the ERC would do anyway.  If the dial is moved, the plane's settings could be automatically mirrored just using Python.  Then the dial would need to be zeroed again once the plane had been mirrored.

Let me think about this and tinker with options a bit.  I'm almost done correcting the UV splitting and welding, so I can start on your idea next.

A good idea!  :thumbupboth:

Edit:

Actually, there's no reason the RUN SCRIPT function really needs to delete the prop.  Hmm.  One could keep using the same prop, theoretically, then use END SCRIPT to delete the prop and end the callback.  I think if I make that change and set up mirroring in Python, it might be the most straightforward and flexible approach.

Quote - Possibly the ApplyLimits() call needs to be used along with SetMin() and SetMax().

I know nothing of Python, but you do need to force limits before the min and max have any effect (unless 'Use Limits' is turned on in the Figure menu).

Quote - Actually, there's no reason the RUN SCRIPT function really needs to delete the prop.  Hmm.  One could keep using the same prop, theoretically, then use END SCRIPT to delete the prop and end the callback.  I think if I make that change and set up mirroring in Python, it might be the most straightforward and flexible approach.

Sounds promising, I hope you can swing it.

Quote - Sounds promising, I hope you can swing it.

I don't think it will be a problem.  At least, nothing compared to these fershlugginer UV's.  :lol:

Spoke too soon.  :cursing:

Poser Python's callback handling seems to be tremendously clunky, and really sort of tacked-on.  Like many things in Poser, it's sort of developed, but not really.  The options are limited and it's hard to regulate (I'm looking at you, Hair Room design tools!).  Steers like a cow.

I've set up a "Mirror" dial, linked to the callback, which works nicely to mirror the plane.  The first time it's used, anyway.  After that, Poser will never recognize the dial value properly.  I can set the value back to 0.0, but Poser will no longer respond when the dial is turned again, only after you select another actor or make some change to the parameters of the plane itself.  But if I try to fight this apparent float sensitivity problem by comparing to an epsilon value, it's too sensitive and the Mirror function responds every single time any dial for the plane is moved.  :cursing:

I can try to insert ERC, but the same basic problem will affect the RUN and END dials if the plane is kept after the initial script run.  So the utility of even an ERC-linked Mirror dial will be limited.  You'd still have to copy the plane transforms to the clipboard and paste them, before mirroring.

The only idea I have left is trying to create a fresh copy of the plane once the loop-making function has run, then copy select settings from the old plane to the new, so subsequent runs can start more or less from scratch.  That might work, but I anticipate problems when I have to set up the new prop, then start the callback again, from a function which is run by the callback itself.

Poser callbacks are really a bit irksome.  :lol:

The attached script update modifies the RUN and END dial names, changes the "Thickness" dial sensitivity to a more useful level, and moves the UV seam from the top of the loop to the innermost ring, where it's hopefully less likely to be a problem.  Still haven't managed the UV welding, unfortunately.  :ohmy:

First off, thanks for this awesome little toy.

Using Mr Looper5f, while I was playing with this I used a poser primitive and Vicky and tried to loop around the body and a primitive, but it just loops around Vicky. I noticed you had on one of your original images the loops around loops, so I tried Vicky and a already placed loop, again it ignored the loop and just went around Vicky.  Am I doing something wrong?

Edited to add - Does this only work on figures not props, I can't seem to have it wrap just around a primitive(s).

ok I think I got this figured out. The poser primitives when scaled are leaving too much room between the verts and were being ignored. If I made the loop go close to the verts it grabs them. Same happened with loop to loop, I had it stretched too much and just hit it between the verts and just went through the edges. Guess I just needed to use the wire frame in poser to see what was going wrong.

Thanks again for the great script, lots-o-fun.

Ooh.  Thank you.  :laugh:

Umm.  What primitive are you trying to loop around?  How has the plane been transformed?  My first thought is that the plane has to be close enough to some vertices on the prop to be able to recognize them.  Depending on the prop, the plane position may need to be tweaked somewhat to get it to find the verts.  (Apologies for that.  I keep looking into ways that I can improve the vertex selection, but I haven't found one yet which doesn't end up selecting too many unwanted vertices.)

My second thought is that you might want to increase the "Sections" setting, to make the loop higher-res.  At the default, the loop may be too low-res in some cases, particularly when a large loop is being generated.  The rings of the loop can end up farther apart and it can sort of collapse into itself in places.

The attached shows a quick test of the process (to verify that I haven't broken anything in an update :lol:), using Antonia low-res and the standard Poser Ball prop.  It at least shows what I've done, to get it to work.

If you can tell me what your prop is like and what your overall consitions are when running the script, I can possibly come up with some other ideas.  Or you may have found a bug, which I'll try to fix, should that be so.

Quote - ok I think I got this figured out. The poser primitives when scaled are leaving too much room between the verts and were being ignored. If I made the loop go close to the verts it grabs them. Same happened with loop to loop, I had it stretched too much and just hit it between the verts and just went through the edges. Guess I just needed to use the wire frame in poser to see what was going wrong.

Thanks again for the great script, lots-o-fun.

Ooh!  Cross-posted!  :lol:

I'm glad you managed to solve the problem.  :laugh:

As I mention above, I'm trying to work out a way to improve the vertex selection process, to make it less finicky.  :lol:

Another idea (Les ducks for cover) . Would it be hard to make it so that the 'orientation' of the loop prop's 'origin' is aligned in the same plane as per the MR LOOPER props rotations (not sure I said that very well).

Say I want to turn the loop into a band by yScaling it. Say the plain was zRotated 45°, so that the loop is created with a 45° slant. At the moment, if I yScale the loop it distorts, as the origin is not aligned with the slant of the geometry. So first I have to go into the Joint Editor and set the orientation for xrot to 45°, so that the prop scales in that direction. I'm wondering if that part of the process could be taken care of in the script by setting the orientation the same as the rotations of the MR LOOPER plain. I don't know if this is a big ask or not. If it would be hard to do, forget I spoke, on the other hand, if it would be easy to implement it would be a nice feature.

Quote - Another idea (Les ducks for cover) . Would it be hard to make it so that the 'orientation' of the loop prop's 'origin' is aligned in the same plane as per the MR LOOPER props rotations (not sure I said that very well).

Say I want to turn the loop into a band by yScaling it. Say the plain was zRotated 45°, so that the loop is created with a 45° slant. At the moment, if I yScale the loop it distorts, as the origin is not aligned with the slant of the geometry. So first I have to go into the Joint Editor and set the orientation for xrot to 45°, so that the prop scales in that direction. I'm wondering if that part of the process could be taken care of in the script by setting the orientation the same as the rotations of the MR LOOPER plain. I don't know if this is a big ask or not. If it would be hard to do, forget I spoke, on the other hand, if it would be easy to implement it would be a nice feature.

This is a good suggestion, and one I hadn't even considered.  :thumbupboth:  Shouldn't be difficult to set up. 

The mirroring is proving absurdly tricky, however.  I'm beginning to consider the possible benefits of switching from callback use to a more standard process which creates pseudo-parameter dials for the plane, using Tkinter.  That might open up some possibilities, among them the creation of multiple loops in one pass, as suggested earlier by jancory.

I'm also trying to fend off some unwanted loop deformation which is still creeping in because of the worldmatrix use, in spite of my efforts to fend it off.  If you scale the plane substantially on x,y, or z, you'll get a result which is flattened to a certain extent along the scaled axes.  This doesn't seem to happen when the Scale dial is used to globally scale the plane along all axes evenly.  This loop deformation could actually be treated as a feature, rather than a bug.  I don't know.  If users see a potential benefit in being able to generate a loop which has flattened rings, it opens up possibilities.  If not, it should be fixed, if possible.

And, seriously.  No need to duck for cover.  I know I have an unfortunate temper (:blushing:) , but I've taken the necessary steps recently to keep it under control.  I appreciate your suggestions.  Thank you!  :thumbupboth:  :laugh:

• Now setting origin, endpoint, and orientation of new loop to match those of plane, as requested by Les.  This enables correct scaling of the loop.
• Fixed bug which was creating squashed/deformed loops when plane is scaled on X,Y, or Z.
• Added option to create a "Fatness" morph on the new loop, as is present on the Poser torus primitive.
• Made a slight change to the test when locating intersection candidates.  Hopefully this will improve the selections somewhat.
• Changed default setting for smoothing option to 0.0 on parameter dials.

Now I'll see if I can work out some way to handle the requested mirroring.

mr_looper5g.py sounds like e great leap forward. The Fatness morph should be a great help, as it is sometimes difficult to exactly judge the appropriate fatness prior to creating the loop, and the automatic orientation will be a big time saver.

Quote - I made some bands for Antonia. Still a WIP as it needs JCM to match Antonia's JCM. Now if I can figure out how to make a reef knot...

Nice one!  :laugh:  :thumbupboth:

I've been trying to think about things like knots, but I'm not quite sure how that would even need to be approached, at this point.  I think a more sophisticated way of defining a path would be required.  If the path could be defined, the basic extrusion process used for the loops could be applied, possibly with some addition to cap any open ends.  Not sure how to define that path, though. 

I'm thinking about this mirror feature.  What if you could set the option to mirror and then, if the plane is translated on X or rotated on Y or Z, a second pass would be automatically run, to create the mirrored loop in the same script run as the original?  That would circumvent all of the callback complications and remove any need to keep the plane around after the script run, as well as avoid futzing about with ERC insertion poses or copying methods, clipboard-related or not.  A similar approach could be used to run a batch of loops, stacked along the plane's Y axis at user-defined intervals.

To use the Mirror function, position the plane and set "Mirror loop" to > 0.0.  If the plane is translated on X or rotated on Y or Z, a second, mirrored loop will be created in the same script run.  The first loop created in the run will be excluded from contributing to the second loop's path, so the two can be criss-crossed if desired.

Tomorrow I will add a "Stack loops" option, to create multiple loops stacked along the plane's Y axis, using a technique similar to the mirroring.

Quote - What if you could set the option to mirror and then, if the plane is translated on X or rotated on Y or Z, a second pass would be automatically run, to create the mirrored loop in the same script run as the original?

Not sure I follow you. Do you mean just any transform, then the script automatically performs the mirror at the correct transforms? That would be fine. Or do you mean that the user has to perform the three transforms manually, then the script runs a second time? This latter would not really achieve anything worthwhile. The tedious part is mirroring the three transforms, and that's the part that would be nice if it could be automated. The only sort of symmetry that's really needed is left/right, and that is always achieved by those same three transforms mentioned above, all three are needed, except in the case where some of them are zero.

[EDIT]

Cross posted. Will try your new script.

Brilliant! 

Cage, you are a genius! The Pope is coming to the U.K. soon, and I shall be have a word with him about your beatification. Or failing that, at the very least you deserve a mention in the Queen's birthday honours!

It worked splendidly, and will save a lot of time and effort.

That got me thinking about chains. If you created a vertical stack of loops round two parallel cylinders with the correct spacing you would have the basis of a chain geometry. You could then apply a pose to each segment to zRotate it by 90°. Next you could apply another pose to every second link to yRotate it 90°. Now all that is necessary is to export all the segments as an obj, and you have your chain geometry.

It would be no great effort to construct the geometry by this method, and the py script would only be needed to create the geometry, not to apply the rotations. The real hardship would come in writing the cr2. I'm wondering if a py script could write out a cr2 with a series of regularly spaced actors. That would take the hard work out of building a chain.

Quote - Brilliant! 

Cage, you are a genius! The Pope is coming to the U.K. soon, and I shall be have a word with him about your beatification. Or failing that, at the very least you deserve a mention in the Queen's birthday honours!

It worked splendidly, and will save a lot of time and effort.

Golly.    Thanks, Les.  :lol:

Could you get Stephen Moffatt a mention in the Queen's birthday honours, in my stead?  I think the Moff prob'ly deserves it more than I do, and would handle it better.  :lol:  I'd just get a swelled head and possibly become (even more of?) a PITA to be around.  :lol:

But, thank you.  I'm really pleased that it worked for you.

I'm thinking about adding an option to the mirroring to include the first loop in the second loop's pass, in case you actually do want them to overlap, rather than intersect.  If Mirror <= 0, there would be no mirroring.  If > 0 but < 2, overlap would be excluded.  If >= 2, overlap would be included.  Or something along those lines.  A bit more flexibility, hopefully without being too much more complex for the user.

Quote - That got me thinking about chains. If you created a vertical stack of loops round two parallel cylinders with the correct spacing you would have the basis of a chain geometry. You could then apply a pose to each segment to zRotate it by 90°. Next you could apply another pose to every second link to yRotate it 90°. Now all that is necessary is to export all the segments as an obj, and you have your chain geometry.

It would be no great effort to construct the geometry by this method, and the py script would only be needed to create the geometry, not to apply the rotations. The real hardship would come in writing the cr2. I'm wondering if a py script could write out a cr2 with a series of regularly spaced actors. That would take the hard work out of building a chain.

A Python script could space the actors, save the geometry (to avoid problematic geomCustom references), and write the .cr2.  What it couldn't do is apply separate groups to the different ring segments.  So perhaps working with geomCustom would be the best way to try to automate that sort of thing.  Hmm.  A Python script could also add any EasyPose type ERC to the .cr2.

Let me think about this.  I hadn't really given any more thought to chains than to knots.  There may be some way to automate the creation of a chain even more fully than you're suggesting, at least the geometry portion.    Hmm.

Lots of good ideas!  Excellent!  :thumbupboth:

Ooh.  Looking at the image of the chain link, above, I notice that I still need to do some work on setting the proper angle for each circular cross-section of the loop.  Seen from above like that, it's clear that the angles are pretty close to correct, but not really.

I'll see what I can do about that....

Okay.  Here's an initial idea for an automatic chain-building feature.

Once the first link is generated, there's no reason to calculate a new geometry for the subsequent links.  That fist link can just be repeated, with appropriate rotation and translation of the geometry.  My thought is to add a "Make chain" dial.  At zero, it would do nothing.  If non-zero, it would determine the long axis of the first link and move additional links in that direction, rotated cross-wise to the plane and translated by the length of the link minus twice the Thickness.

The "Make chain" dial would determine whether the links are added in a positive or negative direction, as well as how many links will be added.  So a setting of 10.0 would create ten links along the positive side of the link length axis, and -10.0 along the negative.

The only trouble (aside from working out all of the matrix handling and interpreting positive or negative directions if the length axis is not aligned on X, Y, or Z) would be a case where the first link is perfectly round, with no longer axis.  In that case, a default would need to be applied, and I'm wondering whether X or Z would be preferable.

There are probably complications which don't occur to me offhand, but the above seems feasible.  :unsure:  I'll tinker with the idea and see what happens.

Doing perfectly straight chains is really easy (there are some arcane CR2 tricks if you want to make posable ones), doing hanging ones with the ends at the same height isn't too hard, but if the ends aren't at the same height the math gets quite tricky.

Quote - Doing perfectly straight chains is really easy (there are some arcane CR2 tricks if you want to make posable ones), doing hanging ones with the ends at the same height isn't too hard, but if the ends aren't at the same height the math gets quite tricky.

It sounds like you may be talking about whether the chain is axially-aligned or not.  Is that correct?  If they aren't axially-aligned, the direction of chain growth can be handled using a direction vector.

Maybe I'm under-thinking some part of this.  :lol:  I can't see the problem being trickier than the effort to space the rings evenly along the loop path and rotating the rings appropriately turned out to be. 

At least I'd like to think so.  :lol:  Am I overlooking something?    Possibly something involving the rotation matrix?  Hmm.

Quote - Let me think about this.  I hadn't really given any more thought to chains than to knots.  There may be some way to automate the creation of a chain even more fully than you're suggesting, at least the geometry portion.

It would be great if you could come up with a chain making script, even if it could only do parts of the process. I did once makes a chain figure, but it was a lot of tedious work. You make a good point about using geomCustom to avoid the need for group names.

Whilst any help in the process of making a chain would be appreciated, the geometry is only part of the problem. The cr2 is arguably an even greater part.

For the most part each actor in definition section of a chain cr2 would have identical contents. The exceptions being the name of the actor, and the 'origin' and 'endPoint' lines. It is calculating and typing out the origin/endPoint lines that puts me off the idea of making chains. Any help on that score would be much appreciated. Even a script that just took the origin and endpoints of link 01, and the desired spacing as input, and that would output a list of origin/endpoint lines for the whole chain,  that could then be pasted into a cr2, would be a help.

Oh, and I forgot about the parent line, which of course would be different
in every actor.

It also applies a much-altered actor selection process and a revised intersection validation process.  Intersection with edges is now possible and it looks like inappropriate selection of nearby vertices is far less likely.  I haven't tested the new process as thoroughly as I had the old one, so please let me know if you encounter any errors in this new version.

This version also adds a loop-stacking feature, which will create a series of loops, stacked along the plane's Y axis.  More on that in the next post, with an explanation of use.

The parameter dials show the settings used to create the series of 21 loops, shown in the image.  The "Stack loops" value is the number of loops, in addition to the first one, to be stacked.  Here, it's set to 20.  The "Stacking offset" value defines how far apart the loops will be and in which direction along the plane's Y axis they will be created.  The setting here is -2.0, which sets the spacing at the diameter of the loop cross-section, then moves down on Y.

The "Stacking offset" Value will be multiplied by the "Thickness" value, to move the plane on Y for each stacked loop, when the script is run.  Since the thickness is the radius of the loop cross-section, the default setting of 2.0 is the value needed to place two loops directly on top of (or beneath) one another without any overlap.  The sign of the parameter input determines whether the stack grows on +Y or -Y.

The stacking feature can be used along with the mirroring feature, as shown by the sets of mirorred and stacked loops shown in the attached image.

Didn't test the stacking enough.  I didn't consider that the translation dials use the global axes, not the local axes.  So that version of the script I just posted will only stack on Y, not on X, Z, or an arbitrary axis.  The attached shows what happens when you try to stack along some other axis.  :lol:

I'll see what I can do to correct this.  Some simple vector math and the plane normal should do it....

Quote - It would be great if you could come up with a chain making script, even if it could only do parts of the process. I did once makes a chain figure, but it was a lot of tedious work. You make a good point about using geomCustom to avoid the need for group names.

Whilst any help in the process of making a chain would be appreciated, the geometry is only part of the problem. The cr2 is arguably an even greater part.

For the most part each actor in definition section of a chain cr2 would have identical contents. The exceptions being the name of the actor, and the 'origin' and 'endPoint' lines. It is calculating and typing out the origin/endPoint lines that puts me off the idea of making chains. Any help on that score would be much appreciated. Even a script that just took the origin and endpoints of link 01, and the desired spacing as input, and that would output a list of origin/endpoint lines for the whole chain,  that could then be pasted into a cr2, would be a help.

Nruddock may be correct and there may be complications, which I'm not seeing yet, involved in the process of setting up a chain.  But I'm fairly sure that getting the origins and endpoints shouldn't be too hard, if the length of each segment is known.  That would be a known value if the script creates them.  The twist axis of the link would be a directional vector running along the link's length axis.  The same basic process used when calculating a morph delta should be able to be applied to position the links and set the origins and endpoints appropriately.

The tricky part, for me, would be creating the .cr2.  Can you supply some kind of template .cr2, containing only the basic information for a chain?  I could work from that to try to create something which might work out.

Possibly this should be a separate script, to avoid complicating the basic loop process too much.  Hmm.

would a script to generate a chain given two endpoints and a droop amount be easier than generating a cr2 ?

the problem with chains is that the links overlap, so the endpoints are sort of between the two ends.  It complicates the joints a lot .

At a quick test the mr_looper6e.py is working well, including the stacking feature.

I'm not sure what you mean, by the droop amount. 

Where would the endpoints fall, basically, on the really crummy illustration of two chain links which I've attached?

Quote - Didn't test the stacking enough.  I didn't consider that the translation dials use the global axes, not the local axes.  So that version of the script I just posted will only stack on Y, not on X, Z, or an arbitrary axis.  The attached shows what happens when you try to stack along some other axis.

I'll see what I can do to correct this.  Some simple vector math and the plane normal should do it....

I'll keep this version, one man's bug is another man's feature!

Quote - The tricky part, for me, would be creating the .cr2.  Can you supply some kind of template .cr2, containing only the basic information for a chain?  I could work from that to try to create something which might work out.

OK, I'll do a cr2. It may be too big to post in the thread, so can you IM me with an email address to send it to? When you say "containing only the basic information for a chain?" could you elaborate a bit on what you mean by that? Do you mean a skeleton with only the bits that would change with each link?

I think just a basic template with two or three links, showing the ideal origin, endpoint, and orientation.  It doesn't need to be a working .cr2 which could function in Poser.  Just something I can try to study to (hopefully) figure out how to approach this idea.  I don't think the "figure" section or the geometry listings would be needed, unless there are any chain-related peculiarities which would fall there.  Maybe a couple of sample links, as well, so I can judge how the joint positions relate to the geometry scale, and how the pices fit together.  If all of this can't be attached as a ".zip as .txt" in a forum post, I'll PM you with an e-mail.  :thumbupboth:

Here's a bugfix for the update I just posted.  This one seems to be stacking as intended, along whatever axis represents the local Y for the plane.  I expected localspace translation, prob'ly because I was thinking about the scaling along local axes which was set up yesterday.  :lol: 

Quote - I'll keep this version, one man's bug is another man's feature!

I generally think that way myself, actually!  :lol:  Not everyone appreciates that reasoning, however, I've found.  :sad:

Sorry for taking so long to get the cr2 to you. I am trying to determine the best place for the origin. It's not that easy. With a vertical chain the best place for the origin in respect to xRot is not the best place in respect to zRot. It seems to be a choice between either making a compromise and placing the origin half way between the optimal for each, or restricting odd numbered  links to zRot only and even numbered links to xRot only. I'm still making cr2s and testing the different options. Will get back to you as soon as I can.

The links are spaced in increments of exactly 0.1 Poser Units. The thickness of the link (as viewed from the side) is 0.022565 PU, within a tolerance of +- 0.000005 PU. The width of the hole in the link is approximately 0.044 PU, the hight of the hole approx 0.1 PU. The overall hight of the link is approx 0.14513 PU, +- 0.000005 PU. By the way, finding this out was not made easier by the fact the P6 joint editor miss reports the position of the origin by more than  0.001 PU.

Attached above is the skeleton cr2. It makes more sense if you can see the actual figure in Poser, so I'll try to attach it to my next post.