Step 4: Upload and launch
The upload itself, the file cache that skips re-uploading unchanged files, the job ID, and what launching actually does.
This is where bytes finally leave your machine. Everything before this ran locally.
Skip re-uploading unchanged files
On by default. Before uploading, each file is fingerprinted in your browser and checked against what you have uploaded on past renders. Anything unchanged is reused straight from storage and never sent again.
- The big win is re-rendering: change one material, and only the
.blendis uploaded while a 5 GB VDB sequence is reused. - The cache is per account and content-addressed, so a file uploaded from the add-on is reused by the browser and the other way round.
- Cached files are kept for 30 days from their last use, which resets every time they are reused.
- Fingerprinting reads every file once, so on a very large scene the progress bar sits in Checking your files for a while before the upload starts. Untick the box to skip that and upload everything.
- The count of reused files is shown during and after upload.
The upload
Files stream from your browser directly to cloud storage using pre-signed links, four at a time. No file bytes pass through our backend. You can cancel mid-way; already-finished files stay uploaded, and retrying only sends what is missing.
The job ID
Every job gets an ID, shown with a copy button once the upload finishes. It is the URL of the render (?jobId=...), the thing to quote in a support mail, and how you get back to a render later. Recent jobs are also listed on the dashboard home.
Launching
Launch render reserves credits, provisions a private tunnel for live streaming, and rents a GPU machine. The button shows how many frames it is about to render. From here you land on the live view, and the URL carries the job so a reload or a shared link goes back to it.
If the machine we picked gets taken by someone else first, we retry on another one, up to four times, before reporting a failure. A failed launch does not consume credits.
