Here is the tutorial i've posted for the "Awesome Spine" setup. Let me know what you think?
Awesome Spine (http://faithofthefallen.wordpress.com/2008/10/08/awesome-spine-setup/)

http://faithofthefallen.files.wordpress.com/2008/09/4.jpg

edwardG

10-08-2008, 08:25 PM

Interesting.

Step 8 has some serious grammatical errors in it, and it took awhile to get what you were saying with regards to that.

I think overall it's a good tutorial, but you left out one important aspect of it; the "why".

There are a lot of steps and I think it might be very good to preface some of the longer parts with a reason why you are doing the following steps. For instance, I'm still not 100% sure why the locators are created... is their primary purpose to keep the spine from flipping, or are they meant to be grabbed by the user for more control as well?

Small things like that. I think it will be an excellent tutorial to point people to who have questions about rigging an IK spine.

mberglund

10-08-2008, 08:32 PM

You make some very good points, i'll go about editing the tutorial. Thanks for pointing that out.

To answer your question about the locators, they are there for the poleVector constraint so you control the twisting of the spine by an individual bone basis. And this is good so you can twist 180degrees without flipping. That is the high level reason for the setup to get a stable twist out of the spine.

eek

10-09-2008, 01:44 PM

can it bend 90 degrees forward, back or sideways whilst twist 180 degrees? Looks like you essentially doing mid-point interpolation for the twist.

mberglund

10-09-2008, 02:01 PM

I did some tests on a skinned version and it does. here are some pics.

Now thats a nice rig! - great work! Now I must assimilate it into max. :drool:

mberglund

10-09-2008, 09:15 PM

I often redo rigs from Maya into Max. I'll give it ago and post what I come up with :)

archanex

10-09-2008, 09:31 PM

could you post the scene file so I can try it out before investing time in going through the tutorial? Thanks

blackseraphim

10-10-2008, 05:44 AM

very generous man... :D
i read your blog and would you pleeeaaasssseeee add a squash and stretch.
i have a question though:
would your "awesome spine" be applicable in arms?
again tnx man!

mberglund

10-10-2008, 01:21 PM

Sure, thing! I'll add the tutorial on how to make it squash and stretchy.

It is applicable with arms, I tested it out when I got the spine working, there is only a few changes that have to be made. I can make that a tutorial as well if you would like.

Also, i'll try to post the .ma file as soon as I can.

eek

10-10-2008, 04:17 PM

More test, sorry I just want to verify the rig of its 'awesomeness' (which it is btw :)):

Successive Twists

test 1
With the chest/shoulder control rotated forward 90 degrees, and twisted 180. Do the same with the hip so the twist is back to 0. Then rotate the chest another successive +180.

Im testing if the chest and hips can twist in +180 steps continuously without having to rotate the main torso control. Do the same with negative twist -180.

cheers,

mlefevre

10-12-2008, 05:31 PM

Hey mberglund,

I wrote a script, (more of a macro) to setup your spine, giving the user a choice of joints. (just to learn more of MEL than anything else).

But it seems that on occasion, a spine built with the script will flip after 180 degrees of rotation. If I rotate the shoulder or hip control, the flipping is sometimes eradicated, and it won't ever flip again if I set the controls back to 0.

Let me see if i understand you... sometimes when you build the Awesome Spine it causes the joints to mess up temperately?

I haven't really noticed this before, but I haven't setup the spine before using a script yet. Sometimes when you add the RPsolvers to the spine_#_bind and poleVector constraint them it will cause the joint to flip because it has to twist around to look at the poleVector, if that happens you can always enter 180 or -180 in the twist attribute of the ikHandle of the joint that is flipping, to get its rotation back to zero.

mberglund

10-13-2008, 01:51 PM

More test, sorry I just want to verify the rig of its 'awesomeness' (which it is btw :)):

Successive Twists

test 1
With the chest/shoulder control rotated forward 90 degrees, and twisted 180. Do the same with the hip so the twist is back to 0. Then rotate the chest another successive +180.

Im testing if the chest and hips can twist in +180 steps continuously without having to rotate the main torso control. Do the same with negative twist -180.

cheers,

If i understand you correctly then these images should answer your question, i hope... :)

It might be hard to make out the forward direction of the chest and hips, but if you rotate the chest 180degrees and then counter rotate the hips 180degrees the entire spine now faces backwards, without rotating the root control.

http://faithofthefallen.wordpress.com/files/2008/10/test1.jpg

http://faithofthefallen.files.wordpress.com/2008/10/test21.jpg

eek

10-13-2008, 07:30 PM

Nice, pretty much correct:

I've spent many years looking at different spine methods, it in the end falls into two categories: tentacle and spine.

