Keyframer Comp - 2021-04-12 12:29

Keyframer Comp

Link to main site


Thank you for sharing this one

Your welcome Achim, I figured it was just too useful to not share…

amazing work @keithlostracco ! Looking forward to using this

This is awesome Keith! Is there a way to lock the offset to current frame. I see you have SHIFT to lock off Y axis. Would be nice to lock X as well?

Thanks guys. @Jarrett actually shift does lock to offset frame while ctrl-shift locks to offset value.

wow! well done - this looks very clean :slight_smile: a much needed upgrade for integrating this workflow into UI/frontends.

Amazing @keithlostracco ! Looking forward to checking it out

Thanks @lucasm, @daniel.dalfovo . Check back in over the next bit, I realized I forgot to copy and pasting of keys so I’m adding that as well as few other additional features having a unique color per channel (that you can quickly edit), duplicate channels etc…

1 Like

I like that it is purely a panel and easier to integrate into other panels (vs a pane).

Minor thing: There is a new-ish widget called contextPath (soon to be renamed to something like operatorPath) that you can use to replace the squished up text string for Anim COMP - it may be better for switching paths.

Small RFE: could you make a top level parameter for fontface

Small issues:

  • drop down menus at wrong scale if dpi scale is not at 100%
  • there are a bunch of nodes in error or warning state that “pollute” any error DAT based issue logging

And a question:
Where is the keyframe data stored ? I’m asking because I always had a workflow in mind where the first and last keyframes of an animation sequence can be shared between multiple “sequences”.

@Achim thanks for the feedback.

You can currently change the font and or any text parameter in Keyframer/view/textSet but yeah I could float some of the more important Pars such a Font and Font Color (line thickness etc…) up to custom Pars on the comp easily enough.

Dropdown wrong DPI scale is a quick fix.

Yeah I’ve been procrastinating removing all those broken file path expressions. That point to actual source files on my computer (or anyone’s who has is working within Vision/Vision Library). Since they weren’t actually displaying full error’s on the node itself (only when viewing the par( or by the sounds of in an errorDAT…) it wasn’t a on the forefront of my mind. I’ll write a script to find them all and change them to constant values…

Regarding keyframe data, it’s not stored. All the keyframe data is in the keys tableDATs in the current AnimationComp. On an earlier iteration I was storing values but it got too cumbersome making sure two sets of data were always being updated in sync… I’m hoping that Derivative will be open to a new way of updating the keyframeCHOP (such as pushing/copying a Numpy array directly into the CHOP) so we could lose the DATs altogether.

All that being said, you can still access keyframe values easily via Python:

# get first key frame (first key of the first segment)
x = op.Keyframer.Channels['myChan'].segments[0].x0 
# get first key value (first key of the first segment)
y = op.Keyframer.Channels['myChan'].segments[0].y0 

n = op.Keyframer.Channels['myChan'].numSegments
# last key frame (end key of the last segment)
x = op.Keyframer.Channels['myChan'].segments[n-1].x1 
# last key value (end key of the last segment)
y = op.Keyframer.Channels['myChan'].segments[n-1].y1 

# other attributes are .inslope, .inaccel, .outslope, .outaccel 
# in / out refers to a "segment's" in and out handles (start/end) not a "key's" in 
# and out handles, if you want get the in and out slope of given key use:
keyInSlope = op.Keyframer.Channels['myChan'].segments[i].inslope
keyOutSlope = op.Keyframer.Channels['myChan'].segments[i-1].outslope

Long story short in my first iteration I started with a “keys” based approach but it go way too convoluted since handle type segments need 4 points.

I was thinking making a new list called “keys” that contains a list of “key” objects that simply refer to a given “key’s values” like the keys Dat but currently under the hood it isn’t really needed. Also you can directly see the issue with of using a “key” as a base data type by looking at a keys tableDAT of any animationCOMP with the last key having handles. Notice the last inslope/inaccel cells contain the values of the last key’s outslope/outaccel… It was much easier to work with segments, then they can have any number of points without needing to have any information about the previous or next segments, but now that that infrastructure is built based on segments, adding a “keys” list of “key” objects to access/modify a “key’s in/out” will be simple.

1 Like

I haven’t done these references outside of the extension but it should be fine as long as:

  • the extension is initialized
  • the channel exists in the connected animationCOMP

Thanks for the tip @greg! Since that current widget is already hooked up setting the value and updating view in particular way I don’t want to swap it out at this time but I can disable the label which will effectively have the same result!

Thanks for all the info. I’ll look into it asap

exactly what we need! BRAVO!

when a default bezier is added the default handles are…,how would I say …tangent?(smooth curve), but once i break that relationship(by trying other keyframe types) i see no way to set it back to default bezier handles smooth relationship? its always a sharp break at keyframe even on bezier) I might be missing something that was in the vid or notes.

excellent work!

@cod65 I think what your referring to is locking handles. Yes by default I unlock handles when two different function types are beside each other but if you switch back to Bezier (or another handle type) I don’t automatically lock the handles again but you can manually toggle lock handles on and off with ctrl-t keyboard shortcut

yes!, thks.


think what your referring to is locking handles. Yes by default I unlock handles when two different function types are beside each other but if you switch back to Bezier (or another handle type) I don’t automatically lock the handles again but you can manually toggle lock handles on and off with ctrl-t keyboard shortcut


I’d imagine this is probably a big hit to performance, but how about a way to visualize where on the curve the ‘playhead’ input is?

That’s interesting, do you mean like a dot that runs along the curve? I do have a (thin) time bar that shows where the playhead is but it’s be it a bit limited functionality for now, ie. you can’t grab it and scrub it. It’s also bit too thin and transparent I noticed.

Running a dot along each curve is interesting, I’m actually refactoring how the geometry is setup right now which should gain a significant performance improvement, so I imagine it would be too much of an additional hit.