mcjAutoLimb 2014, an IK system for animators now with poles - For DS 1, 2, 3, 4

Mortze

Hello y'all.
I'm sorry in advance if this was already explained before but my english is not the best.
I downloaded the script and tried it with no success. Here is what I intend to do and what I've done:

I intend that character B mantain his hand on character A's shoulder as A moves (walks).

1 - I created a null and parented it on A's shoulder, then selected the null as Target and B's hand as Targeter. Hit the script and hit "do it". B's arm assumed another position automaticly, not on A's shoulder, and when I moved A's shoulder B's arm didn't move at all.

2 - I created 2 primitives and parented one to the sohulder and the other to the hand. Did the same procedures with the script and had the same results. The hand did not follow the shoulder movments.

As a fun fact, the script created a forearm node.

Can anyone explain the noob I am how can I do to have A's hand follow (be pined) to B's shoulder as it moves?

Thank you!

Pennyfarman

I think I found one of the bugs, it is not the script itself, it is Daz. I was playing around with scripts "AutoLimb", and noticed that when changing the deceleration/acceleration to "Linear" after the scripting, it throws everything out of whack. That tells me Daz key framing is not stable. Maybe the acceleration/deceleration has something to do with things not looking right? I sent email to Daz support to find out why every key frame forces to acceleration/deceleration to default. I want to be "Linear" by default. That way you can loop the animation anyway you want. Repeat the transformation anyway you way it. Most importantly rotate the objects in consistence motion. In 3D Studio Max, the default interpolation is "Linear", if you want to accelerate it or decelerate it, then you tell it to do so. Daz is the opposite! Maybe the scripts depends on Linear motion to make it work right???

mCasual

baldorvadras said:

Hello y'all.
I'm sorry in advance if this was already explained before but my english is not the best.
I downloaded the script and tried it with no success. Here is what I intend to do and what I've done:

I intend that character B mantain his hand on character A's shoulder as A moves (walks).

1 - I created a null and parented it on A's shoulder, then selected the null as Target and B's hand as Targeter. Hit the script and hit "do it". B's arm assumed another position automaticly, not on A's shoulder, and when I moved A's shoulder B's arm didn't move at all.

2 - I created 2 primitives and parented one to the sohulder and the other to the hand. Did the same procedures with the script and had the same results. The hand did not follow the shoulder movments.

As a fun fact, the script created a forearm node.

Can anyone explain the noob I am how can I do to have A's hand follow (be pined) to B's shoulder as it moves?

Thank you!

the script solves the arm position for 1 frame or for each frame of an animation, it does not turn the arm into an automated arm.
so if you move the target after using the script, nothing special happens

when the hand doesnt reach the target it's usually because the target is out of reach or the limits imposed on the shoulder or foreArm rotations dont allow the script to do its job ( you dont see it on your screen, but the script does a series of attempts to pose the arm until the hand reaches its target )

when the hand doesnt reach the target, make sure the target is within reach or turn Off the limits on the arm joints

----

The steps to do what you want are for example:

animate Figure A walking from frame 0 to 300

and animate Figure B from frame 0 to 300 if she walks along

at frame 0 put B's hand on A's shoulder

create a null node at B's hand/wrist position, we call it the target

( this can be done very quickly and precisely using the mcjMakeTarget script )

parent the target to A's shoulder

select the target

add B's Hand to the selection

run mcjAutoLimb

as the timerange to process, select "current frame only"

click on the "do it" button

if the script was able to do its job, the arm will not move, because it's already reaching the targets, the joint rotation limits did not prevent it from working and the target is within reach

as the timerange, now select "playRange" ( frames 0 to 300 )

click on the "do it" button

for each frame of the animation, the script will compute the arm position required for the hand to reach the target

the arm-twisting should remain similar to what it was at frame 0

now the hand is at the correct position for each one of the 300 frames

but the hand orientation is not stable

to stabilize the hand orientation relative to the held shoulder, use mcjHoldOn

mCasual

odysseyowl said:

I think I found one of the bugs, it is not the script itself, it is Daz. I was playing around with scripts "AutoLimb", and noticed that when changing the deceleration/acceleration to "Linear" after the scripting, it throws everything out of whack. That tells me Daz key framing is not stable. Maybe the acceleration/deceleration has something to do with things not looking right? I sent email to Daz support to find out why every key frame forces to acceleration/deceleration to default. I want to be "Linear" by default. That way you can loop the animation anyway you want. Repeat the transformation anyway you way it. Most importantly rotate the objects in consistence motion. In 3D Studio Max, the default interpolation is "Linear", if you want to accelerate it or decelerate it, then you tell it to do so. Daz is the opposite! Maybe the scripts depends on Linear motion to make it work right???

mcjAutoLimb is not affected by the interpolation
since it keyframes the arm or leg rotations for 1 frame or for each frame over the time-range specified

after using mcjAutolimb, whatever you do is not governed by mcjAutolimb
so if you move the figure's hip 2 ft away, "nobody" is there to change the figure's arm to cope with this new situation

if you use mcjSetInterpolation to change the (usually) interpolation on the hip node to linear
note that any tweaking of the hip position will change the interpolation for that keyframe, back to its curvy interpolation

something i often do: when the hip movements are as i wanted them, i use mcjDecimate to "pin" the hip animation down.
Each frame of the hip animation gets keyframed and interpolation doesn't matter anymore

TimingisEverything

I have found an bug with this script. It works perfectly when figure is in Zero Body or Hip rotation, but once rotated It does not pose the limb correctly *tested with Genesis 2 figure*.

one more thing, I really liked the "spin angle" setting of the old Autolimb script. I would just use the old one but it doesnt contain a "Undo" function which can be messy, is there any chance this could be updated perhaps?

Testing6790

I'm sorry Casual, my brain is fried from training for work all week. I just read through all the thread and I THINK this is the case, but I want to ask just to be sure:

This can be used to keep two non-parented objects in sync during animation? As someone who does A LOT of manual animation... The thought of making that opening and closing door while spinning the handle boggles my mind.

mCasual

TimingisEverything said:

I have found an bug with this script. It works perfectly when figure is in Zero Body or Hip rotation, but once rotated It does not pose the limb correctly *tested with Genesis 2 figure*.

one more thing, I really liked the "spin angle" setting of the old Autolimb script. I would just use the old one but it doesnt contain a "Undo" function which can be messy, is there any chance this could be updated perhaps?

to give all the chances for the script to work it's better to set the ''limits off'' on the shoulder/thigh joints

if it's a case where the arm or leg needs to be fully extended
and the foreArm rotation has limits like -10 degrees to 135 degrees,
then it's better to change the limits to , say, 10 to 135
the reason being, if the arm length with the foreArm bent at -10 degrees is the same as the arm length with the foreArm
bent at +10 degrees, then the script will almost randomly select one or the other. which produces odd poses
( and since the knee would "point" back instead of forth, the leg will be painfully twisted )

the Pole vector is a bit hard to get used to, but needs to be understood, so make sure you read and re-read the instructions

often, i un-parent the pole vector from the figure's collar bone or from the Buttock joint
then i reposition it a bit, so that it's located where i want the elbow or knee to "point at"
and i carefully delete any keyframes on that pole vector, to avoid bizarre leg/arm twist animations

when you re-start the script, it looks for existing pole vectors and re-uses them instead of creating new ones
if you have two genesis figures in the scene, then the script may use a left over pole vector from the other genesis
so you probably should search for and delete old pole vectors in your scene before auto-limbing another figure

i'll see about the undo feature for the old AutoLimb,
it's easy to add that feature
but i also want to make it optional, because an UnDo for a 7820 frames animation can eat up a LOT of memory

( tip : if you attempt to load a 7820 pose-preset-animation (.dsa) and your PC freezez while the script eats up 1.8 gigabytes of memory, then open the .dsa file in Wordpad and delete the 2 lines that mention "beginUndo" and "finishUndo" )

mCasual

Paradigm67 said:

I'm sorry Casual, my brain is fried from training for work all week. I just read through all the thread and I THINK this is the case, but I want to ask just to be sure:

This can be used to keep two non-parented objects in sync during animation? As someone who does A LOT of manual animation... The thought of making that opening and closing door while spinning the handle boggles my mind.

the script computes the pose of a leg or an arm, so that the hand or foot reaches the specified target

it bends and unbends the elbow about 10 times until the arm length is exactly the one needed
then it re-orients the whole arm, by rotating the shoulder, until the hand touches the target

so in your case

1 - animate the door opening
2 - animate the door handle rotation
3 - at frame 0, place the hand on the handle
4 - at frame 0, create a null node (the target) and position it at the hand(wrist) position ( you can use mcjMakeTarget to do that )
4b - keyframe ( timeline(+) button ) the target
5 - parent the target to the door

so now mcjAutoLimb's mission is to keep the wrist at the position of the moving target over the frame range, 0 to 100

6 - select the target
7 - add to the selection the hand
8 - run mcjAutoLimb2014

now that the hand is at the proper location

use mcjHoldOn to keep the hand oriented the same way, relative to the handle

sice the handle twists, the hand should twist the same way

add the wrist rotation manually

-------
or
-------
you could have knuckle 1 of the mid finger track the handle, instead of the hand/wrist
if the handle is a lever
---------

Animation 1 the wrist follows a null node attached to the door

Animation 2 mcjHoldOn keeps the orientation of the hand, relative to the non-moving-knob, constant

Animation3- when the knob rorates, mcjHoldOn rotates the hand the same way, but obviously the
result is not what we intend - so it's more complicated

we create a null node, lets call it the handPivot

we position along the knob's axis

we parent it to the hand

we place our Target node at the same location and leave it parented to the door

mcjAutoLimb's mission will be to make the handPivot track the Target

also i think i animated the knob at the wrong times

TimingisEverything

Casual said:

TimingisEverything said:

I have found an bug with this script. It works perfectly when figure is in Zero Body or Hip rotation, but once rotated It does not pose the limb correctly *tested with Genesis 2 figure*.

one more thing, I really liked the "spin angle" setting of the old Autolimb script. I would just use the old one but it doesnt contain a "Undo" function which can be messy, is there any chance this could be updated perhaps?

to give all the chances for the script to work it's better to set the ''limits off'' on the shoulder/thigh joints

if it's a case where the arm or leg needs to be fully extended
and the foreArm rotation has limits like -10 degrees to 135 degrees,
then it's better to change the limits to , say, 10 to 135
the reason being, if the arm length with the foreArm bent at -10 degrees is the same as the arm length with the foreArm
bent at +10 degrees, then the script will almost randomly select one or the other. which produces odd poses
( and since the knee would "point" back instead of forth, the leg will be painfully twisted )

the Pole vector is a bit hard to get used to, but needs to be understood, so make sure you read and re-read the instructions

often, i un-parent the pole vector from the figure's collar bone or from the Buttock joint
then i reposition it a bit, so that it's located where i want the elbow or knee to "point at"
and i carefully delete any keyframes on that pole vector, to avoid bizarre leg/arm twist animations

when you re-start the script, it looks for existing pole vectors and re-uses them instead of creating new ones
if you have two genesis figures in the scene, then the script may use a left over pole vector from the other genesis
so you probably should search for and delete old pole vectors in your scene before auto-limbing another figure

i'll see about the undo feature for the old AutoLimb,
it's easy to add that feature
but i also want to make it optional, because an UnDo for a 7820 frames animation can eat up a LOT of memory

( tip : if you attempt to load a 7820 pose-preset-animation (.dsa) and your PC freezez while the script eats up 1.8 gigabytes of memory, then open the .dsa file in Wordpad and delete the 2 lines that mention "beginUndo" and "finishUndo" )

Hey, shoulder/thigh limits off did it!

Thankyou for your help Casual, you are a true hero in my book.

as for the Undo feature, why not limit the Undo capability to a certain amount of frames?

mCasual

so that's the result when the hand "pivot" follows the knob pivot, using mcjAutoLimb2014
then mcjHoldOn is used to have the hand seem to rotate the knob
then i had to tweak the animation of the 3 fingers

but i think what i should have done is
make multiple passes of mcjAutoLimb and mcjHoldOn, because they somehow interact
then the fingers could remain perfectly still and remain in contact with the knob

Testing6790

Thank you! That makes my life a lot more easy! Or harder. I stopped animating because it took so much time to do fine detail. This makes it easier which means I'll start again...

Quick question, though. Does it have to be frame 0? Can it be, say, 300 frames starting at frame 1000?

mCasual

Paradigm67 said:

Thank you! That makes my life a lot more easy! Or harder. I stopped animating because it took so much time to do fine detail. This makes it easier which means I'll start again...

Quick question, though. Does it have to be frame 0? Can it be, say, 300 frames starting at frame 1000?

yes the frame doesn't matter,
it's just less confusing when you work at the first frame of the animation segment

notably because the creation of the pole vector ( which later will govern the arm-twisting ) is created at the frame at which you launch mcjAutoLimb the first time

also by "setting shop" at the first frame and working mostly there, you reduce the risk of creating keyframes on the target node or pole node

Tugpsx

You never cease to amaze me, you have created some of the most outstanding scripts for this or any other program.
I know you have been THE most distinguished contributor to our Daz community.
We are totally grateful for all you have given us and yet more to come.
Again thanks and keep them coming.

ami.nad_671d3104eb

Sir If it's not difficult, make video tutorials your scripts as text tutorials are too hard to fallow.

mCasual

if you do character animation in Daz Studio 1,2,3,4
there's a tool i made to keep her hands or her feet or even a sword she holds
stay put as the rest of her body moves
it's basically indispensible
you want it
yes you do
this all worked fine with Aiko3, Victoria3, Victoria 4, Genesis 1, Genesis 2
but Genesis3 is so different that mcjAutoLimb2014 fails to do it's deed
this shall change incredibly soon !
in this animation you can see it aaaaaaaaaalmost works already
when it's ready i'll tell you right here
the old version is here https://sites.google.com/site/mcasualsdazscripts3/mcjautolimb2014

mCasual

so i'm currently adapting mcjAutoLimb2014 for Genesis3
her rig is different from all previous generations
so far i get moderately good results ( see my previous post )
but i want it to work as rock-solid and precise as it was for other figures
the faith of the dance animations depends on it!
the version that works for anyone except Genesis 3 https://sites.google.com/site/mcasualsdazscripts3/mcjautolimb2014
oh and the challenge for autolimb
is to bring the red ball attached to Genesis3's big toe to reach exactly the location of the green ball

mCasual

for genesis 3 mcjAutolimb2014 will do 3 "aiming" operations 

this seems to be needed to get the extreme precision that made mcjAutoLimb2014 such a worldwide acclaimed app