With a spine you really want twist of 180 along the z plane or y in maya. With 90 degrees in each other - this is synonymous with how the wrist works. I spent a long, long time trying to get it to work, finally ending up with something I call a wrist cradle where by one quaternion dictates the rotation for another quaternion to ride on - which itself can be spherically interpolated to allow deformations. E.g The wrist joint bones dictate the rotation for the deformation of the wrist to ride on. Where as with the shoulder you only need one quaternion dictated by a direction, this is because the twist that naturally happens is a safety mechanism designed to keep you upper arm mounted in its shoulder cradle without tearing out - twisting the upper arm back is the resolution of this natural twist - or the spin of the quaternion.

mberglund

10-13-2008, 07:59 PM

ummm... interesting. I would love to see an example of the wrist cradle you're describing. :)

eek

10-14-2008, 12:36 AM

Yep, I'll try and post some notes on it. The other method I got working was duriac method which basically allows for a twist of -360 to +360. I only have it working fully in one direction though - so good for tentacles, where your only moving tangent handles. In theory I might be able to get it to work with the cradle idea allowing for 360 degrees of freedom in one direction and 720 in another. But its complicated as your basically tracking an axis through multiple quaternions, across the quaternion hemisphere.

SeanC

10-14-2008, 03:29 PM

very nice setup.. initially i got a problem with locator groups 1 and 5 rotating along with locator group 3, (the top and bottom locators were getting exactly half of the rotation from the shoulder or hip).. I changed the pma operation from average to sum for those two locator groups and it works fine.. any ideas?

Let us know when the squash/stretchy tutorial goes up!!

:applause:

this would make one tasty script!..

thanks for the knowledge, learned a lot

MolemanSD7

10-15-2008, 09:17 PM

For instance, I'm still not 100% sure why the locators are created... is their primary purpose to keep the spine from flipping, or are they meant to be grabbed by the user for more control as well?

They're used as pole vector constraints for the individial ikRP solvers. So, basically up vectors the the ikHandles.

Interesting setup...I'll have to take a gander at it more in depth later.

Chinwagon

10-16-2008, 02:53 AM

What's the difference between using IK handles with pole vectors on a two joint chain and using aim constraints with the locators as position based up nodes?
Would aim constraints make the setup quicker to update as it only has to calculate rotation?

I guess what makes the above 180/below -180 degree twist possible is that it's calculating the twist based on two distinct Y rotation values, instead of using world transform values. The benefit of this method is the obvious twisting ability but the downside would be possible incorrect twist results when the controls are in gimbal lock and that the twist wouldn't happen if there was rotation applied to a parent of either control.

Of course, this is just in theory. I haven't actually used the spine. Don't get me wrong; I like it.
:¬)

uiron

10-16-2008, 08:24 AM

could you please put a download of a sample scene?

MolemanSD7

10-16-2008, 03:35 PM

Interesting setup...I'm not sure all the IK chains are necessary though. I'm looking into something similar to this now. I'll let you know if I get anywhere.

MolemanSD7

10-16-2008, 08:47 PM

It seems like a pretty solid setup. I like the idea of the splineIK driving the bind skeleton...avoids the cycles while still allowing 'fk' control for the actual spine. Nice idea.

------------------------ HOW TO MAKE IT SQUASH AND STRETCH ---------------------

blackseraphim: i read your blog and would you pleeeaaasssseeee add a squash and stretch.

I managed to implement the squash and stretch feature to it too...pretty simple overall. I'll try to outline it below. I used translation manipulation to adjust the scale of the joints, and not the actual scale attribute, but the technique should be applicable either way. This just makes for fewer connections to make to see the final result.

First thing to do, is to select the splineIK curve. In the command line or script editor, type "arclen -ch 1;"

This will create a curveInfo node that will store the length of the curve. With the infoNode still selected go into the hypergraph > input/output connections view.

Create a multiplyDivide node by going under the Rendering Menu > Create Render Node. In this menu, go under the Utilities tab and click on multiplyDivide. If this doesn't show up in the hypergraph window (as it doesn't in mine) Shift-select the curveInfo Node, and go under the Graph menu of the hypergraph, and click Rebuild. This will now display the curveInfo and multiplyDivide node.

Whether in the connection editor or the hypergraph, connect cuveInfo1.arclen to multiplyDivide1.input1X

Open the attribute editor for the multiplyDivide1 node, and type the value from input 1 into input 2. Set the function to divide.

The output will now be normalized. So we can connect this to a multiplyDivide node to control the X translation of the joints (simulating their scale in length).

So, to do this, create another multiplyDivide node, select the first multiplyDivide node, shift-select the second, and open the connection editor. Connect the outputX of multiplyDivide1 to the input1X of the multiplyDivide2 node. If you select the multiplyDivide2 node now, and open the attribute editor, you should see input1 has a value of 1.

