Network Rendering in Houdini

HQueue, PDG/TOPs, and delegating renders to a farm

Preparation and Optimization Before a Network Render

Before launching a distributed render, get a clear picture of the project: identify precisely which sequences need rendering and their respective timings. Run local test renders on several frames, particularly the most complex ones, and tune quality settings to cut render time while preserving visual quality. Systematically log which frames were rendered and how long each took - this data becomes the basis for planning the full job.

Plan technical needs carefully: render engine, required plug-ins, and distribution strategy. With multiple machines available, decide whether specific renders should be delegated to a particular machine, or whether all machines should collectively work through the same frame range. Delegate simulations to local machines and systematically save render caches to avoid recalculating them during the final render.

Data and Network Architecture

When a project holds a lot of data (scene files, render caches, textures), be aware that network rendering distributes and sends that data to every machine assigned to the render. The fastest, most powerful machine should serve as the MASTER/distributor, while less powerful machines are configured as SLAVEs. Alternatively, store all data on a NAS and configure the Houdini or Blender project to pull resources directly from it, avoiding data duplication entirely.

Once a project is finished, tested and ready to render, always run a package/resource-collection pass to make sure every referenced file sits on a path accessible to the render nodes.

HQueue: Houdini's Render Manager

Distributed network rendering needs a render manager. While third-party solutions exist, Houdini ships its own: HQueue, built on a MASTER/SLAVE architecture. Install a Houdini Launcher on each local machine and an HQueue Client on every slave machine that will participate in rendering. The HQueue Master server coordinates task distribution, while HQueue clients on slave machines receive and execute render jobs.

Verify you actually have access to enough render nodes/licenses. Houdini typically ships with one master node and 10 base render nodes; accessing more requires an additional license purchase.

Render Nodes vs. Drivers

Before configuring network rendering, it's essential to understand the difference between Render Nodes and Drivers:

  • Render Nodes (/out) - nodes in Houdini's /out (Output) context. They define what gets rendered (the scene, objects, effects) and how (quality settings, resolution, sampling). The main Render Nodes are Mantra (PBR, Micropolygon), Karma (XPU, CPU), the Arnold ROP, the Redshift ROP, and other third-party engines.
  • Drivers - parameters inside a Render Node controlling where and when renders happen: output image paths, file format (EXR, PNG, TIFF), the frame range to render, chunked-frame rendering options, and scheduler submission settings (local, HQueue, PDG).

In short: Render Node = who/what/how, Driver = where/when.

Setting Up HQueue and the Scheduler

