[Conrad Olson]

I had that issue when I was using an integrated graphics card. You can stop it happening by changing your Fast Preview options to adaptive resolution instead of using the OpenGL options. You can access these options by clicking on the small icon with a lightening bolt on at the bottom of the composition.

OpenGL is a language that accellerates certain graphics operations using your graphics card. There is a list of graphics cards that the After Effects OpenGL is fully compatible with on the Adobe website.

OpenGL is not vital and only works with certain effects. As I usually use other effects I tend to have my preview mode switched to adaptive resolution most of the time anyway. After Effects seems to be more stable in this mode.

This tutorial does a pretty good job of explaining the pros and cons of using OpenGL: https://library.creativecow.net/articles/mylenium/open_gl.php

[Conrad Olson]

It’s not possible I’m afraid. Each menu has it’s own spearate audio track.

[Conrad Olson]

Hi Dan,

Sorry I didn’t reply sooner but was ill at the end of last week but back in the office now.

I’ve restarted AE (and the computer) and have tried this on a brand new project but I’m still having the same problem. It doesn’t look like a bug or anything, it just looks like I’m doing it wrong.

I’m not sure if I have made my problem clear. I have a wipe transition on a layer inside a pre-comp. This pre comp is longer than the main composition that it is nested in but when I created the expression the first frame of the pre-comp was on the first frame of the main comp. I have keyframed a slider expression control that is on a null layer inside the main composition. These keyframes are synced to something that happens in the main comp and this is where I want the transition to occur.

For example the main comp is 100 frames long and the pre comp is 500 frames long. Frame 0 of the pre comp is at frame 0 in the main comp. The transition starts on frame 10 in the main comp and lasts 10 frames. This works fine. The transition inside the pre comp starts at frame 10.

But if slide the pre comp back 5 frames inside the main comp so that frame 5 of the pre comp is at the first frame in the main comp the transition no longer happens in line with the key frames but starts 5 frames early. I can slide the layers inside the pre comp so that the first frame of the pre comp is still at the first frame of the main comp but I use the pre comp else where in the project so don’t really want to change it.

It seems to me that the expression in the pre comp looks at the position of the keyframe in the main comp (frame 10) and positions it at the same point in the pre comp (frame 10) regardless of whether or not they are at the same point in the main comp.

Hope this makes more sense. Thanks.

[Conrad Olson]

So what I’d done should have behaved the way I expected? I’ve just spent 20 mins messing with the expression, enabling and disabling it, and couldn’t get it to behave.

If I moved the keyframes around inside the main comp the transition would change, but only when the keyframes were in the wrong place.

I thought I had to get the time of the parent comp and use it inside the pre-comp somehow.

I’ll give After Effects a re-start in a minute and see if it works again.

Thanks for the quick reply.

[Conrad Olson]

That’s pretty cool. Thanks. It’s a shame you have to create all of those separate compositions though.

[Conrad Olson]

I’ve just got a version of the porject working with your solution Dan (I’m still only guessing what the array values from the velocity are) but the angle seems to be more jumpy as the particle emmiter moves around. Is that because the velocity property is more accurate than the was I was doing it? I’m guessing the inaccuracy in my method smoothed out the change in motion at sharp corners in the motion path. Would that happen?

[Conrad Olson]

I’ve just got a version of the porject working with your solution Dan (I’m still only guessing what the array values from the velocity are) but the angle seems to be more jumpy as the particle emmiter moves around. Is that because the velocity property is more accurate than the was I was doing it? I’m guessing the inaccuracy in my method smoothed out the change in motion at sharp corners in the motion path. Would that happen?

[Conrad Olson]

I thought there might be a solution using the velocity property but I could find anywhere in the manual that told me what it returns. What values are in the array that it generates? Are v[1] and v[0] the vertical and horizontal speeds of the motion?

Thanks

Conrad

[Conrad Olson]

I thought there might be a solution using the velocity property but I could find anywhere in the manual that told me what it returns. What values are in the array that it generates? Are v[1] and v[0] the vertical and horizontal speeds of the motion?

Thanks

Conrad

[Conrad Olson]

Cool, thanks. I’m glad I’m doing it right.

I’m a little comfussed about the lookAt command and how it works. I’ve just read about it in the manual but it doesn’t make sense to me. How would I use that instead?

Cheers

Conrad