Integrating Houdini rendering into an automated workflow generally involves one or both of the following command line programs.

• The hython and hbatch command line programs lets you run Houdini Python or HScript (respectively) scripts from the command line, allowing you to do almost everything you can do through the Houdini user interface on the command line, including generating IFD files from render nodes.

• The mantra renderer program takes IFD files (mantra’s scene description format) and uses them to render images.

The main difference between the two approaches is that hbatch uses a Houdini license while mantra only uses a render license. A common general workflow is to use a single host to generate IFD files for the frames of an animation (using a single full license), and then farm out the rendering to mantra instances (using multiple cheaper render licenses).

• You can use the Pre Post render node with the Shell render node to run scripts to load geometry files from a server before rendering, and save rendered images to a server after rendering.

• As with many other network types, it’s a good idea to keep a Null render node with a noticeable, descriptive name (for example FINAL_OUTPUT) at the end of a render network, so that even as you insert and remove nodes from the network, you can always refer to the final node consistently.

• You can set a render node to render using a specific take. This is an easy way to set up render passes.

You can connect render nodes together to create dependency graphs, allowing you to control the order in which renders run. You can connect any number of inputs and outputs.

When rendering a node, Houdini will render all input nodes first.

When called from the command line, by default Mantra will render all frames in the input nodes before rendering any frames of the rendering node. That is, if Node B depends on Node A, all frames of Node A are rendered before any frames of Node B (A₁, A₂, …, A_n, B₁, B₂, …, B_n).

Houdini generally ignores the Frame range parameter on an input node when rendering dependencies unless the child node’s Valid Frame Range parameter is “Render Frame Range Only (Strict)”. In that case, Houdini will only output frames within the input node’s frame range.

For example:

composite is dependent on char_diffuse, char_specular and backgound. char_diffuse and char_specular are both dependent on character. If composite is rendered, the order of the render process would be:

1. All frames of character

2. All frames of char_diffuse

3. All frames of char_specular

4. All frames of background

5. All frames of composite

• Houdini will not allow you to create a circular dependency.

• All input render nodes to a subnetwork will render before the nodes inside the subnet.

• The subnetwork will render all its “final” nodes (render nodes without output connections) at the same frame or frame range.

• If a subnet has more than one “final” node, the order in which they render is arbitrary (it’s the order the nodes were created in). To enforce an ordering, use a Merge render nodes to merge the final render nodes together and order its inputs .

• Render node SubNetworks have no direct connections between the child render nodes and the input render nodes to the SubNetwork. Thus, using a Switch or Batch render nodes with no inputs in a SubNetwork will not have them affect the inputs to the SubNetwork.

A number of render nodes manage dependencies, and do not render anything themselves.

• Pre post allows optional “pre-render” and “post-render” branches to run before/after a “main” branch.

• Batch causes the frames in the input to be rendered in sequential order, in one pass, regardless of the order in which frames are requested.

• Frame Dependency - Makes a frame depend on other frame times.

• Merge merges all dependencies together, to make networks easier to read.

• Switch selects one input (or no inputs) to add a dependency on.

• Alembic “renders” the scene to an Alembic file.

• Mantra Archive “renders” the scene to a geometry format optimized for loading by the renderer (using a procedural shader).

• Geometry “renders” part of the Houdini scene to a geometry file.

• Shell runs a script or command.

Two different ways to show/hide different objects for different render passes:

• Set up the visibility and settings for each render pass in a separate take, then set a render node to render using that take.

• Create a bundle or wildcard pattern specifying the objects that should be visible in the pass. Use the Objects tab on the mantra node to specify which objects the render node should render. Note that Houdini wildcards can exclude names as well as include them.

IFD is the scene description format produced by Houdini and consumed by mantra to produce a rendered image or animation sequence. The IFD file contains a complete description of the scene and how to render it.

RIB is the equivalent of IFD for RenderMan and RenderMan-compatible renderers.

You can set up a render output node to save a file instead of rendering an image directly. This gives you the flexibility of rendering at another time, from another machine, or on a render farm. See network rendering.

mantra -f <<filename>>.ifd <<output_filename>>.pic

Once you have an IFD file you can use mantra to render it on the command line, for example:

mantra -f frame0001.ifd rendered_frame0001.pic

(If you don’t specify the -f option, mantra will read the IFD from stdin.)

mantra -h will print a summary of the available options.

Most command-line options are overrides for properties. This means you can set these properties on the scene camera, and then override them on the command line if necessary.

• Running hython gives you a Python command-line environment with the houdini object model package (hou) available.

  % hython myscene.hip
  Python ...
  Houdini ... hou module imported.
  Type "help", "copyright", "credits" or "license" for more information.
  >>> rnode = hou.node("/out/mantra1")
  >>> help(rnode)
  >>> rnode.render()
  

• Running hbatch gives you an HScript command-line environment. This lets you script almost any action you can perform

  % hbatch myscene.hip
  hbatch Version ... (Compiled on ...)
  / -> cd out
  /out -> help render
  /out -> render mantra1
  

  hbatch -h will print a summary of the available options.

Mantra is a multithreaded process, which means that a single mantra render will split work between available processors to speed up rendering. By default, mantra detects the number of processors installed in the system and will start enough threads to use all of the processors.

You can turn off multithreaded rendering by unchecking the Use Max Processors checkbox on the Rendering sub-tab of the Properties tab on the mantra render node. You can also manually set the number of threads to use for rendering by setting the Thread Count.

Mantra has a simple method for distributing rendering to multiple machines on the local network. This may be useful for ad-hoc speedups when rendering a single image. For more robust and full-featured network rendering, use a render queue manager such as HQueue or Alfred.

The -H option lets you specify hostnames to render on. You can use this to render an IFD file on the command line, or in the Command parameter on the Main tab of the mantra output driver.

For example:

mantra -H localhost,clinton,beijing,finland

This command line will start up mantra on 4 servers named localhost, clinton, beijing, and finland. The machines will render tiles and send them back to the host machine to be assembled into the final image.

• This only works for rendering a single image.

• All machines must be running the same version of Houdini license software (hserver). If one of the machines you specify is running a different version of hserver, or not running hserver at all, the render will hang.

  You can check the version of hserver that is running on a machine by running the command hserver -l.

  % hserver -l
  Hostname:       clinton [Linux (little endian)]
  Uptime:         21:29:16        [Started: Wed Aug 15 18:11:48 2007]
  License Server: internal
  Server Version: sesinetd9.0.634
  Version:        Houdini9.0.688
  ...
  

  The major and minor numbers of the Version: value (in this example, 9.0) must match on all machines.

HQueue is a general-purpose job management system that distributes, monitors and manages tasks across a collection of servers. It specializes in managing render and dynamic simulation jobs submitted from Houdini however it can be customized to work with any job from any application.

See the online HQueue documentation for information on how to install and use HQueue.