Blender work is not a shot submission: no Export, no version, no validation, QC or delivery. It is "Ctrl+F12, but on the farm", so it is modelled as what it is — a queue entry and nothing more. That turned out to need very little. Claim, progress, fail and complete-render already tolerated a job with no Export behind them, so a Blender job reuses the whole lifecycle; RenderJob gains projectId, label and submittedBy so a job with no shot code still has something to show. Capability gating is new and was already missing: the claim now filters job types by the machine's reported tools. Without it a workstation without Blender would claim Blender work and fail it repeatedly, burning the attempts while a machine that could have rendered it sat idle. The worker asks for Blender jobs unconditionally and the server refuses them — trusting the worker to self-select would have left the same hole. The runner treats a clean exit with no saved frames as a failure: Blender exits 0 when a frame range is empty or an output path is unwritable, and a job that silently rendered nothing is the worst outcome available. Standalone jobs auto-requeue on a transient failure like any other work; delivery builds are deliberately excluded, since a half-written package wants a human first. Adds the Blender add-on (BlenderPanel/) and its docs. The add-on refuses to submit an unsaved file — the farm opens the .blend from disk, so unsaved changes would render the previous state without warning. Its payload is pinned by a contract test, since add-on and server only ever meet over JSON. Worker 1.5.0. Adds migration 20260815000000_blender_render_jobs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.2 KiB
VFXReview — Blender Submit
A Blender add-on that queues the open .blend on the studio render farm instead
of rendering it locally. Ctrl+F12, but on the farm.
What a Blender job is (and is not)
Deliberately the simplest thing in the pipeline: a queue entry and nothing
more. It has no Export, takes no shot version, and is never validated, QC'd or
delivered. The .blend is expected to be ready to render — output path, format
and frame range already set — and the farm just runs it.
That is the whole difference from an After Effects export, which is a shot submission and carries the full lifecycle behind it.
Install
- Edit → Preferences → Add-ons → Install… and pick
vfxreview_submit.py. - Enable Render: VFXReview — Submit Render.
- Expand its preferences and set:
| Setting | Value |
|---|---|
| Server URL | https://review.twotalesvfx.com |
| API Key | matches API_SECRET_KEY on the server (same key the AE panel uses) |
| Artist Email | recorded against the job so the queue shows who submitted it |
The panel appears under Properties → Output → VFXReview.
Submitting
- Refresh Projects (the circular arrow) and pick the project.
- Optionally set a Label — defaults to the
.blendfilename, and is what the render queue shows, since there is no shot code. - Urgent makes the job claimable outside the render window, ahead of normal work.
- Submit to Render Farm.
The panel shows the frame range, engine and output path it will send, read from the file as saved. Nothing is changed on submission.
The file must be saved first. The farm opens the .blend from disk, so
unsaved changes would render the previous state without warning — the add-on
refuses to submit a dirty file rather than let that happen.
Track the job on the web app under Pipeline → Blender renders: live progress, current frame, ETA and the machine running it, with cancel and requeue.
Which machines can render it
Only workers with blenderPath set in their config.json and the executable
present. The worker reports Blender at registration and the server hands
BLENDER_RENDER jobs only to machines that have it — a machine without Blender
can never claim work it could only fail.
Verify on a worker with:
.\VFXReviewWorker.exe --check
Blender is listed as optional there: a machine without it stays perfectly valid for After Effects work.
Notes
Paths must resolve on the render machine. The .blend path and its output
path are submitted as the artist sees them; the worker applies its own
pathMappings before opening the file. A path on a drive letter the render
account cannot see is the most common reason a job fails immediately.
Renders as saved. The add-on sends the scene's own settings. The manifest supports overrides (samples, resolution %, device, engine) for future use, but nothing in the UI sets them today — one place for render settings is the point.
Exit code 0 with no frames is treated as a failure. Blender exits cleanly when a frame range is empty or an output path is unwritable, so the worker checks that frames were actually saved before reporting success.