Feature Request: DAZ's timeline needs a way to change the default interpolation type
green_90f49a94c9
Posts: 5
The recent changes to DAZ's timeline make it way more usable, but there are still some big and easily-fixed blindspots. Case in point: interpolation.
The current version of DAZ lets you select objects in the timeline and click to set their interpolation to spline, linear or constant. However, no matter what you do, every new animation keyframe will always default to spline interpolation. That means that if you want to primarily (or exclusively) use one of the other two interpolation types, you have to constantly be going back to the timeline to select the keys you changed, and manually change them to constant interpolation.
This might not sound like a huge deal at first glance, but when you're working on a complex project where using one of the other interpolation types, it can a major problem. At the very least, it's a major annoyance having to constantly make those adjustments. At worst, it can lead to things in prior frames being changed in unpredictable ways, potentially destroying what you worked to build.
Here's an example: I'm a comics artist, and I like to be able to create scenes with multiple still camera shots in a single .duf file, with one shot per frame of the timeline. When I finish posing the characters and camera for frames 1-5, I want to be confident that things in those frames won't get randomly moved around when I pose things for frame 6. Unfortunately, unless I keyframe literally everything that's not the case with the current set-up, and even my most valiant efforts to keep changing everything to Constant Interpolation, the default splining still causes weird and unpredictable issues sometimes.
So here's my solution: add an option to change the default interpolation, either for the whole scene or per object/figure. That's it. I imagine the former woudl be a very easy thing to program in, and it would make comics creation in DAZ a much faster and more efficient process.
I also think it would be helpful if the keyframes had color coding or different shapes to let you instantly look at an object's frame on the graph and know which interpolation type it uses.
These aren't advanced features I'm asking for, either; nearly every feature I brought up has been in Poser for over a decade, and is standard in 3D animation software. DAZ is a great program in most respects but the timeline has a lot of catching up to do!
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
Plus one on that. It's a royal PITA having to select all the keys and change them back to "Linear"; that's the only way of guaranteeing that out-of-bounds movements do not happen.
To add to the request: how about *NOT* changing the interpolation method back to TCB when a property value is changed? So if I create a set of keys using Key+, select the whole shebang I just created and change the interpolation method to Linear I do NOT want the method to be changed back to TCB if I then change one of the properties. I mean; the UI allows me to change the value, right, it has nothing to say about the interpolation method, so why does changing the value change the interpolation method?
I have to point out that your use case, while perfectly valid, is not typical.
Didn't you already post this? I'm sure I remember saying that if you want to make sure that adding a pose at T3 doesn't change a pose at T2 because it is modifying a property that isn't keyed at T2, but is at T1 and T3, then it would be ebst to select the whole thing and key it before posing. I'm not sure that a different interpolation type would even help - if the intermediate pose isn't keyed on a property then that property is going to get a value determined by prior/subsequent keys in a way that depends on the interpolation.
Key types are indicated on the Timeline by different shapes - as long as you are looking at the actual property keys, not a collapsed property or node group marker.
I see what you mean. Have you reported this as a possible bug?
I don't think I have. I just adopted a work-flow of key+'ing TROA hip-node-hierarchical and selecting the hip and all sub-nodes then changing everything to linear, repeatedly. At this point I just pretty much select everything in the timeline and change it all to linear; after the first War'n'Peace change the subsequent fixes are quite quick.
There are real bugs here but they come out of a broken model. For example if I have a linear-interpolated transition of a single property between two full-keyed frames and I insert a new "keyframe" between the two the (unkeyed) frames after the property value is interpolated linearly to the new keyframe and has the same value at that keyframe but it is interpreted TCB after that. This behavior makes the interpolation type pretty much unuseable per-property in any real workflow. It's another variant on the bug I mentioned but in this case the interpolation type and, potentially, the values of all the unkeyed frames after the new frame have changed. To undo this I would have to find every !TCB property in the preceding keyframe and set it on the new keyframe.
Even then it doesn't quite work and this is, I think, the point @green_90f49a94c9 was making. You can demonstrate it with a null; just create one on frame 0 then keyframe (TRSOAH key+/Object) at frame 0 and at frame 4. Set the X translate to 100 on frame 4. These are the interpolated values for the intermediate frames:
Frame 1: 15.625
Frame 2: 50
Frame 3: 84.375
Frame 4: 100 [keyed]
Ok, fine. So, following your methodology, suppose you decide you need to change the value of a completely different property at frame 2? As I understand it by your approach you key all the keys at frame 2 ("add a keyframe") and, yes, this is the traditional approach of a lead animator. The problem is that in DAZ Studio all the 'tweens get changed even of properties that you don't intend to change. After I "keyframe" frame 2 without changing anything I see these values:
Frame 1: 18.75 [was:15.625]
Frame 2: 50 [keyed]
Frame 3: 81.25 [was: 84.375]
Frame 4: 100 [keyed]
Ok, so look at what happens when I add a new keyframe at frame 8; this is the classic lead-animator workflow:
Frame 1: 18.75
Frame 2: 50 [keyed]
Frame 3: 79.16* [was: 81.25 [was: 84.375]]
Frame 4: 100 [keyed]
Frame 5: 104.6875 [outside original bounds]
Frame 8: 100 [keyed]
These are two separate problems which together make a big bug; adding control points to TCBs changes all the values either side of the new point even though the point itself is not changed, as well as generating potential out-of-bounds values (e.g. on bend values). This is extremely counterintuitive and, when performing detailed tweaking of an animation or simulation to avoid small collisions makes the whole thing exceptionally difficult. This is why I use linear interpolation - I can actually add a keyframe in the middle of a linear interpolation without breaking things either side, so long as I finally set all the keys in the new keyframe to linear. But then that is the second bug - things default to TCB and change to TCB when a property is altered.
If properties did not change interpolation type and when a property was keyed for the first time the interpolation type was set to the type from the previous key that would go some way to helping. I'd only have to set frame 0 to completely linear to ensure everything stayed linear (or, for that matter, constant or TCB).
As I understand the above the interpolation is still TCB. If so then the value going above 100 between the two keys of 100 is expected, that is necessary for the graph to remain curved. I agree that the intermediate values chnaging when you insert a new key between the two exisitng keys is not what I would have expected (though it's also not what I was thinking about earlier - I understood that only the keyed frames were of interest, not any intermediate frames, since thie was being used as a tool for having several scenes in one file).
When I used to do this, I left 'unused' frames incase I later found out I needed to add a scene there, but the inability to set linear interpolation as a default was one of the reasons I stopped doing things with the timeline.
Another problem is that DAZ doesn't actually support the animation concept of a keyframe; a keyframe really is a sheet with the entire foreground drawn on it (the background may be separate). If the lead animator adds a mug of beer to the next keyframe it doesn't get added anywhere else. With DAZ Studio however adding anything to any key frame causes it to appear in the same position, unkeyed, in every other keyframe. Curiously adding a "NULL" adds no keys to the timeline; no keys anywhere, yet adding an "SLA Full Sandwich" at the same frame gives what is apparently a full-keyed (keyframed) sarnie:
Both the Null and the Sandwich were added a Frame 15; nothing else was done.
This really is a separate issue, but it does mean that anything added to an animation has to have keys added manually to all existing keyframes until it is off sceen (at both ends) - key values remain constant before the first key and after the last, so the terminal TCBs slope into the final constant value before the final key value.
I would much prefer to have true keyframes, such that I can mark the frame as a keyframe so that from then on the values of all properties in the frame are fixed (unlike changed manually). In that scenario a change to an existing linear property key immediately before the keyframe creates a key at the keyframe before the property change is made and a change or creation of aTCB property key immediately either side of the keyframe also creates a key to freeze the value. This deals with both the addition of props and the file size explosion caused by full key creation.
While some applications do, I think, now have the ability to add items 9and chnage parenting) in an aniamtion for a long time this was a very rare or absent feature.
So far as I can determine the DAZ Studio data structure is inverted from the traditional animation flow; in the latter every hung off the key frames because no other structure existed. In DAZ it seems that a property has a value and, curiously, a list of keys (in the parameter setting "Keys" tab.) If I create a NULL it has no keys. If I set the X translate to 1 it gains a key (Frame, Raw, Value) of (0, 1.0, 1.0). If I set the X translate to 2 on frame 1 I can see I have a list [(0,1.0,1.0), (1,2.0,2.0)]. If I set the FPS value to 300 (from 30) the second entry is now on Frame 10, so the frame number isn't quite that simple and I know that aniLip can store key values on non-existent frames. Indeed if I set FPS to 3 the second entry is reported as being (0,2.0,2.0) yet I can see from the timeline that the key is actually one-tenth of the way to frame 1. So I assume that "frame" is actually stored as "time", as floating point seconds. The setup with FPS set to 3 really confuses keymate but I can use the DAZ timeline and select the keys separately!
So there are no frames; just times. It would be possible to add an object to the scene at a given time and remove it later without altering the DAZ structure, but it's probably easier just to allow the Visible property to be animated. At present the only thing I can animate is "Visible in Render"; that's not quite enough because the object would still interfere with a dForce simulation and it would clutter the viewport too while editing.
There are, however, far more important things to animate - I still can't animate "Tonemapper Options/Exposure Value" in 4.15.0.30 even though the tonemapper options were put into the scene (with an annoying null cross) on 4.15.
Yes, keysa re stored at times - if you look at the scripting (or, I assume, SDK) docs for proeprties you can see this.
Thanks, I should do more scripting rather than working it out; I'm certainly better at scripting than art :)
Ditto, I would also really like this feature as well. Furthermore, it would be good if default interpolation types would be possible for different types of objects.
TCB can make sense as a default for characters but as a default for cameras, you often get extremely counterintuitive and counterproductive results.
green_90f49a94c9 said:
As a comic artist myself, I agree and understand you 100% and anyone arguing "well that is not common for most of us since we animate" is a BS counter argument.
My whole timeline is constantly destroyed by auto key features. We definitely need a new animation option, let's call it static. The ability to use the timeline without actual animation. I do not want to have to set up a single shot and then render and then set up another shot and then render again. I set up as many frames as I can, press render and then go to bed or work. I HATE coming back to see that something like an arm or expression shifted. Expressions are HANDS DOWN the most frustrating of all since "poses" and expressions can often totally not even exist on the timeline, yet affect the render.
Honestly, the ONLY solution I have found to work around this is to store a "default reset" pose to your script bar (T pose, A pose, etc) and apply it to each and every single frame you plan to use in the timeline on every single model (people only) in your scene before you start that new frame. This has worked for me to essentially "reset" the model frame by frame. You can then post each frame individually without worry.
Even that is a pain. Pose and setup a frame, select the next frame, "reset" each model on the new frame, pose and move on while repeating the steps.
I prefer linear and am glad it was added as an option as before animation in D|S was awful
it certainly would be nice if it were possible in preferences to set it as the default though instead of having to to manually do it every time
Bézier curves with handles would be nice (like in 2005! autodesk combustion 4).
The problem is, that changing key#3 changes the values between key#1 and #2.
This shouldn't happen.
BTW:
There should be an option to switch autokey off.
I don't think adding a new type of control is going to help and, personally, I have always found Béziers intractable; like to the point of unuseability.
TCBs are fine but they behave the way they behave; the curve at any given control point is determined by the control points on *both* sides according to the "bias setting". I don't know if DAZ document the TCB parameters they are using anywhere but it looks like C, Continuity, is 0 and that's pretty important; we don't want discontinuities at tke keys. Such discontinuities are very obvious! I'm pretty certain that B (Bias) is also zero and I suspect T (Tension) might also be zero. What you want is, if I understand it correctly, closer to TCB(0,0,1)
The problem is that the TCB parameters have been like that for ever and any change would break existing animations, animations that took the artist a lot of effort to get right! Maybe they could give us control over the TCB parameters, maybe it's even part of the scriptable interface.
IRC there was discussion some 20 years ago in the CG world about having splines that had this kind of property; the direction ouf of the control point and all previous interpolated values are fixed by the previous control point. The theory at the time was that this gave a much more useable UI than the control-point-akimbo world of the classic Bézier. It's also what we want for animations; we need to be able to construct new frames without damaging the old ones, so I agree with you there; that's why I wanted "linear" as a default. (Linear is, if I've got it right, TCB(1,-1,0)).
Wherever I see anything related with timeline, I always add: Fixing copy-paste tcb calculation bug. The bug is ancient. It appeared somewhere between 4.10-4.11, got temporarily fixed with one of the 4.11 versions and then re-appeared in late 4.11 versions.
Literally, copy-pasting keyframe(s) of a char's movements in timeline (move and/or duplicate) has a serious chance of triggering this bug. The subjected limb becomes erratic, the related x/y/z value(s) become "NaN" and it might cause viewport to become gray (show nothing) and causes daz to freeze for a very long time and/or permafreeze. The more you do this operation to a same character, the higher chance of reproduction.
Some of my projects are completely halted since I can't do any spacing change on the timeline becuase of this bug.
I hadn't realized it was back, most likely because I've given up on Daz for animation and pretty much only use the timeline for dForce.
Yes, it's a really serious bug; having a calculation which generates a NaN is bad news; infinities are fine, NaNs are not. I reported it at some point in the timescale you mention and gave a pretty easy repro, plus the NaN is a dead giveaway. Oh well.
Before copying keyframes I alway set interpolation to linear and after copying back to TCB.
But you see what you get. There's no need to type in numbers.
But frankly i could live with all that [difficulty], if the animation preview would be faster than 2 fps.
In complex scenarios (some parts of the character is linear while others are tcb), this is a bummer. On very long animations, this is clearly a no-go. Also, I would really like to see this fixed rather than trying to find workarounds for it, since it is related with one of the core features of the Daz studio (timeline).
Even what makes it worse, since keyframing already has an unforeseen tcb value changes in the previous and future keyframes in the animation (this is another logical bug by design), you never know which of the previous parts of the animation got broken again. It is an awesome sight, when you hit space, at some point suddenly the effected character disappears from viewport and then daz freezes.
+1 to let us change the default to constant / linear. I 100% have the same issues as zombiecharger65.
+2
+3
+400
As it is now, the timeline is preventing one from even trying to dabble into animation and making it practically impossible to do storyboarding
+500
I think DAZ is being really short-sighted by not addressing issues like this. It's something that probably wouldn't take a whole lot of money to address, and would make the program useful for a whole lot of people who can't do much with it currently.
Blender is still pretty imposing for new users, and there's not a whole lot else out there in terms of cheap and easily accessible entry-level animation software. iCone is way too expensive for most people. Poser has dated graphics, lacking support and still costs more money than it's worth. If DAZ made the timeline actually decent, they could potentially build a much broader user base. It wouldn't even have to be amazing. Something that has all the features that Poser Pro had more than a decade ago would be sufficient for a lot of use cases. And that's Poser we're talking about!
If anyone at DAZ is reading this, please look into fixing these issues with the timeline!
a) NFTs were/are different people. b) if you want to adderss daz please make a feature request via a Technical Support ticket, ideally without snide comments about NFTs or the like.
Sorry, got a little carried away with the snark. I edited the comment to delete that bit.
I will make a request via support ticket.
It was a well constructed response; you just have to delete the last paragraph.
Feature request: "please fix all the bugs in the timeline that have been reported."
1) The off-by 0.5 error when clicking on the upper line "frame", like if I click before frame 30 I don't expect frame 31 to be selected.
2) The weird inability to click/drag because of whatever it is (locks, precise TRSOAH selections; I don't know!)
3) The aforementioned inability to actually specify the interpolation used on new keys by default.
4) The even more annoying idea to change the interpolation method of a key if the *value* is changed, though I haven't checked if that has been fixed yet; I just TRSOAH drag select and change everything to "Linear"
Now, with due respect, some things have been fixed; the marquee selection seems to be working correctly these days, although there still seems to be a 0.5 bug vertically I can at least select the last key if it is at the end of the timeline.
I think this is definately "A for effort", well done!
Please make separate reports for each.