sourceRectAtTime() calculation is getting delayed by 1 second for no reason

[ricar2]

I got a simple animation of a shape layer that moves into frame and its size is controled by sliders on its layer and also a couple of sliders on a "ctrl" layer as well.

The feature I'm implementing at the time is to have a image file to be masked by this shape layer and also move along staying perfectly centered using sourceRectAtTime();. (this part I removed from my files for simplicity sake)

But this image kept moving in weird pattern and on a uncalled time.

I got a text layer checking for the values for the sourceRectAtTime(); and for some reason the animation I did from 0 to 10f is not accounted untill the playhead reaches the 1 second mark.

that looks like a bug to me.

I removed everything else but the things that are essencial for this layer to work.

Tested on AE 25.5.0 (build 4) and AE 24 24.6.4(build 3)

[Dan Ebberts]

I'm stumped. I might be missing something obvious, but after picking through this in detail, I can't spot anything that would cause what you're seeing.

[ricar2]

Hey Dan, sorry that my file didn't show that so clearly.

I've updated the file on dropbox here.
I've added a star shaped comp there that takes the square position + width/height for is own positioning.
You can see that it will move from right to left for 10 frames from the 1s mark for no reason.

Hope it helps

[Dan Ebberts]

Sorry, I wasn't clear. I do see what you're seeing--I just can't find an explanation for it. I'd guess it's a bug, but there may be something I'm missing. Maybe someone from Adobe will chime in.

[Roland Kahlenberg]

You need to define a time for sourceRectAtTime() - in your case, this worked - 

t = thisComp.layer("Square_03");
sr = t.sourceRectAtTime(2);
posx = t.transform.xPosition;
posy = t.transform.yPosition;

[posx-sr.width/2, posy-sr.height/2]

If you like to build stuff like this and even more interesting Responsive and even Adaptive Design Components - and complex rigs using sourceRectAtTime(), look out for my Advanced AE course - hopefully, I will run it between Jan-March, next year. 

[Dan Ebberts]

OK, I think I've figured it out. It looks like, at some point Square_03 got trimmed so there's one second missing from the start of the layer, and then it was repositioned in time so it lines up again with time = 0. If you use a text layer with this expression:

thisComp.layer("Square_03").sourceTime()

you'll see that at time = 0, the layer's source time is 1.0, which is where the animation starts.

If you use this expression:

thisComp.layer("Square_03").startTime

You'll see that the layer actually starts at -1.0. So, not a bug. That should get you headed in the right direction.

[ricar2]

Gee Dan you are right.

Sorry for all the mess, I did look at the time if the layer was trimmed but I shoud had pushed it way longer to see the issue.
Now thinking about it I prob had the whole thing animated, then when the client asked to shorter it all and I prob just trimmed to work area cutting the beggining of the comp.
Didn't know that could create this kind of mess TIL

But thanks to helping me on that detective work, you saved by bacon!

[Roland Kahlenberg]

Dan, this is major sleuthing!  🙂

Never seen a trimmed clip exhibit such a behavior. For OP, did you try to input the "2" as the sourceRectAtTime() time argument? 

And do take note that valueAtTime() needs accounting for inPoint and will throw a curve ball if you're not mindful.

 

[Dan Ebberts]

Roland, I think providing a fixed time like 2 to sourceRectAtTime() won't work in this case because the size is animated and the expression needs to track that. If you don't provide a parameter, it defaults to time, which is what is needed here (except for the trimming issue).

[Roland Kahlenberg]

Adding the time argument into the sourceRectAtTime() method actually worked for me - to stabilize the move - the centered object stopped straying. Perhaps the OP had set it up to perform a more unique move because at first glance, the set up looked more elaborate than how I would set it up. So, first thoughts for me was to get rid of the straying motion.

An important take away is that sourceRectAtTime() is never wrong. It's always correct and it's always user-error or user-related error that throws unexpected results.