Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
In my tests the pose controls take priority over the ik solver. That is, if you keyframe a channel that's in a ik chain then the ik solver will not use that channel for the ik solution. This allows for example to use the side-side channel of the thigh to bend the knees in the G2F. I agree this is an unusual solution. In other animation packages it's well defined what's under the ik solver control and what's not. I fear this mixage may introduce instability into the ik solver since this way it's operating in "dynamic" conditions as for the assigned channels.
Plus the ik solver precision seems sometime weak and there is a bug when saving and reloading the scene. I guess they have time to improve though. Or may be they just need to explain us how this is supposed to be used with some official docs.
https://www.daz3d.com/forums/discussion/359821/ik-chains-bug-ticket-submitted
Isn't the priority whjat the Reach property is for?
The reach property works for the ik goal, not for the ik chain. I mean, in the default ik chain for the G2F foot you can set 100% reach, that will keep the foot in place. Then you can use the side-side channel of the thigh to position the knee, even if the thigh is inside the ik chain. In this sense the pose controls take priority over the ik solver. That I guess is what's asked by @wolf359.
Have you tried changing the keyframe interpolation to linear? Unwanted movement is caused by curve overshoot used in the ease in ease out curves. Linear interpolation does not use curves, so it doesn't suffer from over shoot. There are interpolation formulas that attempt to constrain the curves to prevent overshoot, but I'm sure not if DS uses these modified formulas.
On the other hand, I do appreciate that DS is adding animation tools to their program, and this is DS beta, where I hope that discussions like these will lead to better tools.
Using linear interpolation is a possible solution for overshooting. But this way you get a sort of "robotic" movements, that's why curves are provided in the graph editor. Also, since linear interpolation for rotations is computed in parented chains, it is not granted that a foot position will not change among keyframes when the hip/knee moves.
That's why ik goals are better, other than easier to use (when they work).
I only mentioned it because you thought there may be some mixing going on. I was just wondering if linear interpolation would work to reduce or eliminate the unwanted movement.. Personally, I find that if you use linear sparingly ( from time to time) the robotic effect is not that noticeable. If it is noticeable it can easily be corrected using spacing (moving the part a smaller or larger amount at beginning or end of the keyframe) or timing ( breaking the keyframe into longer and shorter frames)
Of course the best solution is for DAZ to fixed the IK solver. I think they should look at Motionbuilder as the template IK, FK, and CK. Of course Motionbuilder has floor system that makes things a lot easier; but that's for another discussion. I would like to see DAZ get the bugs out of their IK system and new timeline first.
Does the beta have any IK chain improvements does anyone know? I was thinking of giving it a bit of a run out.
I have no time to beta test. But I did report the bugs to the daz support and at this time I didn't receive any notification for them to be fixed. So I guess the beta doesn't get improvements.
A quick check of the chnage log finds two explicitly listed chnages involving the IK Solver, there may be other chnages thata re relevant but use different terms.
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#4_12_1_15
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#4_12_1_16
Thanks Richard. Will take a look.
Does anyone else find that IK chains are much, much faster on G3 characters vs G8? When I add IK controls to a G8 character's feet, for example, I get extreme lag when posing the character or scrubbing the timeline, whereas everything remains smooth and responsive when I do the same thing with a G3 character. The fact that G3 works so well with IK controls tells me that it's not a typical performance issue that can be resolved by adjusting viewport settings or whatever, but rather a problem with the IK system itself.
A problem with the IK system itself would affect all figures. A lag with particular figures sounds more like soemthing specific to those figures, such as more (or higher-resolution) modifiers to recalculate once the control is released.
I think I found the issue: It seems to be directly related to the amount of content installed for the base figure that's being used, and I have way more G8 than G3 content. I temporarily disabled my content directory, restarted Daz, loaded G8 base, and applied IK chains. Everything was a smooth as it had been with G3.
My plan now is to have two content sets: One will be for my entire content library, and the other will be a temporary / working library for animation. Hopefully at some point Daz will have a more convenient solution to this problem.
When you adjust the pose DS has to check through the dependancies to see if there are any morphs, straight JCMs, or morph corrections that need to be updated - and with an IK adjustment multiple joints will usually need checking.
Playing with these now. I must be thick or something because apart from parenting the IK node to another object in the scene, I'm failing to see how this is any different from ActivePose or Translate Tool pins. So I still don't get the point.
What I need to "get it" is an example that's something I can't do without the IK chain.
Being able to parent the IK target is the point - it allows a figure to respond to the motion of another item, rather than attempting to keep adjusting the two separately to stay in step.
It's hard to know what's a bug when you don't quite understand what it's supposed to be doing for you. I mean I still don't get it. You say other pinning tools are for still frame poses, but most animators will construct animations pose-to-pose, and then later "inbetween" them. That's how I do it anyway. Now if on a frame-by-frame basis the constraint is satisfied, similar to MCasual's AutoLimb and KeepOrient, that would be pretty useful. The problem I have with MCasual's scripts (which I use a lot by the way) is they literally write every frame, which means if you want to go and adjust something you have to first delete all of the inbetweens; a lot of extra work.
So in conclusion then, the idea behind the IK node is to set some constraint to hold true across the timeline. But why implement an IK node when you can just make sure the interpolators obey the existing Translate Tool or ActivePose pins? Apart from follow of course - parenting a hand to a shoulder...
It would almost be worth animating figures in Unity and bringing back into Daz to render with iRay looking at that. But... yet another tool to learn.
It's a bug because it doesn't serve the purpose it was designed for. Feet and hands still jump off the place no matter what you do. And if you don't want limbs to explode, you have to lock the arm rotations. The entire purpose is to have the constraints account for each frame. Animate2 can be very helpful for layer animation. If you convert your animation into an aniblock , you can adjust it as many times as you want without having to delete keyframes.
IK can be used for single frames, depending on how active they are. Other than the softness of the pinning what are you finding "buggy"?
If I say at frame 0 "pin this" (foot) and then to a pose-to-pose on frame 30, as long as I stay within limits (which I can change), it's usually more or less there whilst I'm dragging other parts about. But if I play back, I find the TCB interpolation hasn't respected the pin. So at 1 and 30 it's in more or less the right place but at the inbetweens it isn't. MCasual's Autolimb and Keep Orient scripts will calculate and adjust the limb chain on every frame to keep the position and orientation the same (in world space). This is something you'd expect the pin to do without having to script it. This is the main problem with it I think (for me, I don't know about others).
I've been using the Walkit plugin by generationx which has been my work around for uneven terrains walk cycles for daz characters, Its not really a hard surface pinning tool more like a walk cycle tool. it works very easy mark your foot steps on your terrain & the character follows the foot prints. even on uneven terrain. I've been using daz public build version 4.12.0.85 and the plugin works still in this version even though it was made for 4.10. I can not say it it works in the new daz beta or any newer public build versions of daz 4.12 though. I am not going to upgrade my daz version for a while. mostly because after NVIDIA broke the GTX cards ability to use iray by making opitex prime acceleration on all the time by default in GTX cards. which doubles the resources used. causing me all kinds of fall back to cpu issues with the Beta versions of daz, so I am going to stick with this 4.12.0.85 version of daz public build and NVIDIA 436.30 driver until I can invest in upgrading to RTX gpu's which may be a long time at this point. But the set up i have now is working good with my 2 GTX 1080ti' so no need to fix whats not broken . But I would give that walkit plugin a try its a cool tool
Very interesting. Will take a look. But it's not just about walking. It's anything where you want a limb part to stay still. Fingertips, hands, feet, head.
The only work around i have for that type of encounters. is to use animate2 plugin and create a Sub-track and then create your secondary animations in a empty aniblock on the sub-track for the additional movements . then you can bake the whole thing into the daz/animate2 timeline and resave as a animation preset or create & save as a aniblock for reuse. That has been the best solutions for me when animating animals or making a walk cycle and i need someone to carry a rifle or box or something that required the arm & hands to have a certain position do the same for neck head eyes toes feet etc. just make a subtrack for the extra required moments . of course you may need to refine the animation a little to remove foot slip or to customize the pose positions for the animation cycle I use keymate for that unless i need a curve in the motion then the graph editor works better for those issues
Something I've never been able to get the hang of with Animate is just what it's doing, i.e. is it only storing the changes, or the entire pose? Expressions? Morphs? I tried to make a "breathing" anibloc that involved just chest scale, shoulder up/down and a few other things. This is possible if you start with a t-pose genesis character but otherwise you get a whole bunch of stuff included in the bloc you didn't want included - things you didn't "change" on that frame. Puppeteer is similar in that it doesn't store only the changes you've made on that frame, it stores the entire pose, negating the usefulness of layers.
yeah It does takes a little of practice using animate2 you are sure your using the full licensed version of animate 2 and not animate lite. because the animate one that comes included with daz studio download is only animate-lite and you have to have the license version animate2 to unlock the sub track. if you do have animate2 , thenall it takes is practice stacking and keyframing animations into aniblocks
Oh something to make you all smile :)
click to play