Wild rotations between keyframes
jamesramirez6734
Posts: 90
The bone tool works great for adjusting positions at keyframes, but I've noticed sometimes when working with the hip in particular, the character will spin/rotate wildly on an axis in order to reach the next keyframe (as in do a crazy 360 flip!)
It's as if Daz doesn't know how to animate between the two keyframes, so it rotates the character dramatically and eventually lands in the new position. What's strange is it's very easy for the two frames to flow from one to another (it's a simple bone movement).
Does anyone know of anything which can help prevent this Daz from doing this?
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
Check the graph area at the bottom of the Timeline, with the affected rotation selected, to see what is happening. You may want to adjust the values cotnrolling the interpolation (TCB) or even change the interpolation type (right-click on a key).
I've been complaining about this for years to no avail. The best explanation I have had from this forum seems to be that when you use commercial poses (or even your own) which use hip rotations that go beyond 90 or -90 then it can (but I don't think it is inevitable) trigger that spin like a chicken on a spit. The only way I can be sure of avoiding it is to pose the figure myself without going through my usual process of starting with a commercial pose and tweaking it.
it's a weird gimbal thing only DAZ studio out of all the softwares I use does
it interpolates between all 3 axis not just the one you rotated and chooses the shortest spin
the camera does it too, never zoom and dolly ever!!!
(it will flip like a somersault)
the only solution is to expand the timeline and select and keyframe each axis at some point before you do the next rotation (usually inbetween but you may want to ease in slower or faster so up to you)
a preset pose is always a gamble as some return the figure to 0,0,0 or rotate the hip instead of the figure or any of other possible option
using Puppeteer is also one way of mitagating these issues
It's caused by the limits on the parameter rotation as you pass through 0. If you are going from, say, 270° to 365° that's reasonable, but DAZ puts the limit at 360°. There is no work round, well, not one that works. The next best thing is to find the frame (not keyframe, frame) where the parameter hits the limit (typically 360° or 0°) and then *create* a key frame for that value there with the value 0°, so that it stays in range AND THEN create a key in the *previous* frame with the same value as the one in the next frame but with the other version of 0; the one from the previous frames.
The problem is that dForce works sub-frame; dForce can end up with a temporarily insane value between two frames. The work round for that is impossible, because the frame rate cannot be made high enough in the DAZ UI to match the dForce sub-frame rate. Throw it against the wall and see if it sticks.
You can work round this by changing the interpolation method on the *previous* frame (the one with 0° represented as 360° or vice versa) to LINEAR. Then dForce won't see out-of-limits values.
If you are not doing dForce (so don't care about the wacky sub-frames) and are really doing animation you should not be using TCB interpolation. Seriously; just don't do it. Select everything in the animation, TRSOAH, and set the interpolation method to Linear. Go have a fine meal, come back, save it. Do this every time before you save the file (it gets quicker after the first.)
This is the simplest experiment I could do to demonstrate the problem. Both planes do a few degrees rotation clockwise. The one on lhe left goes around anticlockwise to get there. This problem ruins almost every complex animation I try to do.
Sent in tech help request - ticket 438233
Ifm you set the 1st keyframe of the plane to -5 instead of 355, it will only rotate 5 degrees.
Good luck with the support ticket. I've tried them before and got nowhere on this problem. However I didn't go into the kind of detail you are supplying so maybe they will take notice. I'd be very happy to see this fixed at last.
To solve the problem of gimbal lock, animators prefer to use quaternions to interpolate between keyframes, so Daz should be using spherical interpolation (SLERP) internally. But, there's still a small issue here, as to which path to take, as there's always two paths (long and short) on a sphere. Most prefer to take the shortest path.
If you have a list of quaternions, you can precompute them so they always take the shortest path. The DotProduct is checked, and the quaternion is flipped if negative:
for (int j=1; j < num_keys; j++) { float d = DotProduct( keys[j-1], keys[j] ); if(d < 0.0f) keys[j] = -keys[j]; }
But, that's assuming Daz quats work like everybody's else quats. I know from experience Daz quats don't give the same results as others. They're just weird. But, this info is nothing new. It took 5 minutes to look up. 100% human answer, no ChatGPT.