I was sure this had been covered somewhere, but searching the forum for "chain" mainly produces info on IK chains. There doesn't appear to be a properly working example anywhere in my library either.

When rigging a chain, there's an inherent problem in that one rotation centre per joint won't do. If the chain extends along the X axis for example, Y rotation requires the joint centre to be in a different place than does Z rotation.

The answer would seem to be to place the centre to suit one rotation axis, then use ERC to compensate for the other. I've tried it, but it's more difficult than it first appeared. Some of the ERC linkages apparently need to respond to the absolute value of the rotation angle, and I can't work out how to do that.

ERC gurus, your input would be welcome.

If you aren't an ERC guru and don't have the faintest idea what I'm banging on about, load up a posable chain from your library and try both rotation directions while zoomed in on the link in question. In one direction at least, the link will pass through the adjacent one. In some examples neither direction works properly, but we can discount those... On the other hand, if you have a chain that works properly in both directions, let me know which one it is so I can see how it was done. ;)

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2798819&page=5#message_3628475

We covered chain rigging in the thread on Cage's loop making script (somewhere around the linked post).

Thanks, I knew I'd seen the subject discussed somewhere, but couldn't remember where.

Download Cage's chain_maker4b.py. Create a short chain, orientated on the y axis, and examine the resultant cr2. I designed the template cr2 that the chain maker uses, it's so long ago now that I forget the details, but I think it works something like this. The key to the whole thing is the two extra translateY channels in each link. These act much the same way as the normal 'Offset' channels. One translateY moves the effective origin of the link, then a rotate channel rotates the link round the new "origin", then the other translateY puts the origin back where it was to start with. The rotate channel sandwiched between the extra translateY channels changes depending on the orientation of the link. In the first link it's the rotateZ, then in the second link it's rotateX, then in the third link it's back to rotateZ, and so on, alternating for each link. In this system the order of the channels in the channel stack is very important.

Uh-huh. I was working my way through VK's definitive work, but can't claim to understand it well enough to apply it from scratch on my own. If I have something to copy I might stand a chance. :-) 

The chains made with the chain_maker do not actually use ERC, at leas not in respect to the centers of rotation. There is ERC, but it is only used to bend the chain. The trick with the moving centers of rotation is done by the two extra translateY channels, and does not involve any ERC.

When a translate channel is above a rotate channel, the rotation happens from the point at which the item was before the translation was made. The chain links exploit this fact, using one translate channel to move the link, then rotating it, then using a second translate channel to move the link back where it was to start with.

Here's something that might help you get a feel for it. A modified Poser box prop that has most on the normal channels removed for the sake of simplification.

Load the Test_Box in Poser, use only the very bottom yTran dial, and then try the zRotate dial. Note that the rotation works as per normal. Now Restore the prop (Ctrl+E), the two extra yTran dials will now have none zero values. Try the zRotate dial again, note that the prop now rotates round a different center. Now swap the sign of yTran_A and yTran_B, note that the rotation center has changed again. This is the same thing that happens with the chain, only a lot of none essential stuff has been striped out so that you can see the nitty gritty.

The value of yTran_B defines the offset for the center of rotation relative to the props normal origin, the value of yTran_A should always be set to the inverse of yTran_B.

P.S.

Only channels between yTran_A and yTran_B will be affected by the changed center of rotation.

It's a bit ironic really! This business relates very closely to the previous thread "prop rotates around origin, not its center". There we were trying to cure the problem, here we are trying to deliberately cause the very same "problem", because the mechanism that caused that problem, is the very same mechanism that is used to cure this one. Namely the effect of the channel order in the channel stack.

It's beginning to make sense. I did try a chain from chain_maker to see what its rigging was like, but I made my chain along the X axis and it didn't work well. I now see that the rigging magic only works with Y axis chains. If I rotate the rigging that should serve as a template.

VK's tank track rigging thread did cover the channel stacking concept, although he used ERC as well. It's all rather daunting. ;)

How's it going with the chain Bob?

Attached are a couple of example three link chains, one layed out in the x+ direction, the other in x-. This time I did use ERC, as it makes it easier to change the offset for the second center of rotation. It's easier if you are trying to find the correct location by trial and error. The control channel is in the Body actor.

