Forum Replies Created

  • Whoa! This is amazing! Emailing you now!

  • Here are the steps to experience what I’m referring to:

    – Create a parent comp
    – Create child comp inside it
    – Create square inside child comp
    – Set expression for rotation of that square (This does a 100,000 iteration for loop which pushes the CPU as a complex expression would.)

    //////////
    val = 0;
    for( i=1; i <= 100000; i++){
    val = i;
    }
    transform.rotation = val;
    //////////

    The square won’t move, the point is just to emulate fairly demanding expression code. Now go play from your parent and you’ll see it of course grind away as it generates the ram preview and then play smoothly once it’s in ram. You’d think that it was now done with processing the contents of that child comp but it isn’t so. If you make the precomp 3D enabled, add a camera and move the camera slightly and press play again, you’ll see it’s clearly running that child comp expression code again. Why would it do this?

    To further clarify what’s going on, add some heavy adjustment layer effects inside your child comp. Notice that when you press play from the parent it will work extra hard for that first time generating the child ram preview. After that, no matter what you do in the parent, it won’t have to process those adjustment layers again until you edit the contents of the child comp. However, the expression code will still run.

  • Here are the steps to experience what I’m referring to:

    – Create a parent comp
    – Create child comp inside it
    – Create square inside child comp
    – Set expression for rotation of that square (This does a 100,000 iteration for loop which pushes the CPU as a complex expression would.)

    //////////
    val = 0;
    for( i=1; i <= 100000; i++){
    val = i;
    }
    transform.rotation = val;
    //////////

    The square won’t move, the point is just to emulate fairly demanding expression code. Now go play from your parent and you’ll see it of course grind away as it generates the ram preview and then play smoothly once it’s in ram. You’d think that it was now done with processing the contents of that child comp but it isn’t so. If you make the precomp 3D enabled, add a camera and move the camera slightly and press play again, you’ll see it’s clearly running that child comp expression code again. Why would it do this?

    To further clarify what’s going on, add some heavy adjustment layer effects inside your child comp. Notice that when you press play from the parent it will work extra hard for that first time generating the child ram preview. After that, no matter what you do in the parent, it won’t have to process those adjustment layers again until you edit the contents of the child comp. However, the expression code will still run.

  • Actually I wasn’t quite right, what is happening is the precomp is being put into ram but the complex expression code in the nested comp seems to still run. How can I get it to not run that code in the nested comp?

  • Thank you! I found the problem.

    I had an expression some nested comps which was linked to a slider outside of the comp:

    temp = thisComp.layer(“Pupils”)(“ADBE Effect Parade”)(“joystickLimit”)(“ADBE Slider Control-0001”)*2;

    PHEW! That’s a relief. Thank you so much for your help pointing me in the right direction!

  • Hi Dave,

    Thanks for taking the time to reply. Forgive me, I should have been clearer. Joysticks & Sliders is a plugin for AE:

    https://aescripts.com/joysticks-n-sliders/

  • Thanks!

  • Thanks for taking the time to reply. I really appreciate it.

    I was making a mistake – I was turning motion blur on instead of enabling collapse transformations 😉

    Works now!

    Thanks again
    Rob

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy