Skip to content

Transform Mask Animation and Scalar Channel Changes

Eoin O'Neill requested to merge (removed):ani/transform-translation into master

I'm working on transform mask animation while resolving problems that occur along the way. I'm also taking this time to address necessary scalar channel changes and try to streamline the copying process for animation channels (since this is where 99% of caching errors seem to stem from.)

Roadmap

  • Implement Translation Keyframes (x, y position)
  • With reduced feature-set for simplicity, get working animation cache to render consistently.
  • Clean up KisKeyframeChannel copying process to try to reduce errors. As of this MR, KisDefaultBoundsBase is now set in a separate pass during the image cloning process to address time synchronization issues.
  • Implement Scaling Channels (x, y).
  • Implement Rotation Channels (x, y, z).
  • Implement Shear Channels (x, y).
  • Clean up channel creation / fetching process. Currently, QStrings are passed as identities which works in some cases, but the conversion of QString to KoID or visa-versa is ugly, error-prone, and happens far too often in the code base. In other words, it needs to be rethought and conversion utility methods need to be considered.
  • Rethink how other Transform properties need to be animated. Previously, an additional copy of TransformToolArgs was animated using a special keyframe channel type, which had a lot of unnecessary data / logic duplication.

Recurring tasks / thoughts:

  • Continue to examine keyframe channel copying process.
  • With minor opacity channel changes comes an interesting proposition on animating other nodeProperties which might open more opportunities later. I should keep this in mind as I continue to work on this MR. If you can think of other things that can be animated, let me know. :)

Current Blockers

  • Transform mask origin is set incorrectly during initial channel creation. Because of this, scaling / rotation and shear are disabled (since they rely on having a properly set origin.) You can re-enable them if you'd like, and change the origin position, but be aware that behavior is somewhat erratic.
  • Likely related to blocker 1, but some safe asserts have flared up that need to be investigated.
  • When the origin is changed, we should try to convert the animation to accommodate for new origins. Currently, changing the origin changes the animation behavior (which makes sense) but it would be nice to have some ability to compensate for origin changes wherever possible. Operations like rotation might not be able to conpensate for these changes, as the origin of the object dictates movement behavior. I might need to study tools like blender to get a better understanding of how they balance this.

GUI Issues

  • Importantly, we haven't touched the curves docker UI yet and will be tackled in a separate MR. However, getting some animated transform features will give a good roadmap for what needs to be done to improve the overall UI/UX of creating and modifying scalar channels.

How to Use

As mentioned above, the curves docker needs a lot more love. However, for the time being, clicking the "+handle" icon while a Transform Mask layer is active will add both an X / Y position channel. Once a channel is created, any transformations made with the Transform Tool will either modify the current keyframe (if key data exists at the current time stamp) or insert a new keyframe at the current time. Default interpolation is currently set to linear, but all interpolation modes should work and behave as expected.

Additional Notes:

I'll make a more thorough overview of all of the changes later. Importantly, however, opacity channel changes have also been made to try to streamline the interaction between GUI and Opacity and bring it in line to the aforementioned changes to the channel copying process.

Edited by Eoin O'Neill

Merge request reports

Loading