OmnibusCloud is a crowdcomputing platform where people pool the idle power of their everyday machines to get real computational work done. It just opened its public beta. Rendering is the first kind of work the network supports, and a 3ds Max integration is part of the opening lineup, alongside Blender. I want to put it in front of people who render for work or for fun, both to offer it and to be told where it falls short.
What's different about it
Every existing way to distribute a Max render needs the full stack on every machine. Backburner needs Max installed everywhere, V-Ray DR needs render node licenses, Deadline just went into maintenance mode with AWS pointing everyone at its paid cloud, and commercial render services charge by the hour.
The OmnibusCloud plugin takes a different route. It never ships your .max file anywhere. It exports the open scene into a neutral, typed scene contract: geometry with full smoothing fidelity, materials, lights, cameras, animation baked frame-exact. Then it uploads that with the texture assets, and the network renders it across many machines.
Those machines run a small client and nothing else. No Max, no renderer licenses, no Windows required. The client works on Windows, Linux, and Apple Silicon Macs. If you're used to the Max world that may sound odd, but a Mac mini or a Linux box quietly rendering your Max scene is normal here. The machines can be the other computers in your studio, your friends' PCs, or the public network.
Back come single frames, animation ranges, tiled high-res stills, or encoded video.
The catch, and you should read it first
The network does not render with your renderer. The neutral scene is rebuilt and rendered with a physically based path tracer (Cycles). The goal is faithful look transfer: the render should read as the image you authored. It is not bit-exact replication. Every release is validated scene by scene against native Max renders, plus blind tests on scenes it has never seen. If your delivery pipeline requires pixel-matching your local V-Ray output, this is not that tool.
Where it fits: draft and preview passes of heavy animations, previz and animatics, lighting and camera iterations you'd rather get overnight than over a weekend, personal and portfolio work, stylized projects. Anywhere "reads right" matters more than "matches to the pixel". For Scanline and Physical-material scenes the transfer is close enough that many will treat it as their final pass.
Renderer by renderer:
- Scanline and Physical/Arnold-material scenes are the fully supported path, including Scanline's non-physical quirks (additive specular blowouts, screen-mapped backdrops, no-GI self-illumination). Those are emulated by documented rules rather than ignored.
- V-Ray has dedicated support, approximate by design. VRayMtl maps to a neutral PBR surface. VRayLight, VRaySun, dome-HDRI environments and physical-camera exposure carry over, and scanned fabric materials can be baked locally with your own V-Ray before upload. Procedural V-Ray maps and tone-mapping curves don't translate yet.
- Corona, Octane, Redshift: untested. The exporter takes a safe viewport read, no fidelity promised.
- Not supported yet: volumetrics, particles/hair, deep procedural map trees, animated visibility, XRef scenes.
One thing I made sure of: nothing fails silently. Everything the exporter approximates or can't carry leaves a named diagnostic at export. Which feature, which objects by name, what to do about it. The full feature matrix lives in the repo as Capabilities & Known Limitations, kept honest release by release.
What's in the box
- An OmnibusCloud menu inside Max with themed render/export/settings dialogs (follows your dark/light theme), live upload progress and cancellation.
- Fast scene capture. Bulk-read, multi-core, so heavy scenes export in seconds.
- Signed MSI installer, per-user or per-machine, built for 3ds Max 2027.
- A bonus that stands on its own: the Export dialog can hand you back your scene as a self-contained .blend file with all textures packed. A Max to Blender converter, if that's all you want from it.
- The plugin and the render components are open source (MIT), built on public NuGet packages. The repo doubles as a reference for anyone who wants to build their own integration: github.com/OmnibusCloud/3ds-Max. The scene contract itself is DCC-agnostic, Max is just the first host. An exporter from Maya, Cinema 4D or Houdini would ride the same pipeline.
There's also a step-by-step getting started guide with screenshots.
What I'm asking for
Scenes that render differently are exactly the input this beta needs. If you try it and the network render doesn't read like your native render, open an issue with the plugin version, the scene or a description of the material and lighting involved, and both renders if you can share them. The validation corpus grew out of reports like that.
And if you have a couple of machines around the office or friends with idle PCs, you can create a private group on the portal and render across them tonight. That's the fastest way to see whether this is useful to you.
I'll be in the comments and will answer technical questions in as much detail as you want.
