• Select the axis along which you want the chain to be created.
•  Select the location at which you want to save the .cr2 and .obj.  (Default is Runtime:Libraries:Character:Untitled.cr2)
• Enter the number of links long the chain will be.

The remaining settings all pertain to the shape, size, and resolution of the links. - Sections is number of radial divisions of loop, as in Mr. Looper.

• Slices is number of divisions of each cross-section ring of the loop, as in Mr. Looper.
• Thickness is the radius if the cross section rings of the loop, as in Mr. Looper.
• Radius is the radius of the two circles which will be used to generate the links.
• Link Length is the number of circles long the link will be.

By varying these settings, you can create a wide variety of chain link styles.

Currently the script will generate the .cr2 and .obj files and isn't auto-loading the figure once it has been created.  I can add that in the next release, if that would be a preferred handling.  

There is no need to close the script after creating a chain.  More can be created, although they will overwrite one another if the path is not changed for each one.

yay, superb, excellent  yay 

thats an excellent chain. I did 30 links at the default settings , and I threw in erc and it all bends perfectly, no links deform .

I did  apply a base color and that was fine.

Applying a checkerboard texture using the tile node didnt work very well.

ok, a bit more poking about shows every rong of polygons is mapped exactly the same.

Not really a problem but would be nice if the rings couls stack in uv space for each link .
This would mean knowing how many rings comprise a link and start at the bottom of uv space, and then adding each ring onto the last.

I hope you understood that, I will try to map one to illustrate.

Quote - ok, a bit more poking about shows every rong of polygons is mapped exactly the same.

Not really a problem but would be nice if the rings couls stack in uv space for each link .
This would mean knowing how many rings comprise a link and start at the bottom of uv space, and then adding each ring onto the last.

I hope you understood that, I will try to map one to illustrate.

I've kept the same UV-mapping as is used in the loop script, where it's really more optimized for texturing something like a rope, perhaps.  Each ring has its own tiling.

If you can prepare an example of what you want, I'll see if I can add that as an optional mapping type.  Right now I can offer planar mapping, this ring mapping, or possibly per-polygon tiling, although I haven't tested the indexing on the latter.

This one:

• Adds ERC for Twist, Bend, and Side-side, as prepared by lesbentley.
• Adds parameter dial groups to each actor.
• Applies overwrite protection.  Multiple chains can be created using the same path and they won't overwrite one another.  Each new chain will have a numerical suffix added in order of its creation.
• Loads the newly-created chain figure at the end of the script run.

Now I'm going to see what I can work out for a catenary-posing and/or prop-creation script.

Okay.  That's looks easy enough, as long as you don't expect to have welded texvertices.  :lol:

I'll see what I can do.

If no one else is complained about it I am happy to let it go. I dont usually try to texture map chains anyway.  It would be more of an issue with your loop script because I texture those as ropes.

Quote - If no one else is complained about it I am happy to let it go. I dont usually try to texture map chains anyway.  It would be more of an issue with your loop script because I texture those as ropes.

It's an easy enough modification, and it would actually be easier to try to weld the texvertices with the UV setup you request than with the ring-mapping.  It should be a good option for both scripts.  :thumbupboth:  I'll try to tackle it tomorrow.

Paging nruddock!  :lol:

Looking into the catenary problem again, I came across this:

A Brief Exposition Of The Catenary Curve

While I can read very basic summation notation, this is a bit beyond me.  :blink:  :lol:  However, the paper gives a formula which the writer seems to state will allow for the solution of a catenary when the endpoints are not level on Y. 

Quote - Although our figure shows the end-points at the same height, this is not necessary.
Indeed we could place the end-points anywhere on a given catenary curve,
snip the excess, and the resulting portion of the curve would hang unchanged. Put
differently, every part of a catenary curve is also a catenary curve.

Can you make heads or tails of this?  Might this help solve the problem? 

Another one, this one claiming to have a solution:

http://www.jstor.org/pss/2687546

Tried your chain_maker3b.py. Got problems, probably due to P6 crappy handling of Python. Ran the script with default settings. First run I just got a blank python window with no text. On a second run (without closing the script) I did get text in the window, but can't copy text, so have done screen capture composite image above.

I will try the first version and see what I get.

