addKey and setValuesAtTimes calculation time

Find out why the . goes before the /

Moderator: Paul Tuersley

Post Reply
ajk48n
Posts: 20
Joined: January 17th, 2007, 3:02 pm

I'm trying to add keys on layers that already have a large amount of keys, and I'm having some trouble getting the processing time down to an acceptable length.

Here's what I've found so far.

Adding keys with setValueAtKey or setValueAtTime takes massively longer than putting all the times and values in two arrays and running setValuesAtTimes.

However, setValuesAtTimes (and the rest of the setValue methods) don't return the key indexes of the newly created keys.

So, if I want to edit the new keys later, I need to do one of the following:

a) run nearestKeyIndex for each of my times to get the index of each new keyframe

Code: Select all

setValuesAtTimes(times, values);
for (i=0;i<times.length-1;i++) {
    indexes.push(nearestKeyIndex(times[i]);
}
2) run addKey to create a blank keyframes at the time I want which returns the key index I want, and then overwrite the value when running setValuesAtTimes

Code: Select all

for (i=0;i<times.length-1;i++) {
    indexes.push(addKey(time));
}
setValuesAtTimes(times, values);
Now, neither of these are optimal since running addKey or nearestKeyIndex takes an exceptional amount of time if a property has a lot of keyframes

So, any suggestions on how to speed up getting all the indexes of newly created keys?
Or is there maybe some undocumented way to get the list of indexes back from setValuesAtTimes()?
beginUndoGroup
Posts: 81
Joined: November 27th, 2012, 6:41 am

Hello, i'm also interested in this. I've got no answer, but few comments.

First what do you call a large amount of keys ?
Note than when you run > keyframe assistant > convert animation to keyframes, AE converts at most 30 seconds (at 25 fps that's 750 keys), even if your composition is longer.
There might be a reason to this, properties are not supposed to carry thousands of keyframes...

Most of the time, when setting keys between t1 and t2, i remove existing keys before: so the timeline is split in 3 segments [start,t1[, [t1, t2], ]t2, end].
Then you only need to know the index of the last key in the first segment, the number of keys you add, and the index of first key in the last time segment.
So you use nearestKeyIndex twice, not (#keys you add) times, and you don't need to store an array of indices, only first/last.

If the keys you add overlap existing keys and you want to keep those existing keys, i don't see another solution than your first method... yes it is slow.

Xavier.
ajk48n
Posts: 20
Joined: January 17th, 2007, 3:02 pm

Thanks for the comments. I'm talking in the range of 500-1000 keyframes, which have been gotten from motion tracking.

Unfortunately, I have no way of knowing where the end user is going to be putting the keyframes, so they may well be overlapping previous keyframes.

Although, you did give me a good idea.
I could test to see if the first new key is being put later than the last old key. If that's the case, then it will be trivial to figure out what the new key indexes will be, and I can skip the slow functions. If they are going to overlap, then it won't be any slower than it is now.

Of course, if anyone else has any other ideas for a more general solution, those would be much appreciated as well.
Post Reply