The last years, at least in commercial work, having nonstop feedback until delivery, mixed with a bunch of different resolutions, got a big pain and sometimes launches big chaotic batches. If not needed I always do everything on the timeline, but as soon as it needs a batch, I’m lost finding a good healthy structure.
Right now I never split it into more than one batch, as going into every single on for just one shot for like just one change takes time, so I’ve switched to 2 variants:
A:
All resolutions going on their own way from the start to the end, so you have the same nodes with the same function over each other to quickly change sth. in every node on that “stack”. (Screen A) Pros:
You know how it looks in frame from start to end, especially within bigger setups and a client who wants
to see changes
Easy to add another resolution late in time
Every size can have completely different styles Cons:
You have to do every change in every node xTimes your resolutions
B:
One oversized resolution, as long as possible, and one point splitting it into the endformats. (Screen B) Pros:
As long there are no bigger changes in between, there are much less connections
Mostly one change needed for every resolution Cons:
The batch will explode, if you need to add another not frameable resolution or if everything needs
another style
With clients, some context at the end is lame and possible unviable in real time
At the end, both don’t make a lot on fun at some point, so I’m rly interested, if you are using a different workflow, with a much better management and less or no cons.
I render once at the same rez as the plate and use connected conform/auto replace with different timelines for each format. If there’s something truly weird happening like animation or pan n scan, I’ll set up some resize nodes as contexts for other formats so I can see if anything breaks downstream.
Now, if we’re talking about graphics or something else exotic where the renders HAVE to be different for each format, I’ll do as much as I can to a point and then branch off the main tree and have compasses or whatever that build for a specific aspect ratio, but this didn’t come up that often for me.
I’m also not fond of doing graphics in the same setup as my comp work. I usually do that stuff in the timeline because it gets tweaked to death. But that’s commercial finishing. Other types of work may elicit other opinions.
I have a similar approach to @Kirk . I’ll do my comps in batch at a resolution large enough to satisfy the needs of all of the subsequent deliverables. Usually what I do is work at the size of the original plate, since commercial editors tend to do things like blow up a shot significantly for the 16:9 version and less for the 9:16, for example. It’s a waste of resources to work on a 6k plate for a 9x16 deliverable, so I whenever possible I try to use a resize to create a region of interest to make my working space smaller. Like Kirk, I use connected conform for the shared segments and then use action in the timeline for repos and pan-n-scans on a per-shot basis.
For the most part I create HD deliverables and do timeline resizes. I use Topaz to scale up shots for certain resolutions if there’s an issue, but resolution for moving images is overrated.
Thanks for your replies.
Yes, I was more relating to exotic comps, where the first part might be already different for each size, then about 50%-90% of the steps are exactly the same for everything, but at the end different outcomes, animationpaths etc split it again. Mostly like in A. It is just a huge setup, for 50-90% of the same, that kinda doesn’t make any sense for me.
Using the same source as long as possible to interchange it in the timeline is def. the best go most of the time.
Ditto what those other kids said. As to Andy’s comment about resolution, I regularly bump up lower resolutions to match the larger plates, then resize the whole thing back down to the deliverable size in the timeline. For things like phone comps, it actually helps take the edge off.
In the few times that I’ve encountered this I’ll just call them different shots. Different base plate almost always means different setup for me. I know that’s not what you’re looking for though, so let’s talk it out!
I’d investigate mimic links and link expressions if there are indeed multiple things that are getting tweaked repeatedly throughout the comping and rendering of all of your versions, but I find that it’s important to be honest with myself about how valuable that’s going to be. I’ve spent tons of time making perfect little machines in batch only to tweak it once and then never touch it again.
It seems like you’ve got the whole ‘multiple outputs from action’ thing figured out, which would have been another suggestion.
I dunno, if you’re trying to automate a solution for cascading changes through different resolutions and perhaps timings, your options are pretty limited. Basically mimic and expressions, or, worst case, scripting.
I try to assess up front which things will affect every possible version so that if I need to break out a few things for different aspects, the commonalities will already exist. Like nose boogers. They have to come out of everything, so it’s best done as far upstream as possible.
I got back to this topic with @ChrisKasten in some bigger cgi setups and gave it a new try. Thanks to @fredwarren on discord, he wrote a small script on which I could expand and try around (Not really easy for nonscripting users like me :D)
Finally I got a rough dummy working
The idea is based on the variant B, where the whole workflow is in FullFrame 1:1, but all steps, that are different for different resolutions, are split where needed. A mux node with 5 Inputs will directly put them back into one string as soon as possible.
All of these muxes are linked to a “Hero Mux”. Now when having one of the 4 rendernodes in their resolution (+ 1 for fullframe) selected, the script will pickup information (shotname atm) from the rendernode and put it to the “Hero Mux” input selection.
Actually I somehow missed Freds reply and never worked on improving the script, sry.
Being on the thin line atm between spending more time finishing the script to be in batch faster or using workflows to just skip batch overall or in worstcase flame itself to be more productive for the problem.
Over the last year I went back to linked mux nodes and a manual one for the render to define the node manually. It isn’t much productive but still will get the job done when it’s needed.
