The OmnibusCloud add-on lets you render Blender scenes on the network without leaving Blender: sign in, choose what to render, press Render — the scene is uploaded, split across the machines helping you, and the finished frames or video come straight back into Blender.
This guide covers installing the add-on, your first render, the two output modes — a single image and an animation — and what happens when your scene contains a simulation. Cycles, Eevee and Grease Pencil scenes all work.
Before you start
You'll need two things:
- An OmnibusCloud account — the same one used across the portal and the client. If you don't have one, you'll create it during sign-in.
- Machines to render on. The add-on submits work into a scope — a campaign or a private group with machines connected to it. That could be a campaign → where the community helps render your film, a private group → pooling your team's workstations, or simply your own machines running the OmnibusCloud client →.
Blender 4.0+ on Windows, Linux or macOS (Apple Silicon).
The add-on does not require the OmnibusCloud client on your machine — they are independent and play different roles: the client contributes a machine's power to the network; the add-on submits work to it. Install either, or both. They coexist happily on the same machine: put the client next to the add-on, and your workstation becomes one of the nodes rendering your own jobs — while a weaker machine can stay a pure submitter and let the network do the heavy lifting.
1. Install the add-on
Download the extension zip for your platform — win-x64, linux-x64 or osx-arm64. It's self-contained: no separate runtimes to install.
In Blender: Edit → Preferences → Add-ons → ⌄ → Install from Disk…, pick the zip, and enable OmnibusCloud Render Bridge.
Open the OmnibusCloud tab in the 3D-viewport sidebar (N key). On first open the panel connects for a moment, then asks you to sign in.
2. Sign in
Click Login — your system browser opens with the OmnibusCloud sign-in form. When it confirms You're signed in, close the tab and return to Blender: the panel now shows your account in a single identity row at the top, and below it — the Render panel. That one panel is the whole workflow. You sign in once; the add-on keeps your session across Blender restarts, and your tokens never enter Blender itself.
3. The Render panel
Top to bottom:
- Target — where the render runs: your campaigns and private groups.
- Output — Image or Animation, with the frame (or frame range) read from your scene.
- Format — chosen right in the panel: PNG, OpenEXR, JPEG, TIFF or WebP for images; alpha (including Film → Transparent) and bit depth travel with the scene.
The panel also reads your scene and suggests a suitable mode — a Recommended line with a one-click Use recommended button. It never switches anything by itself; it just saves you from rendering a 250-frame animation as a single still by mistake.
Resolution comes from your scene, exactly as you set it for a local render — there's nothing to configure twice.
The status line above the Render button always tells you where you stand. If something blocks the render — say, the scene isn't saved — the panel says so and offers a one-click fix right there.
4. Render an image
Set Output to Image, check the frame, press Render. The add-on uploads the scene, validates it, and submits the job — one click does the whole chain.
For a heavy frame, tick Split frame across machines: the frame is cut into tiles, rendered in parallel and stitched back into one image on the server. Tiles X / Tiles Y set the grid, Tile Overlap controls the seam margin — the controls are right there in the panel.
5. Render an animation
Set Output to Animation — the frame field becomes a Start / End range with a frame count readout, and a result switch appears:
- Sequence — you get the rendered frames as an image sequence.
- Video — you get one finished file. Presets cover MP4 (H.264 / H.265), WebM (VP9) and MOV (ProRes 422 HQ / ProRes 4444, which carries alpha); set the FPS right there. As the panel notes, encoding starts after all frames return.
Frames are distributed across the machines in your target scope and rendered in parallel — this is where the network shows its point: a range that would occupy your workstation for days comes back while you keep working.
6. If your scene has a simulation
A simulation — fluid, cloth, particles, rigid body, a Geometry Nodes simulation zone — can't be distributed as-is: every frame depends on the ones before it. The add-on detects simulations in your scene (you'll see them listed, e.g. Simulation: Fluid, Particles) and won't start the render until they're baked into a cache any machine can read — so a simulation never comes back as a frozen or broken result.
When one is detected, the panel asks where to bake before rendering:
- On render farm (default) — delegated baking. OmnibusCloud picks the most suitable machine among those available in your project or group and bakes the simulation there, as part of the same job. Nothing to prepare, your
.blendis left untouched, and the bake shows live per-frame progress. This is what makes a weak host viable: you can drive complex simulated scenes from a modest laptop, because neither the bake nor the render happens on it. - On this computer — local baking. The add-on bakes in your own Blender before upload (with progress and Esc to cancel), and the already-baked simulation is what goes to the server. This bakes into and saves your
.blend— you'll be asked to confirm — and the bake is reused on later renders of the same file.
Either way the distributed render is identical; the only difference is where the one-time bake runs.
7. While it renders — and after
During the render the panel folds into a compact progress view — what's rendering, where, and two live bars: Overall for the whole job and Computation for the rendering itself — with a Cancel button that stops the job cleanly. You can keep using Blender — or close it; the job runs on the network, not on your machine.
The network handles trouble for you: if a machine fails mid-job, its frames are reassigned to the remaining machines and retried — a job only fails on a real scene error. Each machine also picks its best GPU backend on its own and falls back gracefully, so one flaky GPU never sinks the render.
When it's done, the panel flips to Completed: Download result, then Open, Folder, or — for images — Load in Blender. Large results download with their own progress bar (and their own Cancel), so a multi-hundred-MB video arrives reliably even on a slow connection.
The panel remembers your working habits — target, tiling, video settings — per machine, so the next render starts where you left off. Scene facts like frame range and format always come live from Blender.
If something goes wrong
The panel heals its own connection automatically. If it can't, it tells you exactly what's wrong and what to do — Reconnect if the local bridge stopped responding, Locate / Install if it's missing. Deeper details live in the collapsed Advanced / Diagnostics section; you shouldn't need it for everyday rendering.
What's next
- Gathering the community to render your film? → Getting Started with Campaigns →
- Pooling your studio's machines? → Getting Started with Private Groups →
- Contributing your own idle power too? → Getting Started with the OmnibusCloud Client →
- Working in 3ds Max as well? → Getting Started with the 3ds Max Plugin →
Questions? Ask in r/OmnibusCloud → — we read everything.
Let's build the ultracomputer together!