Posterize Time effect breaking the integrity of a pre-comp, causing layers to "time slip"

[Stephen Barrante]

Hi folks, we're experience a really strange issue with the Posterize Time effect, and at the worst possible moment for the project.

The addition of Posterize Time over some nested Pre-comps causes the layers in those pre-comps to become out of sync or "time slip". 

Quick summary of set up:

We have a 23.976 pre-comp ("comp A"), dropped into a main composition ("comp B"), of the same dimensions and frame-rate. Inside comp A, we have several animated layers which are tracked over live-action footage. Some layers are manually key-framed, but in all instances the motion is synced and plays back as expected if we maintain the full-frame rate.

When we add Posterize Time effect to comp A's layer directly, OR as an adjustment layer in comp B, so it effects all the comps below, such as comp A, it causes the content in comp A to shift out of sync. For instance it might shift our live action a few frames forward and the tracked / composited laters a couple frames earlier.

Our expectations are that comp A layer should be treated as "footage" in comp B, and it should, in effect, "flatten" all the laters inside comp A and any posterization would be applied uniformly. We don't care what frames it drops, as long as they are done together. Also worth noting that we do not have collapse transformations enabled.

Attempts to solve have included:

• Nesting comp B into another comp and applying the effect to the whole sequence
• Using expressions to Posterize Time
• Interestingly enough, dropping comp A into a comp that itself has a lower frame rate, rather than using the Posterize Time effect, also produces this problem. Which partially eliminates Posterize Time as the main culprit but doesn't really shed any light on to the root cause.
• Also worth noting this effects ALL comps that any animated content on top of footage that should remain in sync.

The only solution we have is to pre-render each of these comps, bring them back in and THEN drop their frame rate, but we're really trying to avoid that at the moment – we're neck deep in client rounds of feedback.

For what it's worth I've attached two images of the problem. What you are seeing is comp A, with and without the posterize time effect enabled. The pencils should not be separated from eachother.

Appreciate any help!

*After Effects 24.5.0 (Build 52) Mac Studio Ultra

[Rick Gerard]

Try dropping the comp with problems in a new comp and applying Posterize Time to the nested original comp. That should solve the timing problem. 

Dragging screenshots to the reply field makes them easier to see. Screenshots with the whole UI showing and the modified properties of the problem layers (press uu) make problems much easier to solve. Just an image of the render does not tell us anything about your workflow.

[Stephen Barrante]

Hi Rick - appreciate the response as always. Unfortuntaely I can't provide much context to the comp or file setup due to the sensistivity of the project. I can say that the very basic structure of comp A is:

Layer 1 - tracked content / distorted using corner pin

Layer 2 - manually animated content over the footage, fully aligned

Layer 3 - graded footage (pro-res)

Everything behaves perfectly until I drop this comp into another comp and throw posterize time over it. 

I did try nesting the comps previously – was hoping that would be a quick solve but alas it didn't work. As mentioned before, both nesting and dropping into a comp with the lower frame rate produced the same results.

Stephen

[Rick Gerard]

The quickest solution is to select your main comp without posterize time and then choose Composition/Pre-render from the menu. Drop the rendered comp in a new comp and apply Posterize Time. 

If I use a tool that taxes the system, like Rotobrush, or frames take more than a few seconds to render, I almost always Pre-render the comp before completing the final composite. If that workflow is good enough for Pixar, Disney, and the other effects houses, it's good enough for me.

[Stephen Barrante]

For sure - and that will likely end up being the way we have to workaround the problem. Unlike those houses, we're itterating multiple rounds in a single day and have limited time to kick out new renders. Just the nature of the beast. 

When I come up for air I'll submit a bug report to see if the dev teams can investigate this issue.