Tried the first script chain_maker3a.py. Same procedure, same result, almost same error message, except refers to one different line number.

Aha!  Looks like the math module did not have built-in conversion between degrees and radians in the older version of Python used by Posers 5 and 6.    I didn't know that, but it would explain why the feature seemed to be such a well -kept secret, if it had just been added recently.

It's an easy fix.  Try the attached revision of the 3b script.

Sorry about that, Les.  :sad:

**  It worked! It worked!** IT WORKED! 

Bless you Cage, this is going to be so very useful! 

Quote - **  It worked! It worked!** IT WORKED! 

Bless you Cage, this is going to be so very useful! 

Excellent!  :woot:  With all the work you put into designing the donor .cr2, it would be pretty rotten if it wouldn't work for you.

Let me know if any shortcomings become apparent.

is there an upper limit to the number of links it can create?

Quote - is there an upper limit to the number of links it can create?

I haven't set one, so theoretically, no.  The script takes longer to create the chain, as the length increases.  Ten links is very fast, 100 takes a bit.  A really long chain would be impractical in Poser, I would think, but one could try to make such a chain.
I suppose I should do some tests, and watch the timing and the RAM consumption.  Hmm.

Quote - However, the paper gives a formula which the writer seems to state will allow for the solution of a catenary when the endpoints are not level on Y. 

Quote - Although our figure shows the end-points at the same height, this is not necessary.
Indeed we could place the end-points anywhere on a given catenary curve,
snip the excess, and the resulting portion of the curve would hang unchanged. Put
differently, every part of a catenary curve is also a catenary curve.

Can you make heads or tails of this?  Might this help solve the problem?

Well the author does say that , but later says :-

Quote - Unfortunately, we cannot solve the equation h = (cosh(L/2)a − 1) /a for a, so
we are unable to write a as an explicit expression in terms of L and h alone. However,
we can put a value for L into the equation for h and then approximate a arbitrarily
closely using numerical methods

meaning that they didn't actually manage to find an analytical solution even for the easy case and I don't think they got close to one for other cases because there's no sign of them setting out a formulation of the non-equal height case.

The other reference supports my view, saying > Quote - ... when the supports of a catenary are at different evelations, the mathematical complexity preculdes a theoretically correct solution ...

When I get a chance I'll check my working and code to see if I can suggest a better method for the inital guess.

Hoo boy.  A 1000 link chain took about ten minutes to generate and grabbed 35% of my RAM, failing to release it at the end of the run.  The resulting .obz file is 4.5 MB, as is the uncompressed .cr2 for the chain.  Poser is slightly slow in responding to camera changes once the long chain has been loaded, and the entire chain can't be displayed onscreen at one time without pulling back too far to be able to see what it actually is.

So.  Obviously I need to try to optimize the process and do some junk-cleaning.  I'm being cavalier about the data which is being processed by the script, and I'm not cleaning all of it up as I go and releasing the RAM.  It might help to write the files as they're built up, too, rather than compiling them fully then writing the whole thing at once.

I think it's fairly evident, as well, that a 1000-link chain isn't really a practical figure in Poser.  :lol:

Edit: When I removed the 1000-link figure from my scene, 10% of my RAM was released.  Poser was using all of that just to keep the figure passively loaded in memory.  Yikes!  :scary:

Quote - meaning that they didn't actually manage to find an analytical solution even for the easy case and I don't think they got close to one for other cases because there's no sign of them setting out a formulation of the non-equal height case.

The other reference supports my view, saying Quote - "... when the supports of a catenary are at different evelations, the mathematical complexity preculdes a theoretically correct solution ..."

When I get a chance I'll check my working and code to see if I can suggest a better method for the inital guess.

I don't see how the second reference supports your view.    The writer may be incorrect, but he seems to believe he's found a solution in spite of the widespread view represented by the line you quote.

Here's the quote, in context:

Quote - A search of various textbooks and handbooks of mathematics, mechanics, and engineering practice produced what appeared to be a settled conclusion: when the supports of a catenary are at different elevations, the mathematical complexity precludes a theoretically correct solution, and a parabolic approximation is the recommended approach.

