Thanks for your input, it’s certainly useful. And the current approach won’t be thrown out until we have something that works even better
If there is an issue with a description, an example file, and steps to reproduce, just use the bug tracker to discuss it
I think it’s great that people share feedback on the topics of the meeting, let’s keep that going. It’s just that when the discussion moves to very specific issues and their possible solutions, I think that the meeting notes may not be the best place for that. A design task on developer.blender.org would be a better place for such things.
I appreciate that! And sorry if I’ve been coming across as aggressive (re-reading some of my posts, I’m realizing that may be the case). That wasn’t my intention, nor my feelings behind them when writing them.
I think rotations generally (even aside from quaternions specifically) are a pain point for animators, and I’m very excited to see the animation/rigging team exploring better ways for animators to work with them!
Thanks for the info, and the links. I have found plenty of people who say, “Don’t use slerp.” What I’ve noticed is that these people tend to be game coders, who care deeply about performance, and are presumably creating their keyframes in a different app that probably isn’t using normalized component quats. If you have baked keyframes, then I can easily imagine that nobody would ever notice the difference, because your keyframes represent tiny rotational differences.
But when you’re actually creating those frames, you’re creating breakdowns from potentially large rotational differences, where normalized components are not going to give you smooth breakdowns unless you cut them exactly in half. Creating the animation data in the first place is different than interpolating that data in a game.
It looks to me like Blow says exactly that: “Hey, we’re sampling animation created elsewhere at 30hz, perceptual differences are minimal and, probably, not even inspected by the animator at a higher frequency. Let’s do what’s fast and what lets us blend without caring about blend order.”
I can see how one could consider “shortest path interpolation” as being something potentially separate from slerp. (I could also see how one could consider it part of slerp implementation.) Yes, I can see how you could do shortest path without slerp, or slerp without shortest path. But shortest path requires a temporal awareness that Blender doesn’t have right now, because to judge whether to flip the W requires knowing the last and next keyframes, not just a current interpolation. (For reasonable f-curves; for less reasonable f-curves, I think you’d need to know the last and next min/max, but my understanding isn’t advanced enough to be confident.) Even without shortest path interpolation, slerp requires that temporal awareness, and once you have it, shortest-path interpolation is easy (and smart; and no, I wouldn’t consider an “any-path slerp” to be half as useful.)
Obviously, moving from normalized-component doesn’t magically make anybody a better animator. But it does mean that if you want, you can properly animate a clock with quaternion hands at 4, 8, and 12, and not need a math lesson to understand why it’s not correct at 5 o’clock. And when used in conjunction with shortest path, as I’ve seen it done in previous animation software I used, it solves a lot of problems with character animation that otherwise involve unintuitive solutions. Like the one I mentioned. Shortest path quat interpolation makes quats behave much, much more like people expect rotation to interpolate. The only thing that they get confused by are 180 degree+ rotations, and compared to the issues with normalized components, that’s easy to understand, easy to explain.
Yes, there are things that moving from normalized-component breaks. Like, a sine f-curve modifier on a quat component. But those are things that never made any sense to begin with. Part of what’s exciting to me is that actually treating quats as quats allows Blender developers to start doing things like quat f-curve modifiers that make sense. Like an additive sine on a slerp fac, rather than on components. The doors that close were always pretty crappy, and it allows new doors to open.
Sorry. Hopefully the rest of this discussion is okay, and you’ll let us know if not. I never created a bug report related to that issue, because AFAICT, it was working according to dev intent.
Oh yeah, for sure, the primary reason for using direct component interpolation in game development is performance. That’s actually also relevant for production animation (e.g. keeping a responsive viewport when animating with a large number of characters, etc.). But I agree it’s not nearly as critical, and is not the primary reason I’m advocating for keeping it around in Blender.
In general, I feel like you think we have a disagreement, whereas I’m pretty sure we don’t. At least about the facts of quaternion rotations and interpolation methods thereof, and also about the usefulness of having other ways to handle and work with quaternions in Blender.
Again, the only case I’m making here is that the current approach is also good, and should be kept.
Hello guys!
I have some suggestions to improve the usability and readability of the dope sheet.
Right now the Dope sheet has a lot of redudant information when comes to Keyframes,
they are repeated everytime with the same opacity.
What about turning it down the general “dots” opacity for everything and only highlighting the last open property on the list.
That way is more easy to read.
Some nice aditions would be to pin objects to the top or group objects to easilly move the dots around.
And the ability to randomize and “staircase” the keyframes with a shortcut or button.