Select any of the ik or bind joints, besides the root or first joints, and find their translateX value. Type that value into the multiplyDivide2's input2X window.

Now, just go through and connect the outputX of multiplyDivide2's node to the translateX attribute for the spine_2+_ik joint and the spine_2+_bind joints.

Hope this helps! Have fun with it.

mberglund

10-16-2008, 09:09 PM

What's the difference between using IK handles with pole vectors on a two joint chain and using aim constraints with the locators as position based up nodes?
Would aim constraints make the setup quicker to update as it only has to calculate rotation?

Those are good questions. Well, Using RPIKHandles does a few things. 1) it leaves the rotations open for manipulation if i need to get to them. 2) I parent the ikHandles to the spine that is driven by splineIK, so it inherits both position and rotation. You can use Aim Constraints but then you would have to use point contriants to get the spine_#_bind to follow the spine_#_ik. And then you end up haveing an aim constraint and a point constraint for each joint. The transforms inheirted through parenting is much faster then through constraints. I personally think its easier and quicker to setup then two constraints. 3) This is just person perference, but i perfer using IKHandles rather then aim constraints. its just me :)

Feel free to try it with two constraints and let me know what you think.

Polimeno

10-17-2008, 01:25 PM

really nice thread mberglund !

tell me, this kind of spine can strech/squash ??
and please, if you can, post some animations tests showing more about your spine.... i´d like to see it working in some motion.

hey eek, can you show us some aproachs and craft notes about doing such thing in max ?

thanks folks.

Buexe

10-17-2008, 01:59 PM

the spine set-up looks very good, have you tried it with different rotaqtion orders in action? In my experience spine set-ups can also be sensitive to rotation orders...

mberglund

10-17-2008, 02:02 PM

the spine set-up looks very good, have you tried it with different rotaqtion orders in action? In my experience spine set-ups can also be sensitive to rotation orders...

That's probably a good test to do. Thanks, I will definitely do some testing with rotation orders.

MolemanSD7

10-17-2008, 04:09 PM

So, I've been pretty excited about this spine setup. I've added some modifications to it. The squash and stretch I mentioned in a previous post. But, I also added a mid-spine control to really push the curve. I made a little tutorial for it and posted it on my blog. Kudos to mberglund for the inspiration and creativity. I hope you don't mind my additions...

you should really add a download to finished scene, so we don't have to recreate the setup just to see how it works.

MolemanSD7

10-17-2008, 04:25 PM

Here's my finished scene. I hope mberglund doesn't mind. If you do, let me know and I can try to take it off this post.

Its for maya 8.5

Everything is visible, so be careful not to break it. Only select/move the circle controls and the big joint in the middle.

tonytouch

10-17-2008, 04:52 PM

this looks great - i will try this out soon ... :)

thnx for sharing the technique

uiron

10-17-2008, 05:06 PM

thanks a lot, moleman.

if moleman's setup is working 100% , there's quite some issues i don't like about this whole setup.

first... i take top controller and move slightly to the side. the default shape is wrong.
http://img142.imageshack.us/img142/2646/spine1ui5.jpg

the expected behaviour is this - i had to "fight" the rig by adjusting middle controller to get the wanted shape.
http://img225.imageshack.us/img225/525/spine2cg5.jpg

second. i don't like the idea that by rotating "shoulder" rig does not align spine shape exactly to the controller - in really extreme poses shoulders will feel very separate from the chest area. problem of all spline-based spine setups i guess.
http://img78.imageshack.us/img78/1343/spine3tb0.jpg

third. rotating hips and shoulder from the default pose alter overall length of spine, making it stretch by default - to keep volume, animator will have to fight the rig again by adjusting controllers' positions, but still, interpolation between poses will still look weird.
http://img357.imageshack.us/img357/3254/spine4md3.jpg

i don't know, maybe i'm just not a fan of spline based setups, and from animation point of view - not really liking the IK style spines.

MolemanSD7

10-17-2008, 05:21 PM

Some of those issues were just from my mid control joint. I'm still playing with the overall controls. To get back to the original spine, except for my squash and stretch additions, just delete the mid control joint, and see how you fair.

mberglund

10-17-2008, 07:03 PM

I just posted the file on the tutorial page HERE (http://faithofthefallen.wordpress.com/2008/10/08/awesome-spine-setup/)

I had to upload it as a .doc, but when you download it just change the extension to .ma (saved using maya2008).

This version of the file has squash and stretch, so when you pull the chest way out it gets thinner in the middle and when you bring the chest in real close to the pelvis it bulges out in the middle. Generally you only want scale a joint if its direct children wont be animated, otherwise you could get shearing, But in this case the child is the skinned geometry, so its ok.

Thanks everyone for checking it out and offer suggestions, and way to make it better. I hope to post the squash and stretch tutorial soon. What MolemanSD7 posted is pretty close to what I did, i just added some more for the thinning and bulging.

Thanks MolemanSD7 for your interests and contributions!

MolemanSD7

10-17-2008, 09:56 PM

uiron: "i don't know, maybe i'm just not a fan of spline based setups, and from animation point of view - not really liking the IK style spines."

What kind of setup do you prefer?

tonytouch

10-19-2008, 09:37 AM

@uiron:

you can easily "aimConstraint" the middleJNT_GROUP , towards either shoulder or hip control .

@mberglund:
i like the whole setup , i was having a look at it yesterday - and it is interesting to see , that you are using "average" in plusMinusAverage-Nodes ( i never used "average" and always wondered , what this is doing - so now i learned a very interesting new thing ... so far i did not rebuild the aweasome-spine by myself yet , but i will do , within the next 2 weeks )

i ( also ) did never like splineIK-setups so much , because of the endJoint ( in stretchyMode ) these POP in most rigs ... but i know , there es an easy workaround for this - and now as i take a look at your setup , i guess i will use more splineIKs in the future - especially , if they are twisting like this multi-IK-setup . ( so this might definetely change my opinion about splineIKs )

... but i guess i will need some time , to adapt this method and THEN find out about the stability of it - so far it REALLY looks "AWESOME" from moving around the controls and having a look in the OUTLINER - the method described here it is a TINY AWESOME addition of a regular advanced-twist-splineIK-setup , that makes SplineIK_setups much more powerful - e.g. when rigging the neck of a giraffe or tails and tentacles )

thanx a lot for sharing this technique :)

have a nice sunday