"Having since retired, I had the time to revisit this question, convinced that there must be a mathematically correct way to solve the generalized problem.  As it turns out, a combination of algebra and a scientific calculator will do the trick.

The writer then goes on to present a method which he seems to think gives the solution to the problem.  Unfortunately, we can't tell whether his peers tested his method and found it flawed, publishing their responses in subsequent editions of The College Mathematics Journal.

Have I misunderstood? 

remember cage it has to store the geometry , and the default for each link is 300 polys (30 x 10) , so 1000 link chain 300,000 polys  :woot: 

an actual program limit would be the variable sizes so it comes down to how long you want to wait and how much memory it will take.

I did find a paper on catenery for different anchor points but it also discussed different angular loads :(  it used an itterative method of changing A in the equation (that tightens or flattens the curve ) and then test fitting it to your known points.  It didnt seem that workable in poser python.

Quote - I think it's fairly evident, as well, that a 1000-link chain isn't really a practical figure in Poser.

I would suggest setting a limit of at the very most 300 links. A 300 link chain would presumably not need to be viewed form close up, so could use quite low res geom.

I am trying to run some parameters through to see what sort of big chains can be done, and the more common restrain your ... er dog  .

I would make this a commercial product Its that useful. or at least compile it to a pyc so people cant tinker with it , and yes , by people I mean me :) 

Quote - I would suggest setting a limit of at the very most 300 links. A 300 link chain would presumably not need to be viewed form close up, so could use quite low res geom.

I hate to set an actual limit.    Hmm.  I've added a status box which lists the script progress, since processing can apparently take some time.  The status box could actually list a warning if a chain of > 300 links is attempted, before running.  It could suggest that the Sections and Slices settings be reduced for a longer chain.

Which reminds me.  I'm curious about what might be the most optimized low-res chain the script can create.  I think if Sections is set to 10 and Slices is set to 4, that might make something low-res which could work well in the background of a scene.  Hmm.

Quote - I did find a paper on catenery for different anchor points but it also discussed different angular loads :(  it used an itterative method of changing A in the equation (that tightens or flattens the curve ) and then test fitting it to your known points.  It didnt seem that workable in poser python.

I think I saw one like that last night.  So far, nothing I've read seems useful.  I'm veering toward using the mere parabola.

Quote - I would make this a commercial product Its that useful. or at least compile it to a pyc so people cant tinker with it , and yes , by people I mean me :) 

Tinker away!  :lol:  I have no objection to having others learn from, expand upon, or even swipe my code, if it comes to that.  I think it should be taken as given that once you post something on the internet, it's out of your control.  You can try, I suppose.  You can still hope to control the state and distribution of the "original" data, maybe.  But once it's out there, someone will borrow it, or use it in a way you didn't expect (and may not like).  If there's a way to decompile, decode, or decrypt something, someone will probably try to do so, assuming what you've posted has any actual appeal to such people.  Hmm.

I'm babbling now, aren't I?  Sorry.  It's a problem I have, that.  :lol:  My point: if you want to tinker, go ahead.  Doesn't bother me.  :thumbupboth:  Just be cool about it, if you get my drift.  :laugh:  

It also adds a status box which alerts the user to script progress, lists the final file paths for the .cr2 and .obj, gives timing information, lets the user know if there's been a problem with the process, and warns about creating extremely long chains.

Finally, the new UV mapping requested by markschum is now available as an option.

that looks really good, cage. 

Attached Link: http://www.maa.org/pubs/Calc_articles/ma028.pdf

No, that was me not reading far enough.
Google came up with a link to a full version of the paper (see attached link), so I been able to see what he came up with.

