The message lands at 7pm for a 9pm delivery. "Small change, can you make the logo blue instead of red?" Your stomach drops, because you know the rend
The message lands at 7pm for a 9pm delivery. “Small change, can you make the logo blue instead of red?” Your stomach drops, because you know the render took six hours last time. The instinct is to panic and re-render everything. The move that actually saves you is to slow down for sixty seconds and work out how little you can get away with re-rendering.
The first five minutes: do not hit render yet. Work out the scope of the change. If it touches one element, one shot, or one pass, you re-render only that, not the whole sequence. If it changes lighting or the whole look, you are re-rendering everything and your only lever is more machines. Knowing which of those you are facing decides everything that follows.
Triage: what actually changed?
The reason scope matters is that a smart render setup lets you swap one thing without redoing the rest. If you rendered in layers or passes, a logo colour change might mean re-rendering one element and recompositing, which is minutes, not hours. A lighting change is a different animal, because it touches every frame. Here is how I sort it the moment a change request lands.
| What changed | Re-render scope | Fastest path |
|---|---|---|
| One element (a logo, a colour, a texture) | That element or pass only | Re-render the layer, recomposite |
| One shot or a few frames | Just those frames | Render the frame range, splice in |
| Camera or timing on one shot | That shot’s frames | Re-render the shot, not the sequence |
| Lighting or full look change | Everything | Optimize fast, then burst across machines |
When you genuinely have to re-render everything
If the change hits every frame and one machine cannot finish in two hours, the only way through is more machines at once. Spreading the sequence across rented GPUs can turn a six-hour render into a bit over an hour, though not in a clean multiple, and you have to count the setup and upload time against your two hours, which is real. Bursting at the last minute is also the most expensive way to render, since a rented server bills for every hour it is awake plus a little setup, so emergencies are not where cloud rendering is cheapest. It is where it saves the relationship anyway.
I keep an account ready precisely so this is not the moment I am learning the tool. When I burst, I use iRender for the speed and the ability to run my exact setup. The real lesson from every one of these nights is in the buffer, though, so the delivery playbook is the thing that stops the 7pm message from being a crisis at all.
Caught two hours out with a full re-render? Bursting across rented GPUs can claw the time back, as long as the account is already set up. See iRender multi-GPU servers
FAQ
How do I re-render fast when a client changes something last minute?
First work out the scope. If the change touches one element, render that layer or pass only and recomposite. If it touches one shot, render just those frames. Re-render the whole sequence only when lighting or the entire look changed. Rendering in layers and passes is what makes most last-minute changes a small job instead of a full redo.
Can a render farm save me when I am out of time?
It can, if your account is already set up. Spreading a full re-render across rented GPUs can cut hours down to around one, though you must count setup and upload time, and last-minute bursting is the priciest way to render. It buys back the deadline. The better fix is a buffer so you are not in that spot.
See more: The Real Reason Your Render Time Estimate Is Always Wrong
Image source: MAXON
COMMENTS