I'm not sure I entirely understand what you mean with "slowing down the
rotation".
There's a few things that need to be detailed before you do something
like that.
If you translate an IK effector at constant velocity away from the chain root, the rotational acceleration of the two IK joints increases according to the tangential relationship. Because of this, as the effector reaches the full distance from the root, the two IK joints seem to pop.
For many animators, regardless of skill or control preference, animating with standard IK solvers can be irksome, especially if they are spending a lot of time dealing with setting keys near the effector distance limit. The big advantage of IK over FK is supposed to be the notion that you can get more animation done while setting fewer keyframes. As we are all aware by now (I hope), fewer keyframes to finished animation == many $$$ in the economics of large productions. The reality for many top tier animators is that they end up being forced to set tons of keyframes anyway, just to maintain better control over the IK performance. So if both control options, IK or FK, result in forcing you to set many keyframes to better control interpolation, it's time to think about a new interpolation model. It would be worth investing $$ if you end up saving $$$$.
Related Side Note:
I am starting to think (and will be formulating a request to Softimage) that we need to explore another direction in the area of IK that will better facilitate a future of experimental and eventually improved solver models. We need to ween ourselves from a dependence on the prepackaged, all in one, iconized IK chains that have been our animation bread and butter since their amazing introduction in SI|3D.
In XSI, IK chains are quite powerful, but they are also unfortunately quite bulky, and a lot of the bulk is superfluous most of the time. I've rigged enough advanced creatures now to have a general sense of how many IK chains I average per character and what the performance impact is from all the extra bulk, and it's somewhat expensive. Hopefully there's a way to abstract IK behavior into an operator or constraint that kills two birds with one stone. Ideally, we could reduce the expense of IK chain performance, and we could also reduce the expense of animator frustration with existing solver behavior.
-Brad
-------Original Message-------
one is at what point that is introduced in the workflow.
doing it with FK would entirely defeat the purpose of FK and take away
the control that makes it good when it's needed.
if you only do it on IK chains then you need to staple at least a few
things.
can the lenght of the bones be affected? or does it need to remain constant?
if it can't be affected then you're already ruling out 2bones chains in
IK, because given one root, one effector and one upvector there's only
one possible solution to that chain's IK.
if you do it with chains that have more then two bones then it can be
done, at least partially, without touching the lenght by changing the
stiffness of the elements (it will prevent 2 or more bones from lining
up, or line up certain bones first, before the chain is fully extended),
but it could be tricky, and you'd need to carefully reverse engineer
exactly what the stiffness values do in the IK solver.
Also XSI's solver for 3+ bones chains is pretty good in my experience,
and it seldomly, if not ever, will line and lock sections of the chain
before you reach full extension.
if you want a length based one then it becomes simplier, and all that
needs to be done is adding a target which will be driving the effector
and, given a roof for the length, increase the length according to the
distance between the target and the root in whatever way you want,
probably by a quadratic progression.
the other thing to figure out is if you want the animators to see it and
control it, or if it's a post animation process.
if it's a post animation process then it gets even easier, and all you
need to do is read rotations and/or positions and change some Fcurves
accordingly, but this could potentially change some of the finest
details in the animation.
all in all it doesn't seem like a very convenient rig helper to be
honest, at least in my opinion.
in my experience animators usually want as much control as they can get,
and the best thing to do is giving them monitoring tools, rather then
trying to change the way they work and rigging in such a way that they
are being babysitted forcefully.
Things like changing the colour of icons or bones when values enter a
potentially dangerous threshold, or write a simple Fcurve
parser/validator that will correct or at least report potential issues
with the animation are much more animator effective usually, unless you
are setting up a sweatshop kind of pipeline with 100 animators that is,
in that case you'll probably need a lot of patience, babysitting rigs,
and probably a portable flamethrower and some gasoline to soak the
buggers with.
******************************
| Raffaele Fragapane |
| Rising Sun Pictures |
| "Remember, TD is for TopDog" |
******************************
Kris Rivel wrote:
>
> When I was at Siggraph, I was watching a presentation on the rigging
> and animation of Madagascar. They were showing how they modified a
> bones rotation so that it slowed down when approaching hyper
> extension. Anyone know how to do this in XSI?
>
> Kris
>
>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