The flaw is the assumption that the height of the supports are measured in the same FoR as the catenary, fortuitously making the height of the lowest point of the chain equivalent to a and so eliminating an unknown, which will almost certainly not be the case (i.e. it's another special case).
Essentially in the truely general case the supports are arbitarily offset w.r.t. the catenary's FoR as the only measurements we have are in the real world FoR, not the catenary's.

Even without the above we have two unknowns to find, c and x' in the paper's notation from what we do know v, d, l.

Thank you!  :laugh:  I didn't expect to end up making chains, when I started making loops, but I'm pleased with the result.  I hope it can be useful.  Something like the attached image might be able to serve as the basis for a necklace or bracelet or something. 

Quote - Attached Link: http://www.maa.org/pubs/Calc_articles/ma028.pdf

Quote - "Have I misunderstood?"

No, that was me not reading far enough.
Google came up with a link to a full version of the paper (see attached link), so I been able to see what he came up with.

The flaw is the assumption that the height of the supports are measured in the same FoR as the catenary, fortuitously making the height of the lowest point of the chain equivalent to a and so eliminating an unknown, which will almost certainly not be the case (i.e. it's another special case).
Essentially in the truely general case the supports are arbitarily offset w.r.t. the catenary's FoR as the only measurements we have are in the real world FoR, not the catenary's.

Even without the above we have two unknowns to find, c and x' in the paper's notation from what we do know v, d, l.

Aha.  So he didn't have the full solution.  Dang.  :sad:

I have a basic script set up which can serve as the foundation for a posing script, if and when the proper math for the best curve can be determined.

I looked at Zark's script, from the link lesbentley posted, and that seems to have the final rotations hard-coded.  It's just a complex way of delivering one specific pose, and doesn't really help pose anything effectively given the start and end points.

So I'm kind of stuck, right now, with the curve-posing concept.  I'll see if more Googling can help somehow.

Thanks for looking into this so deeply!  :thumbupboth:

Quote - I hate to set an actual limit.    Hmm.  I've added a status box which lists the script progress, since processing can apparently take some time.  The status box could actually list a warning if a chain of > 300 links is attempted, before running.  It could suggest that the Sections and Slices settings be reduced for a longer chain.

That sounds like a good idea. And perhaps my suggestion of setting a limit was not so good. Just because todays Poser running on todays machines tends to bog down on a thousand link chain, does not mean that tomorows systems will.

Quote - Which reminds me.  I'm curious about what might be the most optimized low-res chain the script can create.  I think if Sections is set to 10 and Slices is set to 4, that might make something low-res which could work well in the background of a scene.  Hmm.

I've been wondering about thet myself. On a related point, I'm not sure about the default ratio between Sections and Slices. At the default settings the curve of the link looks quite smooth even close up, but viewed from the end a section through the link looks quite angular. Perhaps the default Slices should go up, or the default sections come down.

You mean, viewed edge-on?  I think I see what you mean.  If I raise the Slices setting to 12, that smooths it a bit, but the resolution is higher, per-link.  Lowering the Sections setting to 28 doesn't seem to give bad results.

But I'm not exactly sure what you mean.    I'm happy to change the defaults.  The current defaults for these values are just retained from the loop-making script, where they may make more sense (much like the per-ring UV mapping).

I think the real problem with the Sections is the way the spacing of the vertices of the link is working out.  If you look at the innermost ring, the vertices are evenly-spaced.  With the outer ring, however, they're scrunched in the straight areas and stretched in the curves.  I'm trying to think about how I can alter the ring rotation handling to place the scrunching in the center ring, not the outer ring.  This is something else which is less troublesome in the loop script than here.

Quote - So I'm kind of stuck, right now, with the curve-posing concept.  I'll see if more Googling can help somehow.

Like I said before, I'll see if that paper will improve what can be used for the initial guess, if it does so much the better, but either way I'll look into tidying up the code I already have (the solver bit is only about 60 lines but it's mixed in with drawing and window init code for P8)

As you can see from the image, curve A is smoother than curve B (end on view).

Perhaps the default sections should be cut down to 28, so the smoothness is a closer match whatever the angle of view. I'm not saying that curve A and B should be the same smoothness, just that they should be slightly closer.

Quote - Like I said before, I'll see if that paper will improve what can be used for the initial guess, if it does so much the better, but either way I'll look into tidying up the code I already have (the solver bit is only about 60 lines but it's mixed in with drawing and window init code for P8)

Ah!  Sorry.    I didn't realize that's what you were doing.  Thank you!   :thumbupboth:

Quote - As you can see from the image, curve A is smoother than curve B (end on view).

Perhaps the default sections should be cut down to 28, so the smoothness is a closer match whatever the angle of view. I'm not saying that curve A and B should be the same smoothness, just that they should be slightly closer.

Okay.  That's what I thought you meant, but I wasn't sure.  I'm happy reducing the default for Sections to 28.  :thumbupboth:

Yes that looks like a big improvement.

From the point of view of the shape and keeping mesh small, the straight parts don't need Sections, but I don't know how hard it would be to get rid of them, or the problems it might cause with the mapping.

I don't think it would be hard to get rid of them.  I think I could just use the convex hull, without placing the evenly-spaced marker points, before generating the rings.  This might spoil the ability to set a controlled number of sections.

The main trouble would be with the mapping.  I can try adding the sparse link type as an option, if you want it.

Here's an update which applies the improved section spacing and changes the default for Sections to 28.

Quote - This might spoil the ability to set a controlled number of sections.

The main trouble would be with the mapping.  I can try adding the sparse link type as an option, if you want it.

Saving polygons is always good, but, sounds like the downsides outweigh the up sides. Choosing the number of sections is handy, and you don't want to mess up the mapping. If its an either/or, probably best leaving it as is, but if it can just be an option, it would be handy.

Quote - Saving polygons is always good, but, sounds like the downsides outweigh the up sides. Choosing the number of sections is handy, and you don't want to mess up the mapping. If its an either/or, probably best leaving it as is, but if it can just be an option, it would be handy.

It can be an option.  I can still make it respond to the changing value for Sections, but unless I come up with a different approach to it, the actual section count won't always be correct, and the links won't necessarily end up with symmetrical vertex placement.

So I'll definitely add it.  I may be able to come up with a way to refine it before releasing it. 

Quote - > Quote - Like I said before, I'll see if that paper will improve what can be used for the initial guess, if it does so much the better, but either way I'll look into tidying up the code I already have (the solver bit is only about 60 lines but it's mixed in with drawing and window init code for P8)

Ah!  Sorry.    I didn't realize that's what you were doing.  Thank you!   :thumbupboth:

As math isn't exactly one of my strong points either, it did take quite a while to get to where I'm at now (a few years going by the timestamps) but the solver is only a few months old.

Quote - As math isn't exactly one of my strong points either, it did take quite a while to get to where I'm at now (a few years going by the timestamps) but the solver is only a few months old.

Well, golly.  :blushing:  I tend to assume everyone knows more than I do, as I've said.  :lol:  You're worlds beyond me, and I appreciate your input in all of this.  :thumbupboth:  I hope I've learned a good deal since 2005, when I started scripting, but I still have a very great deal to learn.  Sorry to have specifically called on you, with the catenary questions.  I thought it was a topic of special interest to you and that you were hoping for a chain-posing or chain prop-making tool which would give results as close to mathematically-correct as possible.  I would, too, if it's feasible.

I don't suppose there's any way the script could try to alter the Frame of Reference, to be able to make use of the assumption that the lowest point on the curve lies at the world origin?  It seems like that would end up distorting the X proportions, so the problem would no longer be working from -1 to 1 on X.  Or it could be equivalent to altering the a input, maybe?  The problem is already going to be approached as 2D, using the XY plane, then transformed back into 3D space once solved.  Would it hurt to try to change the proportions of X and Y to control Y, then transform the scaling along with the translation and rotation at the end?  The loop script already does a great deal of that sort of thing.  (I'm not sure, but possibly this is something like what your code would end up doing?  )

I may still be thinking about the catenary problem in the wrong frame of reference.  :unsure:

Thank you for all of your input!  :woot:

Cage, thank you much for your generosity. This script will be very usefull.  Thanks to Les, nruddock, ockham and others as well.

Cheers,
Mike.

Quote - Cage, thank you much for your generosity. This script will be very usefull.  Thanks to Les, nruddock, ockham and others as well.

Thanks, phantom3D!  :laugh:  Glad to see you back!

Brad is looking fabulous, BTW!  :woot:

This adds the "sparse" link type requested yesterday, by lesbentley.  I've managed to preserve the Sections handling for this type of link, as well as correct the UV's for the disproportionately long polygons.  (See attached.)  The UV solution for the "per-ring" UV mapping may be a bit tacky, I dunno.  In order to correct the squashing created by the ring-tiling on the long polys, I had to extend their UV's beyond 1.0 on v.  I'm sure this is probably frowned upon, but it does texture stretching, giving a final result with the correct proportions.