Hi all, The follow curve IK is giving me very limited results and a lot of glitching and flipping bones and unpredictability. Whats the secret here to getting predictable results? I was just expecting it to behave like spline IK in Maya. Problems Highlighted in the attached file (scrub timeline to see animation).

Your line has no normals, so it flips

Hello Fuos, thanks for the response, could you go into a bit more detail as to how this works?

I checked it out, it seems like it flips because it has normals. When I deleted “N” the flipping went away.

jsmack
I checked it out, it seems like it flips because it has normals. When I deleted “N” the flipping went away.

Yeh the normals causes the flipping like fuos said but the flipping isn't the only problem, it has this glitchy feel to it where if you pull the top pathCV down the bones seem to freeze for a moment and they stop following the curve then they twitch and start following the curve again (see attached gif). Its weird behavior to me. But when I draw my own curve using raw SOPs (NO shelf tool) it works fine, but now I would have to develop my own custom twisting as well.

The solver has a harder time evaluating the bones' position when the curve's bent to this extreme position. It might be an inherent math limitation or an implementation issue, I don't know of the top of the mind.

If you rotate the base CV 90deg towards the other null, the glitches will disappear.
Of course you should also set “no normals” (or delete them a priori if you prefer) in the InverseKin chop to eliminate flipping.

inhiding
The solver has a harder time evaluating the bones' position when the curve's bent to this extreme position. It might be an inherent math limitation or an implementation issue, I don't know of the top of the mind.

If you rotate the base CV 90deg towards the other null, the glitches will disappear.
Of course you should also set “no normals” (or delete them a priori if you prefer) in the InverseKin chop to eliminate flipping.

Yeh true. maybe @MichaelGoldfarb can share some thoughts on this?

You have to make the “pathcv1” look at the end point
or rotate it, your problem is in my opinion the
“pointing upwards pathcv1” all the time.
or maybe resample the curve…

enable “Enable Contraints” on pathcv1 to have the look at…
and/or play with the Scale Z on pathcv1.

matthias_k
You have to make the “pathcv1” look at the endpoint
or rotate it, your problem is, in my opinion, the
“pointing upwards pathcv1” all the time.
or maybe resample the curve…

enable “Enable Constraints” on pathcv1 to have the look at…
and/or play with the Scale Z on pathcv1.

Thanks, matthias_k, however, still not getting the kind of results I was expecting, it just doesn't feel stable enough as it is. I'll be doing a lot of extreme cartoony poses and the follow curve (or my lack of understanding of the follow curve) is worrying for me. Coming from Maya, the spline IK functionality is what I expected. See gif for how Maya solution behaves.

like in the attached file :-?

in your gif the “mid” point has a far better position,
which avoids the “curve to small” problem.

uh, forgotten to say: crtl points should have a proper
ending nummer for the right order, if you like to add them via
match pattern: ../../curve_crtl_pnt_*
and make sure that: “Pack geometry before merging” is
enabled in the “object_merge” node.

matthias_k
like in the attached file :-?

in your gif the “mid” point has a far better position,
which avoids the “curve to small” problem.

uh, forgotten to say: crtl points should have a proper
ending nummer for the right order, if you like to add them via
match pattern: ../../curve_crtl_pnt_*
and make sure that: “Pack geometry before merging” is
enabled in the “object_merge” node.

Thank you, this is much more like the behaviour I was hoping for albeit without the twist, But I think I can figure that out using some lookat constraints. I did try a setup like this using the origin expression but that wasn't giving great results either. Using packed geometry to bring in centroid point is nice. Thanks again matthias_k.

Maybe add normals?
Adding normals to the nurbs curve should work, too.

I think we ought to clarify when you need normals and when you don't, unless we want to confuse the heck out of some unfortunate soul looking into the spine creation issue and stumbling upon this thread.
In my tests, when the follow curve solver cares about the curve's normals, it's a cause for bone flipping.

edit: My setup [vimeo.com] was not exactly like your setup Matthias, so if we manage to deductively extract a general rule from all these cases, it would be helpful for everyone interested in rigging.

Scrub the time line and watch the bones flip. Go at the solver and change it to “No Normals” and scrub again - no flipping.

Hi inhiding,

many thanks for the hints :-)

I think it is good idea to have control over the bone
direction. This means that we need some normals
or other attributes to control it. One question
is maybe: what is the desired direction for the bones?

If you create the curve via PathCv, then the direction/normals
should be controllable via PathCv rotation.

Maybe another solution is to have a null to control the
normal/bone direction + additional ramp.

Another try which should be stable.
Play the animation to see it moving.

That's a very nice setup!
Two things:
I've managed to brake it by moving on YZ the locked on X null (swing if you can), just a little, not too extreme.
Another, is this curve rig works well in some cases, but for realistic humanoids or any creature that is not upright (spine on horizontal) there's a needed for a bit more flexibility, therefore a spine has to have two ctrl nulls (a la XSI) which is better for this case as it allows independent twisting at chest and hip level.

So, trying to extract the essence from here, I'd say that in general when you're rigging this curve in order to be used as a spine, you don't necessarily need to have manual control over bones' orientation (vertebrae twist progressively only a bit in relation to their upper and lower neighbor), but you need to have them stable as in keep their initial rotation. In this situation, from what I've managed to test thus far, curve normals are to be avoided.

I'm sure we'll know more as we encounter various situations in real projects, as these tests, although do provide some insights, are rather dry when compared to what you actually need when you start rigging some real organic or mech, so we, or at least me, won't know for sure what's the best approach beforehand.

me, won't know for sure what's the best approach beforehand

me, too :-)

I just did a test with a “torso” piece of geometry and it seems like I was wrong: “no normals” for the follow curve solver is not the best option, because as I said earlier, vertebrae have to rotate progressively.

For a human spine, if the upper torso (rib cage) rotates on Y, the vertebrae on the lumbar region barely rotate, or not at all in the case of the first one or two right on top of the sacrum. Having the four ctrl CVs (two inner CVs parented to the end ones) will allow a gradual transition regarding each vertebra's rotation in relation to its neighbors, while the solver is set to take into account curve normals (best guess option).

The problem with “curve normals” is that in some poses where the curve twists rather intensely, bone flipping will start to occur.*

It would be cool if Twist Affector wouldn't be greyed out when the solver type is Follow Curve.
Of course with the current implementation of the solver it wouldn't probably work and the idea that's rattling around in my head right now is that if it were possible to have a twist affector, it would be cool to have it per bone, similar to a blend constraint, so I can use a normalized blend value between the two twists (inner CVs). This could very well be one of the worst ideas ever.

In terms of what it can be done with the available tools, I think in the case of my setup, it's best to control the curve's normal at each individual CV. I'm currently doing just that - figuring out what the best way of achieving that might be. Tweaking the initial CV rotation (by going inside CVs and changing the normal in the - deprecated - point SOP, something which might be totally unnecessary, not sure yet) has given me very good results, the exception being the cases when you translate the inner CVs so that they cross “the other side” of the curve.

*Now that I've played with this while visualizing the normals and the results, I surmise that translating the inner CVs should be done reservedly or not at all.

hmmm,

https://www.sidefx.com/forum/topic/52347/#post-235545 [www.sidefx.com]
Please have a look here, too.
Another usecase.
I have to get deeper into this…

Checked them - simple and efficient setups.
I especially like the one that mimics volume preservation of the neck or whatever that is, but if you'd use that for a realistic character/animal you obviously can't use the arclen expression to drive the capture region's length as a fraction of the curve length.
For cartoonish setups, like the chicken in the video, it works perfectly.
Please do get deeper into this