hold frames and time remapping bugs

[urbanstarship]

I often do animations using pre-comps, hold keyframes and time-remapping.  Lately this is incredibly buggy, and frames are not holding, making this technique I've used for over a decade unworkable.  I'm using v 22.4 on a Mac, and I've purged the cache repeatedly with no difference.

[Rick Gerard]

It would help if we could see an example comp with screenshots. I have no problems with my M1 MacBook Pro and the latest AE or AE Beta versions.

[urbanstarship]

It's difficult to demonstrate in a still or two, but I'll try.  The animation changes at frames 30, 32 and 34, but I've had to stagger the time-remap keyframes because they are changing a frame early.  Sometimes they randomly change to being in sync...there's no obvious pattern...sometime the keyframes change nothing.  All the comps have the same frame rate, so it's not that.  I'm on a 2018 MacBook Pro on Big Sur.

[Warren Heaton]

Have you tried turning Motion Blur off?

If it turns out you're seeing frames 30, 32, and 34 as expected when that's off, try pre-rendering Comp Proxies.

[urbanstarship · Accepted solution]

Turning motion blur off didn't affect it, but turning on Collapse Transformations seems to have corrected it!  Something funky going on there, I've never known that setting to affect time remapping.

[Warren Heaton]

Oh, interesting.  Thank you for reporting back.

Actually, that makes sense as Collapse Transformations forces After Effects to look at the source footage as well as the rendered frames.

[anders_hattne]

I have problems with this too.
Using  two keyframes Time-remap to animate in, second keyframe is a hold keyframe.. Hold for a few seconds, then keyframe the out animation. But on the frame before the off animation, there's a glitch and I have no idea what frame it shows ( the first linear keyframe after the hold keyframe that is..).
Collapse transform does not help...

[Warren Heaton]

Try rendering the Comp that's being used as a Layer with Time Remapping and then replace the Layer Source with it.  This way, you're using a rendered movie rather than a nested Comp.

[anders_hattne]

Sure, but that is not ideal, since I get changes quite frequently, prices change, wording changes. I'd end up with a whole range of unecessary files..
Interestingly, I have older projects where I use the same technique and there is no weird jump from a hold frame to a normal one.
What I do.. but it's not as clean, is cut the precomped layer in two, where the first layer has the animation in (0-1s)
and then the out animation on the ssecond the first keyframe being 3 seconds.. and then I use an expression to turn off the visibility of first copy at the inpoint of the second.. it's a simple work around, but I'd prefer to have on layer rahter than two. Especially, since it has worked in the past!!

[Rick Gerard]

Time Remapping keyframes are time values. It gets confusing. If the distance between keyframes matches the time difference, then that part of the layer (footage or nested comp) plays in real-time. Shorten the distance between keyframes, and the footage speeds up, increase the distance, and the speed slows down. Once you get that figured out, you are halfway to understanding how Time Remapping works. 

Only Temporal keyframe interpolation is available for Time Remapping. Understanding the Graph Editor is difficult and editing time using the graph editor takes practice.

Nothing has changed in Time Remapping. If you are getting different behavior, the Keyframe Interpolation is different in the two different comps. 

Rendering a layer and then applying Time Remapping requires you to blend frames. If you Pre-compose an animation, then apply Time Remapping, and you have not changed the Pre-comp's settings from the default to Maintain Frame Rate when nested, time remapping has the effect of moving all of the keyframes around to change the timing, and you end up with no blended frames. This is a lot more useful workflow for animations.

Show us timelines with the modified properties of problem layers by dragging them or copying and pasting them to the reply field so we can see them without downloading them, and we can probably help you figure out what is going on.

[reubenlara]

There is still a bug with motion blur when you using hold frames in time remapping. Please see the simple example here. the glitch is labeled as a marker in the "Remap" comp: 

[Rick Gerard]

Your "glitch" problem is caused by the one-frame jump in time. To fix the problem, open the graph editor, convert the keyframe, and then drag the starting time value down to match the hold time. The graph needs to be set to edit and view the Value graph, not the speed graph.

It's not a bug. It's just a workflow problem. 

[reubenlara]

Thanks for the quick response Rick! But this still doesn't allow me to remap from frame 75 to 87, as it's now remapping from 25 to 87. I understand that that comp's remap is one-to-one with the nested comp, but if we move the ramapped "75-87" keys back a dozen frames, say to start at frome 40 of the "Remap" comp,  i'm still getting that motion blur artifact at frame 39 of the "Remap" comp.