I think they are rigged correctly, but I have not tested extensively. The channel stack should be the same for every alternate link, the even numbered channels should all have the same channel stack as each other, and the odd numbered channels all have the same channel stack as each other. With the only difference apart from the alternating stack being the origin and endPoint for each link (at least I think so).

Your right about the chain_maker not producing the correct rig for chains made on the x axis (perhaps for z as well, haven't checked). I never noticed that (or had forgotten). Again it's a channel order thing. With chains made by the chain_maker on the x axis, in the even numbered links, the the extra translate channels each need to be moved moved up one slot, so that it is rotateZ that is sandwiched in-between the extra translate channels. In the odd numbered channels they need to be moved down one slot, so that it is rotateY that is sandwiched between them.

I also found that I had not used the correct offset for the second rotation center, the value was a little too large. For the default chain it should have been -0.006 and 0.006, not -0.007 and 0.007.

No! There is still something wrong with the chains from my last post. If you use a combination of yRotate and zRotate in link1 the chain breaks. :(

OK, think I've got them working correctly this time. Fingers crossed. Had to change the rotation order.

Thanks Les. I'll give that a try later on.

As to the position of the rotation centers, it seems to me that they need to ba based on the inside radius of the links. Assuming a vertical chain with the first link at the bottom, one axis of rotation would be at the center of a circle drawn at the inside top of the link below the link in question, the other at the inside bottom of the link in question itself. These two axes are equidistant from the point where the two links touch. In chains produced by the chain_maker the bottom axis is the real origin, and the top axis is the "fake origin", though I suppose it might just as easily be done the other way round.

Messing with the rotation orders of the chain links, I realize just how little I understand about rotation orders and how to set them appropriately. At the moment my method is pure trial and error. I may see if I can make something to shed some light on this.

Quote - ...one axis of rotation would be at the center of a circle drawn at the inside top of the link below the link in question, the other at the inside bottom of the link in question itself.

I've been fiddling with this off and on, so far without any real understanding or, indeed, success. I've examined the chain you posted, Les, but although I know where I want my two joint centres to fall, and I can see the corresponding centres in your chain, I can't seem to work out what figures need to be plugged in to what channels in order to bring that about.

I'm trying to rig an existing chain, so I don't have any freedom regarding the geometry. I'd have had it done by now otherwise. :)

How many links are there in the chain?

Attached Link: http://www.daz3d.com/i/shop/itemdetails/?item=12483

Five altogether. I'm re-rigging the handcuffs from Flipmode's *Cuffed (In A Suspicious Cellar)* set. I added a new ERC rig to the old original Zygote handcuffs some time ago, for my own use. I'd had to re-make the geometry, so distribution would have been a problem, but then DAZ solved the dilemma by taking the cuffs off sale.

So I decided to tackle these instead. As you can see, the joint centres will need to be different for the non-opening cuff parts which effectively form the end links of the chain.

I'll figure it out eventually. ;-) 

Off-topic, I'm also making some conforming fuzzy covers. I never thought I'd find myself making conforming clothing for handcuffs, but some people expressed an interest in them.

They'll be pinker in the end, of course. :D 

I think I'm getting it now. I'm just taking a break before too much CR2 editing makes my brain explode. :)

Quote - The trick with the moving centers of rotation is done by the two extra translateY channels, and does not involve any ERC.

I took that statement literally and ignored all the ERC in your example, Les. That was my fundamental mistake, because the RotOffset ERC is needed to determine the offset value that's going to be plugged into the extra translateX channels. I need a different value for some links than for others, and the links' dimensions aren't round numbers of OBJ units, so getting the values right is a bit more work; but I think I may be on the right track.

If I understand the process sufficiently when I've finished, I'll write some notes on how it's done. 

Yesss... I think I have it all worked out now. Here's the new rigging, along with some of the ERC controls in action. Most of the Y rotation ERCs have equivalents which rotate in the Z axis, apart from the cuff opening of course.

Now the proof of the pudding is if I can apply the same procedure to a new chain and have it work. Then I'll have the basis for a tutorial. 

Here's a close-up of the chain part in operation.

BRAVO Bob! that looks really excellent. :thumbupboth: