Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
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!
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???
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
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
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?
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.
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" )
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
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?
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
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
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.
Sir If it's not difficult, make video tutorials your scripts as text tutorials are too hard to fallow.
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
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
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 )
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
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!
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
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/
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
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
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.
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
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();
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 )
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 )
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
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