PS:
i use ribbon_spines in most of my rigs ... later i attach a deformer-skeleton to it , in some cases add a bit of a volume-preservation , and it ends up in a nice joint_chain ( e.g. for baking out animation in one skeleton-hierarchy . but it is always good to see alternatives in rigging .... you can do it this way or that way - but it is good to know as many different methods - so in each case you can decide ...

uiron

10-19-2008, 10:06 AM

the biggest drawback of IK spines is that while they seem to be easy to pose, they interpolate between poses in a linear fashion and it looks very unnatural, even with added in-betweens. The difference to FK based setups is minimal in things like walk cycles (and even here FK spines have advantage with arc-like interpolations), but try animating something agressive, like, falling on the floor - you'll be amazed how frustrating IK spine can be.

tonytouch

10-19-2008, 10:39 AM

hi uirion ,

you are totally right about IK_controls for spines .

good is , to having some sort of blendable setup for both IK and FK_controls . ( flexible setups )

i think ,
mberglunds setup is more about the splineIK itself , rather than about the IK_controls - i am pretty sure , you can adapt the spline-IK-construct ( multi-IK-chain ) and build different control-systems around it . that way , you can ( e.g. use blenshapes for driving the ikSplineCurve in 2 different states FK and IK )

( here in my short testing phase , there occured no flippings when twisting the spine more than 360 degree , so i think the technique itself is very interesting , and thats why he called it awesome-spine / because of the awesome twisting and not because of the IK-system built around it - in the exampleTutorial )

rock on ...

mberglund

10-19-2008, 03:21 PM

the biggest drawback of IK spines is that while they seem to be easy to pose, they interpolate between poses in a linear fashion and it looks very unnatural, even with added in-betweens. The difference to FK based setups is minimal in things like walk cycles (and even here FK spines have advantage with arc-like interpolations), but try animating something agressive, like, falling on the floor - you'll be amazed how frustrating IK spine can be.

I understand what you are saying about the IK Spine being harder to get arcs. But if you applied that same logic to the rest of the rig, then you wouldn't use IK arm or legs because they suffer from the same problem. IK is generally translated so getting arcs is tougher, but the reason we have IK arm, legs, and spines is because we need them. With out IK planting limbs would be really hard. The IK Spine allows for independent control of the hips and shoulders, which an FK system wouldn't allow.

I think animators and TD's need to be aware of the problems of both and use fk and ik accordingly. In the file that I uploaded, if you go to the layers panel and make the fk controls visible (a blue color) you can control the IK spine in an FK fashion. The FK controls are exactly to my liking yet, but they work. I had an animator use them that wasn't familiar with translating spine controls, and he liked this simple fk attachment best.

eek

10-19-2008, 04:49 PM

the biggest drawback of IK spines is that while they seem to be easy to pose, they interpolate between poses in a linear fashion and it looks very unnatural, even with added in-betweens. The difference to FK based setups is minimal in things like walk cycles (and even here FK spines have advantage with arc-like interpolations), but try animating something agressive, like, falling on the floor - you'll be amazed how frustrating IK spine can be.

I see your point, but I'd argue that you can control the length of the bones along the spine to stop the bones essentially stretching, or flipping/popping/crunching - they just overshoot the spine - setups dont usually have this and ive only seen it in Isners or mine. Blending between two or more poses still retains an arc.

Secondly a splineIK type spine has superiority in dealing with counter rotation - trying to adjust the hips whilst keeping the chest locked would be pretty hard, and in fk mode lots of keys.

It would be neat to treat an FK rig like IK when you needed to pose it or vice versa.

I think the issues your seeing are fault of the rig - not splineIK in general or that type of rig. You definately need to keep a 'clean' shape through the spine and have top and end bones match there controls - else it gets very frustrating. Essentially you want to keep natural 's' shapes but have the control of splineIK/etc.

uiron

10-20-2008, 07:23 AM

I understand what you are saying about the IK Spine being harder to get arcs. But if you applied that same logic to the rest of the rig, then you wouldn't use IK arm or legs because they suffer from the same problem.

difference between IK arm and IK spine is major one. while you need IK on the arm/leg for the obvious purpose - keeping hand/foot contact while moving chest/shoulder/hips around, i can't think of an everyday situation where you would want to fixate hips and chest to two different transform spaces, or independed to each other.

if animator is moving arm freely in space, he switches to FK to get arcs, right... spine is mostly ALWAYS moving freely in space, this implies that FK-like setup should be default for spine. having IK option is nice, ofc, but still, every IK/FK switch adds that bump in trajectories which needs an additional animator work to get that transition happen smooth.

anyway, I'm not trying to prove myself right and everyone else wrong, that's just my own personal preference.

archanex

10-20-2008, 07:47 AM

I agree with you 100% uiron. IK spines are like IK fingers, great for very specific situations, but most of the time, extra work

That said, this is an impressive IK spine. However I had a hard time getting making it go from being straight into a bent over C shape naturally

oh and BTW, thanks for posting your file whoever that was! :D

mberglund

10-20-2008, 02:24 PM

difference between IK arm and IK spine is major one. while you need IK on the arm/leg for the obvious purpose - keeping hand/foot contact while moving chest/shoulder/hips around, i can't think of an everyday situation where you would want to fixate hips and chest to two different transform spaces, or independed to each other.

if animator is moving arm freely in space, he switches to FK to get arcs, right... spine is mostly ALWAYS moving freely in space, this implies that FK-like setup should be default for spine. having IK option is nice, ofc, but still, every IK/FK switch adds that bump in trajectories which needs an additional animator work to get that transition happen smooth.

anyway, I'm not trying to prove myself right and everyone else wrong, that's just my own personal preference.

I kind of see your point better. I've definitely known some animators that just like FK only, probably because it simple. I think the best reason to use an IK Spine is to reduce the amount of counter animation. For example, if you have the upper spine in just the right pose, but you want the lower spine to change a small bit. If you’re using FK you would have to change the joints from the top of hierarchy down, this would mess up your upper spine pose. And I know to some animators that they hate this. I think a rig should probably contain both FK and IK for the spine, as well as some way to snap them to match position and rotation.

But really what it comes down to is, what do your animators want? If they like simple FK, then your job is easier.

edwardG

10-20-2008, 02:57 PM

Truthfully, you need both IK & FK in the spine in order for it to have complete functionality.

IK does much more than just stick in space, it provides independant Hip action from the shoulders, which you'd be quite suprised how much you do it. One example is in "Idle" animations, where you're standing still but shifting your weight from foot to foot and your hips will switch to put the weight from one foot to another. IK also allows quick counter-animation that you simply cannot achieve with a traditional FK setup. Interestingly enough, you need an IK setup for reverse FK spine arcs as well (think Surf's up where they wanted to rotate the lower half of the body while keeping the upper half upright, or a Skateboarder doing tricks, etc).

The FK is important because it allows for very natural bending arcs that are too difficult to achieve with the IK alone. Any arcs you try to do in IK will have to be counter-animated and it's way too dificult to eyeball it.

IK fingers are far more specialized and I would only use them in a shot specific rig (unless of coarse there was a frequent need for the IK fingers otherwise, but this is still project specific). I don't think that's a good comparision to the usefulness of the spine, because to me they are apples and oranges.

I will say, however, that many animator's that I've talked to will use FK controls more than IK controls, so I completely understand the points that are being made. If they had to pick one or the other, they would probably go with the FK setup, but they admit that having both is ideal.

*EDIT* I was writing this post before the previous was completed.

You don't need a blending feature, I like the Art of Rigging's setup which gives you both IK and FK control simultaneously. It's been the most useful spine I've seen so far.

uiron

10-20-2008, 03:32 PM

IK does much more than just stick in space, it provides independant Hip action from the shoulders, .

FK setups can, and should have this feature as well. The simpliest one, for example, is having hip and shoulder controls in same transform space (e.g., center-of-mass space), independed to each other, and spine bones interpolating rotation between these two (first bone oriented to hip, second 90% hip 10% shoulder.... untill last bone 0% hip 100% shoulder).

i usually set up spines similar to this with three FK controls, middle one being adjuster when you want to get S shapes instead of C shapes.

you might say "but this does not make sure your chest stays in place when you move hips". yes, it does not, but most of the time you don't need to have your character stick to the air anyway. if you animate, for example, weight shifting from one leg to another - you make two poses, one with weight on left leg, another one on right leg, you as well move hips to the side or invert spine's S shape so the character looks stable in those two poses.

EDIT: here's a short test of an FK spine. i just made key poses, the rest is done by default.
http://www.vimeo.com/2016841

in a good FK setup the "how much you need the chest to stay in place" is controlled solely by key poses.

eek

10-20-2008, 04:17 PM

you make two poses, one with weight on left leg, another one on right leg, you as well move hips to the side or invert spine's S shape so the character looks stable in those two poses.

Doesnt this just defeat the idea of economy of keys? You want both controllability and efficency on a rig. Really you want both - ik/fk and the ability to quickly change poses without repositioning/rotating everything again. Now how you acheive this is another story.

edwardG

10-20-2008, 07:04 PM

FK setups can, and should have this feature as well. The simpliest one, for example, is having hip and shoulder controls in same transform space (e.g., center-of-mass space), independed to each other, and spine bones interpolating rotation between these two (first bone oriented to hip, second 90% hip 10% shoulder.... untill last bone 0% hip 100% shoulder).

i usually set up spines similar to this with three FK controls, middle one being adjuster when you want to get S shapes instead of C shapes.

you might say "but this does not make sure your chest stays in place when you move hips". yes, it does not, but most of the time you don't need to have your character stick to the air anyway. if you animate, for example, weight shifting from one leg to another - you make two poses, one with weight on left leg, another one on right leg, you as well move hips to the side or invert spine's S shape so the character looks stable in those two poses.

EDIT: here's a short test of an FK spine. i just made key poses, the rest is done by default.
http://www.vimeo.com/2016841

in a good FK setup the "how much you need the chest to stay in place" is controlled solely by key poses.

I understand that you're able to do it, but the whole point of the IK spine is to avoid the counter animating that you're talking about. I watched animators do well with both types of setups, but they were able to produce animations quicker with the IK/FK rig.

eek

10-21-2008, 02:39 AM

Researching some of the issues with spine setups especially with a splineIK method is that if the tangent direction at the top and bottom isn't the same as the controls dictating that direction you'll get flipping.

You can only in my opinion have two methods, firstly by dictating the direction of the curve via position, and not worrying about maintaining the tangent direction, because you veto'ing the issues of rotating the controllers. With this method you can bring in methods such as +360 to -360 degrees of twist.

Or secondly you maintain explicitly the tangent direction at the top and bottom, and allow the controllers to rotate and move. The shape of the curve always follows from the direction of the hips to the chest, even if the bones stretch or maintain a set length - the latter can cause drifting on the controls.

I think the issues arise when your try to mix these two methods together - a third mid controller seems then to be introduced to iron out these problems. But in doing so adds another layer of complexity - it essentially becomes the counter-rotation/position.

riggo

11-05-2008, 08:15 PM

mberglund,
about the stretch/squash spine. I'v tried downloading your latest version from your site but no dice with openning the file. could you write down what you did to make it stretch? are you keeping the setup the same just adding some other constraints or is the spine partially rebuilt.
thanks.

mberglund

11-24-2008, 05:06 PM

mberglund,
about the stretch/squash spine. I'v tried downloading your latest version from your site but no dice with openning the file. could you write down what you did to make it stretch? are you keeping the setup the same just adding some other constraints or is the spine partially rebuilt.
thanks.

did you rename the extension of the file? i saved it as a .ma so if you dont have Maya2008 you can edit the file. open up the .ma file in a text editor then change all occurrences of 2008 to whatever version you are using.

I still plan on posting a "True" squash and stretch tutorial. but in the mean time... I mainly just add onto the already built spine. I use utility nodes to calculate the squash and stretch for the spine_ik and spine_bind joints, then connect them too scale XYZ.

riggo

11-24-2008, 06:59 PM

thanks amberglund. i think i have an idea of how you make it stretch. I found this tutorial online: http://www.darksuit.com/tutorials/StretchSpine.html

ramiro3d

12-19-2008, 04:10 PM

I often redo rigs from Maya into Max. I'll give it ago and post what I come up with :)

Mberglund thanks for shareing!!, could you redo this spine in Max? could you post it? Thank you very much!

pixar012

02-18-2009, 11:26 AM

Thanks so much for the tutorial mberglund! But I was wondering... is it possible to apply this to cartoon arms/legs? Because I want to make a cartoony arms and legs that twist, bend, and stretch.

I tried using this elastik solver plugin but it doesn't work on my computer, sadly. T^T

mberglund

02-19-2009, 12:27 AM

Oh yeah, its totally possible to apply it to arms and legs. You need to tweak it a bit since you don't need independent twist from both sides. Example: the twist for the bicep starts at the elbow and propagates up so the shoulder gets a rotation of zero. the same with the forearm.

theflash

02-21-2009, 09:44 PM

It's a really nice & clever setup. Strangely this rpIK idea was used in Inside Maya 5(!) book in chapter 17. And it was named "Divine Spine Setup".

Thanks for sharing.

Keithtron

03-20-2009, 05:24 PM

Thanks for the killer tutorial! I've scripted this setup, and it's almost done and working, but the pole vectors are behaving kinda weird.

My spine bones have a consistent orientation... y points to the next bone, z points forward, and x points left. I have all the PV locators directly in front of the character, and once the pole vectors are constrained the bones get all twisted like crazy. In order to straighten out the mesh, I have to twist these locators around so that every other locator is behind the character, and the other half of the locators are to the left of the character. Pretty weird. I've tried placing my locators on all sides of the character, but it still has this wacky twist problem. Any idea what could be causing it? Thanks in advance for any input!

MolemanSD7

03-20-2009, 06:04 PM

Could you post part of the script. There may be some flags or something you're missing in there during the setup. Otherwise, There was a part in the tutorial where he mentioned that the PV could be negative or twisted somehow if I remember correctly. You'd have to go in and change them if they are. Check for that part in the tut. In your script have it look for those specific attributes and if they are the flipped version of what you want, just reverse them. That's all I can think of for now.

mberglund

03-20-2009, 06:09 PM

It could be were the IK is expecting the PoleVector to be, instead of twisting the locator around to the back, go to the twist attr on IKHandle and type 180 or -180, I've had to do that sometimes. because it expects the poleVec to be behind but you want it in front so you have to counter with the twist value.

But because your scripting you want something consistent, maybe run a joint orient first, or build the joints in the side viewport or some type of hackery...

Keithtron

03-20-2009, 07:20 PM

Yeah, ideally I'd like to avoid needing to go in there and mess around too much after the script execution. I want to make this as much of a one-shot script as possible! I'm not generating any bones in my script though. Generating a skeleton is very character-specific, whereas generating the controls on the skeleton is usually very similar from character to character, so that's the part that I'm scripting, with a nice UI and everything.

Rather than running a joint orient in the script, I'm just manually ensuring that the spine joint orientations are all nice and lined up and consistent before running my proc. I'd like to think that a consist joint orientation would yield consistent behavior in the IK's and PV's. I guess I'm not entirely sure how pole vectors work though... when you're using an rpIK on just 2 joints, how does it decide what axis to point at the pole vector? It doesn't seem to have a specific up-axis or anything like that to work from. In my case, for half of the joints, it's pointing the z-axis at the PV locator, and for the others the x-axis points at it. It seems like there must be some way to control this. Hmmm....

Would just using the twist value on the spline IK work, in place of the pole vectors on the IK handles? I'm playing around with it as we speak, not sure if it's a workable solution or not. I assume if it was that easy, you would've used that yourself!

Keithtron

03-20-2009, 07:41 PM

Ok, so it definitely helps if I generate these PV locators behind the character. Half of them keep the corresponding joint un-twisted and stable. But the other half still need to be rotated around to the character's left side to maintain the proper initial state. And it's every other one too, not random or anything. Very weird, I'm not sure where the difference is coming from.

mberglund

03-20-2009, 07:48 PM

Can you try setting a preferred angle for the joints before the script. or if your script doesn't want to touch the existing joints, create joints with the script then point and orient constrain the existing joints to them. Thats probably a crappy solution but if your in a pinch.

Or just make sure they dont skin their mesh yet, then you wont see the twisting.

Keithtron

03-20-2009, 08:05 PM

Fixed! I just had to freeze my joint orientations before running the script. Problem solved. :cool:

Now I just have to fix the very top joint, since it's getting double rotations, but that should be pretty straightforward to fix. Gonna script in a stretchy toggle as well.

EDIT: Just in case anyone's curious or runs into a similar problem, I fixed the over-rotations on the top joint by just orient constraining that joint to the top control joint. I'm not saying it's a mistake or flaw with the Awesome spine in general, but my implementation is slightly different, so I surely introduced the problem myself.

Keithtron

04-08-2009, 03:40 PM

I've finally almost finished my script for a slightly modified version of this setup, including attr's for stretch amount and volume preservation amount. However, I've run into a bit of weirdness... and I've come up with a workaround for it, but I'm still curious as to what would be causing it.

When the stretch and volume preservation are turned off, the orient constraint on the top joint seems to work just fine, and looks stable so far. But as soon as either the stretch or volume preservation are turned on, the top joint gets some weird and wacky rotations. The stretch/preserve just scales the ik/bind spine joints, except for the top joint, which is not scaled at all. Is this a known issue? Scaling parent joints can cause weird rotations on its orient constrained children? Or maybe there's something I should be approaching differently.

The workaround I came up with is to replace the top joint of the bind spine with a dummy joint, so that I can remove the top bind joint from the skeletal hierarchy. Then I point constrain that bind joint to the dummy bind joint, and orient constrain it to the top control joint. At a glance it seems like a decent fix, so I'll go ahead and incorporate that change into the script and play with it some more. I was just hoping to avoid that change if there's a cleaner alternative solution.

uiron

04-08-2009, 03:59 PM

Is this a known issue? Scaling parent joints can cause weird rotations on its orient constrained children?

yes. to reconstruct that, you can simply make two-joint chain, orient the second one to some locator and scale the parent one, more extreme scale values (2.0, 0.5) break orient-constraint behaviour.

from what i understand, that's caused by joint's scaleCompensate mechanic. joint's parentInverseMatrix (used by constraints) doesn't take that into account. workaround is adding an extra bone in hierarchy(imagine hierarchy A->B->C, orientconstraint on C, scale A : works perfectly), or manually constructing inverse parent matrix for the constraint.

read more here, it's a topic i started when i found out about that problem myself: http://www.highend3d.com/boards/index.php?showtopic=255463

mberglund

04-08-2009, 05:12 PM

What you are referring to, is what happens in Max and Maya (NOT XSI) when you scale an object with a child. It has to do with matrix math and the scale values mixing with the rotations. XSI doesn't suffer from this problem because when they do the matrix math, they remove the scale values, replace them with all ones, do the calculations then put the original values back in.

This effect is called shearing, i believe.

Keithtron

04-08-2009, 07:22 PM

Interesting. Do you know if there's any justification for the behavior in Max and Maya? Any reason for it behaving like that? Or is it just a straight-up bug?

I got it working, scripted and all. Thanks for the help guys! :thumbsup:

mberglund

04-08-2009, 09:44 PM

No its not a bug, thats how the math works out. Really XSI is the only software that I know that takes extra steps to change it. XSI's math has extra steps involved, but the speed might be negliable.

So because of this shearing effect CHaracterTDs (myself included) try not to scale anything unless they know that the child wont be animated. If thats true then you can get away with scaling.

So stuff like the leg stretch I use the TranslateX attr to stretch. It takes a bit more work but I dont have to worry about scale.

uiron

04-09-2009, 07:45 AM

well, dunno... take a look at this file: http://www.neglostyti.com/media/other/orientfix.zip
see the IO graph of the "parent_matrix_correct". what i did there is constructing ANOTHER matrix for orient constraint that takes into account inverseScaleValue of the joint. orienting now works fine even if the parent is scaled. either it's close to behaviour actually what you're told about XSI, or i just constructed the correct parent inverse matrix.

one thing i know is that this fix didn't work for aim constraint:]

uiron

04-09-2009, 07:48 AM

So stuff like the leg stretch I use the TranslateX attr to stretch. It takes a bit more work but I dont have to worry about scale.

but then the skin deformation will look different than scaling..

eek

04-09-2009, 03:08 PM

No its not a bug, thats how the math works out. Really XSI is the only software that I know that takes extra steps to change it. XSI's math has extra steps involved, but the speed might be negliable.

So because of this shearing effect CHaracterTDs (myself included) try not to scale anything unless they know that the child wont be animated. If thats true then you can get away with scaling.

So stuff like the leg stretch I use the TranslateX attr to stretch. It takes a bit more work but I dont have to worry about scale.

We take care to keep our matrices orthogonalized - i'd rather see whats truely happening than another process to fix the natural sheering. Even max doesnt 'truely' show matrices correctly - for that you'd need to use houdini.

Its all about scaling non-uniformaly because scale in each axis is the unit length of each axis in a matrix - its quite elegant as your encapuslating everything. Rotating is bound by the direction of scale and scale is bound by the length of the rotations direction i.e there the same, there both bound a direction and spin defined by three axis'.

If you wanted to do the scale method its quite easily really, all you would do is this get the current scale as a matrix and normalize each row except for position. Then take the difference as a magnitude for your attribute.

Follow Us On:

The CGSociety

The CGSociety is the most respected and accessible global organization for creative digital artists. The CGS supports artists at every level by offering a range of services to connect, inform, educate and promote digital artists worldwide. More about us on TheArtSociety.com