Hi
Thanks for the tip on getLocaltoVworld() :-).
I was thinking about the general technique behind CCD and I thought of
something. If you have a chain of bones pointing towards an effector, why
can't you use simple trigonometry to rotate the chain?
For example, take a chain with 1 DOF and 1 bone, pointing towards an
effector. If you move the effector, you can calculate the angle you need to
rotate the bone using cosines. Construct a triangle, with one leg going from
the base of the bone to the tip, and another going from the base of the bone
to the effector (the orientation that will minimize the error is always the
one where the line from the bone base to the tip points directly at the
effector) . The angle seperating them can be calculated by
angle = arccos(basetotip/basetoeffector)
and from there you can generate a 2*2 rotational matrix using that angle.
Then, since you constrained it to 1 DOF, you transform only the two
coordinates of the bone that can be changed. For example, pretend that you
are looking at it straight on. The z coordinate cannot change; only the x
and y coordinates. So, you apply the 2*2 rotation matrix to the x and y
coordinates.
Then, if you have more than 1 DOF, you repeat from a different view. For
example, if you use a side-on view, the x-coordinate cannot change, just y
and z. You repeat the process, generating another 2*2 matrix which you use
to transform the y and z coordinates. (the y coordinate should already be in
the correct place, so that part of the matrix should be an identity)
Then you have the coordinates for the new position of your bone!
Now I know that there is more than one solution for arccos. But, first of
all, we only need to consider one complete revolution in either direction;
from -2 PI to 2 PI
And, using the coordinates, we can determine the quadrant which the rotation
falls in, so there is really only two solutions for the angle; a positive,
counterclockwise rotation and a negative, clockwise rotation.
First, we will check the constraints of the joint to see if one is
eliminated. Then, if there are still two, we take the one that requires the
least amount of work, whichever angle has a smaller absolute value.
When you have more than one bone, you can do your subsequent iterations by
calculating the length of the legs of the triangle using the distance
formula. The rest of the process remains the same.
Performance-wise, there are a lot of square root and arccos calcualations
that need to be performed for each frame of animation, but current methods
involve calculating complex matrices and/or derivatives?
What do you think of this process? Is there some fatal flaw that I
overlooked? Will this be slower than current methods?
-B.D.
>From: Fred Klingener <[EMAIL PROTECTED]>
>Reply-To: Fred Klingener <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] IK and Skeletal Animation
>Date: Tue, 26 Jun 2001 01:24:17 -0400
>
>From: "Bob Dengle" <[EMAIL PROTECTED]>
>Sent: Monday, June 25, 2001 7:45 PM
>
>
> > Hi.
> >
> > Thanks for the info. I was busy seaching graphics and game
>development sites
> > for articles on inverse kinematics hoping there was
>information on CCD. :-)
> >
> > The best resource i came up with was Chris Welman's PhD thesis
>on Inverse
> > Kinematics. It discusses methods for implementing an ik
>system, but there
> > isnt any source to go with :-(. It can be downloaded in .ps
>format from
> >
> > ftp://fas.sfu.ca/pub/cs/theses/1993/ChrisWelmanMSc.ps.gz
>
>Yeah. Welman's paper remains one of the best and most
>comprehensive treatments. But don't go looking for source.
>Fact is that you probably don't want to. Java 3D will do much
>of the work for you, and much of the ugly little detail that the
>C++ and *gag* Javascript programmers have to wallow in we can do
>with a couple of calls to getLocalToVworld().
>
>To make it work, you mark the scene graph nodes that you want to
>coincide, run the forward kinematics with your dependent
>transforms set at the initial guess, and then you can get the
>error (as a Transform3D) with a couple of getLocalToVworld()
>calls, an inversion, and a multiply. Of course, you have to
>take apart the resulting Transform3D to get the displacements
>and the angles. Then, if you're using any of the
>derivative-based IK routines - building the full Jacobian or CCD
>for example - you can approximate the derivatives that you need
>directly on the scene graph by tweaking each of the dependent
>joints and measuring the changes in the error. (They come out
>as the columns of the Jacobian.) What you do with them from
>there on depends on your system and your goals.
>
>I have no idea how this approach compares performance-wise with
>a hand-coded system or how much of it gets done on hardware, but
>the economy of expression is certainly attractive.
>
>I did this for a simple one-degree-of-freedom, one
>pin-constraint, determinate system in
>http://www.brockeng.com/VMech/IK/IKSG.PDF . Because the example
>system is so simple, I finish by simply inverting the Jacobian,
>but the front half setup is applicable to any of the
>Jacobian-based systems or CCD, for example.
>
>Cheers,
>
>Fred Klingener
>Brock Engineering
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff JAVA3D-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