Installation and Configuration

  1. Download and install the HQueue server on your Master machine (sidefx.com/products/hqueue).
  2. Install HQueue clients on each Slave machine.
  3. Configure shared network paths so every machine can reach the project files.
  4. In Houdini, go to Edit > Preferences > HQueue Server and enter your server URL (typically http://[MASTER_IP]:5000).

Preparing the Scene (Essential)

  • Save the scene with backup enabled (File > Save As, with auto-save on) - absolutely essential to avoid data loss.
  • Create a camera in the /obj context, positioned per your composition.
  • Create a Render Node in /out (Mantra or Karma, depending on need).
  • Configure the Driver tab of that Render Node - output path, image format, and frame range.

Submitting to HQueue (Classic Method)

  1. In your Render Node (Mantra/Karma), go to the Driver tab.
  2. Click Render and choose "Submit Render to HQueue".
  3. The HQueue Scheduler opens, letting you set the frame range, job priority, target machines (or leave HQueue to distribute automatically), frames per task (chunking), and dependencies between jobs (e.g. simulations that must compute first).
  4. Confirm - the job is added to the HQueue queue, and progress can be monitored via the HQueue web interface (http://[MASTER_IP]:5000).

Choosing a Render Engine for Farm Jobs

Houdini's native engines: Mantra PBR for modern photoreal rendering with full PBR material support, global illumination and caustics - ideal for most current VFX projects; Mantra Micropolygon, Houdini's historic engine, excellent for extremely detailed geometry (millions of polygons), complex displacement effects, and stylized rendering, less used today but still relevant for specific workflows; and Karma, SideFX's new USD-based, modern path-tracing engine - use it for high-quality renders in USD workflows, optimized performance, and future-proof integration. Karma is Houdini's rendering future, offering competitive render times with exceptional quality.

Compatible third-party engines: Arnold (Autodesk) - the industry reference for film and VFX, used by ILM, Sony Pictures and others; a robust, reliable path tracer with excellent image quality but longer render times, ideal for high-end cinema. RenderMan (Pixar) - the historic Pixar engine, the absolute reference for animated features, optimized for complex hair, fur and subsurface scattering, used across all Pixar and Disney studios. Redshift (Maxon) - an extremely fast biased GPU engine, perfect for quick iteration and tight deadlines, an excellent quality/speed ratio, very popular in advertising and motion design, requiring a powerful NVIDIA GPU. Octane (OTOY) - an unbiased GPU engine with physically correct spectral rendering, popular for photoreal renders and archviz, with an intuitive interface and real-time viewport rendering; also requires an NVIDIA GPU. Guerilla Render - a French engine optimized for huge data volumes (dense vegetation, crowds), used notably by Mikros Image and BUF Compagnie, excellent for complex natural environments. AMD ProRender - AMD's open-source engine, compatible with any graphics card (AMD, NVIDIA, Intel), free but less performant than commercial solutions - worth it if you already have an AMD card.

Advanced: PDG/TOPs Render Scheduler

For more complex, professional workflows, Houdini 21 offers a modern approach via PDG (TOPs) and the Render Scheduler.

Starting with the Python Scheduler

  1. Create a TOP Network in the /tasks context.
  2. Add a Python Scheduler node - it lets you write Python callbacks to manage scheduling, launching and cleanup of render tasks.
  3. Configure the key callbacks: onStart (initialize scheduler state on registration), onSchedule (define work-item/chunk scheduling logic, returning True on success), onSubmitAsJob (launch the whole TOP Network as a standalone job and retrieve its status URI), and onStartCook/onStopCook (actions to run at the start/end of a cook - useful for preparing or cleaning up the execution context).

Supervision via the Render Scheduler Panel

Enable it via Windows > Render Scheduler. It lets you supervise running renders (pause/kill), toggle the display as needed, follow distributed renders and interact with queues, and monitor compute nodes and their status.

Integrating an Existing Farm

To integrate PDG with existing render-farm infrastructure, switch the default scheduler to one compatible with that solution via the Scheduler node's context menu ("Set As Default Scheduler") - aligning PDG with offline or shared-network infrastructure (RenderMan, Redshift, Arnold, HQueue, Deadline, etc.).

Practical tips: work from a shared network directory (PDG automatically converts local paths to remote ones per execution context, but a shared filesystem makes life much easier); test first with a small TOP Network and a handful of frames before launching a full farm render; use logging to help debug callbacks and job status; and clearly define dependencies (e.g. simulations that must compute before rendering, or compositing that must run after).

A complete network workflow chain: TOPs with a Python Scheduler → task queues → Render Scheduler → farm agents (HQueue clients, Deadline workers, etc.) → centralized supervision. This chain lets you test, debug and adjust the network render flow step by step.

Houdini offers several ways to launch distributed renders: directly from the interface via the Scheduler (HQueue or PDG), via command-line batch rendering, or via the Python console for full programmatic control. To save time and resources, it's worth launching distributed renders through a console or small render-management app rather than keeping Houdini's full UI open.

Slave Machine Hardware

If render PCs (slaves) don't need to run simulation calculations or make intensive GPU use (CPU-only rendering), a simple graphics card is enough - it's then better to invest in RAM and strong multicore processors instead. Watch for network or hardware bottlenecks, which will slow down even the most powerful machine. Use the slowest machine as your reference for estimating render times - faster machines then finish early as a bonus, avoiding unpleasant surprises on deadline.

It's possible to write a Python script to manage render distribution and talk to Houdini's API directly, but this is generally unnecessary for small or medium projects - it's mostly reserved for professional render farms.

External Render Farms

Renders can also be delegated to professional render farms, which often sidestep local technical headaches (bottlenecks, HQueue management, infrastructure). RanchComputing (ranchcomputing.com) is a farm with several practical advantages: European hosting (GDPR compliance), French-language support, pricing comparable to other farms, and - notably - actual Houdini integration, which many farms lack since SideFX doesn't distribute its licenses widely.

RanchComputing Workflow

  1. Run local test renders and log frame times.
  2. Download the RanchChecker plugin.
  3. Drop it into Houdini's OTLS folder and launch Houdini.
  4. Go to the TOP Nodes context.
  5. Add a RanchChecker node and collect the project's resources.
  6. Send the file to the farm.
  7. Choose a priority/cost tier and launch the render.
  8. Wait for a queue slot to open up.
  9. Once done, an email lets you download images via FTP (e.g. FileZilla), or you can ask Ranch to sync each rendered frame directly to you.
Before sending a job to Ranch, run a Cinebench R15 test to gauge local machine power, then note the average per-frame render time on your PC - RanchComputing uses that to estimate cost and time with a comparison. Always test a few frames first, even at some cost: once a farm render starts, it's billed regardless of whether the result disappoints. RanchComputing can also run simulations on a dedicated GPU farm separately from final image rendering - consider splitting simulation and final render across farm vs. local depending on your production strategy. Starting early matters: a render farm's real advantage is buying back weeks of time for critical fixes, editing, or sound design.

Blender equivalent: RanchComputing also supports Blender with a similar workflow. Blender additionally has its own network rendering system, Flamenco (flamenco.blender.org), an open-source render manager from the Blender Foundation using a manager/worker architecture equivalent to master/slave.

Other Notable Render Farms

  • RebusFarm (rebusfarm.net) - a German farm with excellent support for 3ds Max, Cinema 4D, Maya and Blender.
  • GarageFarm (garagefarm.net) - very popular, competitive pricing, good Houdini and Blender support.
  • Fox Render Farm (foxrenderfarm.com) - based in China, very attractive pricing, 24/7 support.
  • Conductor (conductortech.com) - a premium cloud solution used by major studios.
  • AWS Thinkbox Deadline - AWS's cloud solution, maximum scalability.
  • Google Zync (zyncrender.com) - Google's cloud platform, GCP integration.

Resources

← Related: TOPs and PDG: Distributed Computing Back to Articles →