|
that means that the end of the chain won't be exactly where your
controller is, which is one of the main advantages of IK in some
situations, and it will still allow over-extension when animation is
blocked out quickly.
if all you want to avoid is the pop at the alignment moment, then you
can easily do that with a double chain (driving chain a iota shorter
then the deformers/visible chain), or with some scriptwork, and preserve
the consistancy between effector and end of bone.
******************************
| Raffaele Fragapane |
| Rising Sun Pictures |
| "Remember, TD is for TopDog" |
******************************
Hans,Veenendaal,AMplus R&D,SOJ wrote:
Add an additional null to the chain. Put the effector animation on
that null and use that to control the 'real' effector of the chain
through an expression. This expression should take into account the
chain length.
The replacement effector can overextend (Go further away than the bone
length), while the expression will makes sure the bone slows down its
extension when nearing full extension.
If you set full extension to be about 1.2 times the actual bone
length, then you animator will have full control while it is not
difficult to animate.
+------+------+***+
R E N
------ = chain.
**** Distance between controlling null and effector
For distances smaller than the chain length the position of the Null
and the effector should almost be the same.
This method will influence IK only and you can still blend with FK.
Hans.
-----Original Message-----
From: owner-xsi(at)Softimage.COM [_mailto:owner-xsi(at)Softimage.COM_]
On Behalf Of Raffaele Fragapane
Sent: Tuesday, October 18, 2005 9:28 AM
To: XSI(at)Softimage.COM
Subject: Re: slow down hyper-extension
Brad, know that much, but I must be stupid and I can't see
how you could resolve a 2 bones chain, which is essentialy a
triangle, any differently from how it's solved now.
I can think of several things, from the old school 2bones
chain controlling a slightly longer 2bones chain, to several
gimmicks to track the motion of the effectors, but all of them
fall out of the IK solver category, some of them usually
pissed off animators, and most of them make blending FK and IK
a nightmare.
could you describe a different solver to deal with this please?
******************************
| Raffaele Fragapane |
| Rising Sun Pictures |
| "Remember, TD is for TopDog" |
******************************
brad wrote:
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
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
text in body:
unsubscribe xsi
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
|