( it's not ready yet no )

 

mCasual

so it's decided , the new mcjAutoLimb will be mcjAutoLimb2015 and it will have its own thread and own release page

there will also be a new cofm for genesis 3 - i used it to make Zephyra (genesis 3 ) more balanced

Testing6790

I cannot even begin to explain how much time and effort your autolimb project has saved me in animation. Will the new one still work with older versions, or will we need to continue to use the older ones for the previous generations?

Thanks for all the hard work!

mCasual

AWWWWWWWH a snag !!! 

i'm encountering unforeseen issue with Genesis's arms !
looks like she doesnt have a side-side joint rotation ! go figure

so since i dont want to stress too much on this, i'll say the release date may be tomorrow

mCasual

the old versions mcjAutoLimb and mcjAutoLimb2014 will stay online 

the new version mcjAutoLimb2015 should be compatible with all humans including Genesis3

mcjAutoLimb2015 wont use "poles" which could be usefull but were also confusing

like v2014 v2015 will use the knees/elbows to obtain the proper limb/reach length

then it will use the thighs/shoulders joint to "point" the limb toward the target

then it will restore the initial limb twist ( instead of having the knee/elbow point-at the pole node )

 

a few minutes ago i discovered the Genesis 3 shoulders have no side-side joint rotation! ... 

so i wont release v2015 today, but probably tomorrow

 

note that the developments are chronicled here and here http://mcasual.deviantart.com/

 

 

 

 

Paradigm67 said:

I cannot even begin to explain how much time and effort your autolimb project has saved me in animation. Will the new one still work with older versions, or will we need to continue to use the older ones for the previous generations?

Thanks for all the hard work!

 

mCasual

here you can see a test where mcjAutoLimb2015 did a perfect job of keeping the hands still ( minimum precision of 1/100th of a millimeter i think )

but the arms seem to do an unnecessary duck-dance motion

hopefully i'll solve this tomorrow 

 

mCasual

for totally mysterious reasons i was unable ( and i tried ! ) to get Genesis3 to smile at us and stop smiling during the foot work

it's as if Daz Studio 4.8.0.59 had trouble deleting some morph keyframes 

zaz777

First, thanks for the scripts you've written.  I use several of them quite frequently.

I made a some changes to my copy of mcjAutoLimb2014 that you might find useful.  The most notable of my changes are in the for loop in the process function of mcjAutoLimb2014.dsa.

The original code is shown below:

        for( var fr = startFrame; fr <= endFrame; fr += step )
        {
            var t = fr * tick;

            var posLimbRoot     = limbRoot.getWSPos( t );
            var posTarget         = target.getWSPos( t );
            var targetLen         = posLimbRoot.subtract( posTarget ).length();    
            setLimbLen( t, target, targeter, limbRoot, limbLenCtl );
            limbRoot.setWSRot( t, zeroRot );
            var posTargeter        = targeter.getWSPos( t )
            var vectargeter       = posTargeter.subtract( posLimbRoot );
            var vecTarget             = posTarget.subtract( posLimbRoot );
            var q = vecTarget.getRotationTo( vectargeter );
            limbRoot.setWSRot( t, q );

            var posLimbRoot                 = limbRoot.getWSPos( t );
            var posHinge                     = limbHinge.getWSPos( t );
            var posTargeter                = targeter.getWSPos( t );
            var vRootTargeter             = posTargeter.subtract( posLimbRoot );
            var vHingeToTargeter     = posHinge.subtract( posTargeter );
            var vRootHinge                 = posHinge.subtract( posLimbRoot );
            var bendPlaneNormal        = vHingeToTargeter.cross( vRootHinge );            
            var elbowPointAtVector = vRootTargeter.cross( bendPlaneNormal );
            if( pole )
            {
                posPoleVector = pole.getWSPos( t );
            }
            var vRootPoleVector     = posPoleVector.subtract( posLimbRoot );
            var vPole = projectWontoV( vRootTargeter, vRootPoleVector );
            vPole = vPole.add( posLimbRoot );
            vPole = posPoleVector.subtract( vPole );
            var rfix = vPole.getRotationTo( elbowPointAtVector );
            var r = limbRoot.getWSRot( t )
            r = r.multiply( rfix )
            limbRoot.setWSRot( t, r )            
        }

I've replaced that with:

        for( var fr = startFrame; fr <= endFrame; fr += step )
        {
            var ttt = fr * tick;

            Scene.setFrame(fr);
            Scene.update();
            var posLimbRoot     = limbRoot.getWSPos();
            var posTarget         = target.getWSPos();
            var rotTarget        = target.getWSRot ();
            var targetLen         = posLimbRoot.subtract( posTarget ).length();    
            setLimbLen( target, targeter, limbRoot, limbLenCtl );
            limbRoot.setWSRot(zeroRot );
            var posTargeter        = targeter.getWSPos()
            var vectargeter       = posTargeter.subtract( posLimbRoot );
            var vecTarget             = posTarget.subtract( posLimbRoot );
            var q = vecTarget.getRotationTo( vectargeter );
            limbRoot.setWSRot( q );

            var posLimbRoot                 = limbRoot.getWSPos();
            var posHinge                     = limbHinge.getWSPos( );
            var posTargeter                = targeter.getWSPos( );
            var vRootTargeter             = posTargeter.subtract( posLimbRoot );
            var vHingeToTargeter     = posHinge.subtract( posTargeter );
            var vRootHinge                 = posHinge.subtract( posLimbRoot );
            var bendPlaneNormal        = vHingeToTargeter.cross( vRootHinge );            
            var elbowPointAtVector = vRootTargeter.cross( bendPlaneNormal );
            if( pole )
            {
                posPoleVector = pole.getWSPos( );
            }
            var vRootPoleVector     = posPoleVector.subtract( posLimbRoot );
            var vPole = projectWontoV( vRootTargeter, vRootPoleVector );
            vPole = vPole.add( posLimbRoot );
            vPole = posPoleVector.subtract( vPole );
            var rfix = vPole.getRotationTo( elbowPointAtVector );
            var r = limbRoot.getWSRot( );
            r = r.multiply( rfix );
            limbRoot.setWSRot( r );
            targeter.setWSRot ( rotTarget);
        }

The primary change was to change the method calls to not use the value of t which is computed at the top of the loop.  I use Scene.setFrame(fr) and Scene.update() to manage time and the getters and setters used to do the work don't use the computed time.

The benefit of this is that mcjAutoLimb2014 now works with aniblocks.  With the changes I've described, I can now drop an aniblock on the time line and then either in that aniblock, on the default or other level, or in a new aniblock on a subtrack, I can use mcjAutoLimb2014 to fix up the limb movement in the animate2 timeline.

The way the code was originally written, one would have to bake to studio keyframes and then recreate the aniblock from the studio keyframes.

I'd be happy to send you the entire script if you want it.  I've got a few other changes in there that I think might deal with rotation better, but I'd have to look through it and test against the original to be sure what all the changes I've made are.

For example, I don't recall right now why I have the targeter.setWSRot ( rotTarget);  line at the bottom of the loop.  I think I was having problems with foot or hand rotations that were related to not setting limits off.  So, that line is probably superfluous.

 

mCasual

i may add the setFrame behavior as an option to mcjAutoLimb2014 and mcjAutoLimb2015 if it can help with aniblocks

the one drawback of doing this is that the OpenGL rendering takes a few fractions of a second per frame but probably not that much

your setWSRot() was probably like what mcjKeepOrient does, though this only works if the targeter is indeed a foot or a hand

https://sites.google.com/site/mcasualsdazscripts/mcjkeeporient

i've been thinking (and it was suggested to me ) to add mcjKeepOrient or mcjHoldOn capabilities to mcjAutoLimb ... still thinking :)

i'll message you about the source code

 

 

zaz777 said:

 

For example, I don't recall right now why I have the targeter.setWSRot ( rotTarget); 

mCasual

Note to me and to fellow script writers about time and Daz Studio 4

var tick = Scene.getTimeStep();

debug( tick, 1 * tick, 28 * tick )

Executing Script...

[object Object] 320 8960

====================

conclusion, when dealing with Time values, if you intend to treat them as a numbers later, force them to be numbers by multiplying them by 1

var tick = 1 * Scene.getTimeStep();

=====================

This holds true for the Scene.getTime() function too

if you want to avoid an hour of head scratching wondering why this simple test script you wrote aint working, do

var t = 1 * Scene.getTime();

 

mCasual

good news !

using 90% of understanding and 10% of guess ( it was not easy )

i seem to be able to twist Genesis bi-jointed Thighs without having the targeter ( toe tip) ever leaving the target (red ball)

with extreeeeeeeme precision

and i'm probably able to do the other part of the target/targeter leg-aiming in 1 shot instead of 3 to 10 successive approximations

so today thursday may be the release day for mcjAutoLimb2015 compatible with Genesis 3 ( and everyone else )

 

mCasual

http://orig04.deviantart.net/e363/f/2015/330/4/e/footy_by_mcasual-d9i3vcv.gif

working on it today too

( the little physics simulator mcjThrow which was used here to animate the basketball will eventually be published on my site )

mCasual

the following is possibly an annoyance introduced in recent versions of Daz Studio 4 because i never had trouble with that in Daz Studio 3 .....

but apparently if i do 

pos = littleBall.getWSPos( time_at_frame_10 );

and i'm not at frame 10

if littleBall is parented to a figure ... i dont get the WorldSpacePosition of littleBall at frame 10

so next versions of mcjParent and other ( dozens !!!!!??) of my scripts will need to be modified and use

setFrame( 10  ); 

pos = littleBall.getWSPos( );

and maybe even Scene.update(); 

this will slow them down

 

zaz777 said:

 

            Scene.setFrame(fr);
            Scene.update();

 

mCasual

good news the "pole vector" maths seems to werk perfectly

so contrary to previous posts, this feature will remain as-is

... even if it's confusing

... because its usefull

for instance twerking

and duck-dance arm movements

important stuff

 

click on the attachment image for the larger version

http://www.daz3d.com/forums/uploads/FileUpload/1b/3d2de4e7c9e872feb60bf4f140d6e8.jpg