Rigging Follow Curve IK Madness
7250 18 1
-
- traileverse
- Member
- 355 posts
- Joined: Nov. 2015
- Offline
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).
hou.f*ckatdskmaya().forever()
-
- anon_user_37409885
- Member
- 4189 posts
- Joined: June 2012
- Offline
-
- traileverse
- Member
- 355 posts
- Joined: Nov. 2015
- Offline
-
- jsmack
- Member
- 7736 posts
- Joined: Sept. 2011
- Online
-
- traileverse
- Member
- 355 posts
- Joined: Nov. 2015
- Offline
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.
hou.f*ckatdskmaya().forever()
-
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
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.
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.
Edited by anon_user_89151269 - April 16, 2018 05:55:51
-
- traileverse
- Member
- 355 posts
- Joined: Nov. 2015
- Offline
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?
hou.f*ckatdskmaya().forever()
-
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
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.
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.
Edited by matthias_k - April 21, 2018 04:36:01
English is not my native language, sorry in advance for any misunderstanding :-)
-
- traileverse
- Member
- 355 posts
- Joined: Nov. 2015
- Offline
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.
hou.f*ckatdskmaya().forever()
-
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
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.
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.
Edited by matthias_k - April 23, 2018 03:41:22
English is not my native language, sorry in advance for any misunderstanding :-)
-
- traileverse
- Member
- 355 posts
- Joined: Nov. 2015
- Offline
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.
hou.f*ckatdskmaya().forever()
-
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
-
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
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.
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.
Edited by anon_user_89151269 - April 23, 2018 12:25:05
-
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
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.
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.
Edited by matthias_k - April 23, 2018 15:28:55
English is not my native language, sorry in advance for any misunderstanding :-)
-
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
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.
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.
Edited by anon_user_89151269 - April 24, 2018 03:23:09
-
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
-
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
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.
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.
Edited by anon_user_89151269 - April 26, 2018 07:13:53
-
- matthias_k
- Member
- 483 posts
- Joined: Dec. 2006
- Offline
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…
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…
English is not my native language, sorry in advance for any misunderstanding :-)
-
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
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
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
-
- Quick Links