[Joseph Burns]

FWIW, I had this error coming up due to a FAT-32 drive being selected as a render target. As I’m sure most of you know, that volume format has significant restrictions, so no surprise there, except that I had it targeted in the first place. Oops.

Just another troubleshooting step for people with this error.

[Joseph Burns]

So to follow up and give some closure here, I did the precompose and comp duplication. Specifically, I precomped everything but the cameras, then duped the outermost comp by the same number as I had cameras, then deleted all cameras but one from each comp, so that I ended up with 1 camera per comp. This allowed me to put all the cameras in the render queue and let it render overnight. And then some 😛

Render was murder as the motion blur didn’t work for some 3D boundaries, so I had to use CC Force Motion Blur. So I was going to have to precomp for that anyway.

Thanks again for the pointers.

[Joseph Burns]

This is for an on-disc menu system. The menus exist in a created 3D environment, with each in a different location. Navigating from one menu to the other moves the virtual camera to a different location where the next menu lives. Six of the cameras run the length of the comp to provide the loops when you are parked on a menu. Two of the cameras are for the transitions where the camera flies from one menu to the next.

So, alas, there is no “cutting” per se. The transition cameras will be divvied up into the individual moves, but those edits are already lined up in the animations.

There’s a great deal of dynamics on the “walls,” so keeping some consistency is important to sell the conceit of the thing, since parts of the environment are common amongst the views.

The idea of precomping everything seems the optimum approach (as if I didn’t have enough nesting already!). Seems like an ideal project for scripting, though, if I decide to wade into that end of the pool.

Thanks for the responses.