Mantra render node

Renders the scene using Houdini’s standard mantra renderer and generates IFD files.

All

Parameters

Example files

Overview

The mantra output driver node uses mantra (Houdini’s built-in renderer) to render your scene. You can create a new mantra node by choosing Render > Create render node > Mantra from the main menus. You can edit an existing render node with Render > Edit render node > node name. To see the actual network of render driver nodes, click the path at the top of a network editor pane and choose Other networks > out.

You can add and remove properties from the output driver just like you can for objects. If you add object properties to the render driver, they define defaults for all objects in the scene. Select a render node, and in the parameter editor click the Gear menu and choose _Edit rendering parameters to edit the properties on the node. For more information on properties, see properties. For more information on adding properties to a node see the Edit Parameter Interface.

For complex scenes involving multiple render passes, separate lighting and shadow passes, and so on, you can set up dependency relationships between render drivers by connecting driver nodes together. See render dependencies.

Important parameters

Some important parameters on the render driver include:

The camera to render from (Main tab, Camera).
The image to render to. (Properties tab, Output sub-tab, Output picture).

Use ip instead of a filename to render directly into the mplay image viewer (this is the default). This will not save the image to disk, but you can save manually from mplay.
The frame range to render for an animation (Valid frame range and Start/end/inc).
Turn on motion blur for all objects (Properties tab, Sampling sub-tab, Allow motion blur).
Adjust render quality (Properties tab, Sampling sub-tab). The Pixel samples and ray sample controls are good places to start. See the documentation for these options below.

Parameters

Render

Begins the render with the last render control settings..

Render Control

Opens the render control dialog to allow adjustments of the render parameters before rendering.

Valid Frame Range

Controls whether this render node outputs the current frame (Render any frame) or the image sequence specified in the Start/End/Inc parameters (Render Frame Range).

Render Frame Range (strict) will render frames START to END when it is rendered, but will not allow frames outside this range to be rendered at all. Render Frame Range will allow outside frames to be rendered. This is used in conjunction with render dependencies. It also affects the behaviour of the 'Override Frame Range' in the Render Control dialog.

Two possible cases where you'd want the strict behavior:

A 60 frame walk cycle written out to a geo, but part of a larger ROP net to render out a larger frame range
A texture loop from 1-20

Otherwise, you will usually set this to non-strict.

Render Any Frame	Renders a single frame, based on the value in the playbar or the frame that is requested by a connected output render node.
Render Frame Range	Renders a sequence of frames. If an output render node is connected, this range is generally ignored in favor of frames requested by the output render node.
Render Frame Range (Strict)	Renders a sequence of frames. If an output render node is connected, this range restricts its requested frames to this frame range.

Start/End/Inc

Specifies the range of frames to render (start frame, end frame, and increment). All values may be floating point values. The range is inclusive.

These parameters determine the values of the local variables for the output driver.

$NRENDER	The number of frames to be rendered by the output driver.
$N	The current frame being rendered (starting at 1 and going to $NRENDER).

For example, if the parameters are set to:

Start	End	Inc
10.5	12	0.5

There will be 4 frames rendered (10.5, 11, 11.5, and 12), so $NRENDER will have a value of 4. $N will have the value:

Frame	10.5	11	11.5	12
$N	1	2	3	4

Render With Take

The output driver will switch to this take before rendering to restore the current take when rendering has been completed.

Main

The output driver is responsible for generating IFD files. These files describe the Houdini scene to mantra. The Main tab determines how the IFD generation is processed.

Render Target	Choosing a target version of mantra allows you to generate an IFD targeted to a specific build of mantra.
Camera	The camera object which defines the scene.
Disk File	The location where the IFD file is saved to disk. You must turn on the Disk File checkbox to enable this parameter.
Command	The command (i.e. mantra) where the IFD file is sent. This will be disabled if the IFD file is saved to disk.
Block Until Render Completes	When sending the output to a command, Houdini will normally return control after it is finished writing the IFD. This allows the render process to complete in the background. Turning on this parameter will force Houdini to block until the mantra finishes rendering the frame. When rendering a frame range, this option is automatically turned on. However, the option is not automatically turned on when rendering in an hscript or python loop construct. Therefore caution must be used or it is possible to end up starting multiple background renders. Note The rps and rkill hscript commands can be used to query or kill background renders. See the Troubleshooting section for more information.
Initiate Simulation OPs	If this option is turned on, POP and DOP simulations will be initialized before rendering.

Objects

The parameters on this tab determine which objects and lights are included in the IFD.

The order of processing these parameters is as follows:

Candidate objects/lights are selected.
Forced objects/lights are added.
Objects/Lights matching the exclusion parameter are removed.

Candidate Objects	The geometry objects in this parameter will be included in the IFD if their display flags are turned on and their display channel is enabled.
Force Objects	Objects in this parameter are added to the IFD regardless of the state of their display. Objects can only be added to the IFD once.
Exclude Objects	Objects in this parameter are excluded from the scene, regardless of whether they are selected in the Candidate Objects or Force Objects.
Solo Light	Only lights in this parameter will be included in the IFD. This includes shadow map generation and illumination. If this parameter is set, the candidate, forced, and exclusion parameters are ignored. Note Using this parameter in conjunction with the render_viewcamera property provides a quick way of generating shadow maps for selected lights.
Candidate Lights	Each light in this parameter is added to the IFD if the dimmer channel of the light is not 0. The standard light sets the dimmer channel to 0 when the light is not enabled.
Force Lights	The lights in this parameter are added to the IFD regardless of the value in their dimmer channels.
Exclude Lights	These lights will be excluded from the scene, even if they are selected in Candidate Lights or Force Lights__.
Visible Fog	The fog/atmosphere objects in this parameter are included in the IFD if their display flags are turned on and their display channel is enabled.

Properties

You can add any rendering property to the mantra output driver. Properties change the behavior of how mantra will interpret the scene. You can add any property, even if it might not make sense to add to an output driver. For example, you can add a surface shader even though the output driver does not have any surfaces. These values will be used as default values for objects which do not have these properties defined. However, if an object has a property defined, the value assigned to the object will be used instead of the value assigned on the output driver.

Output

Output Picture

The image or device where the resulting image will be rendered. You can set this value to ip which renders the image in MPlay, or you can save it to an image. The following image types are supported: .pic, .tif, .sgi, .pic.gz, .rat, .jpg, .cin, .rta, .bmp, .tga, .rad, .exr, and .png.

Include $F in the file name to insert the frame number. This is necessary when rendering animation. See expressions in file names for more information.

Output Device

The image format or device for the output image.

Pixel Filter

Specifies the pixel filter used to combine sub-pixel samples to generate the value for the single pixel.

Quantization

The storage type for the primary plane image.

White Point

The white-point of the image used during quantization.

Override Camera Resolution

Normally, the resolution channels on the camera determine the output resolution. Enabling this parameter allows an alternate resolution to be used.

Resolution Scale

A specific resolution can be specified using this parameter, or alternatively, a fraction of the camera’s resolution.

Resolution

Allows you to override the camera resolution.

Pixel Aspect Ratio

The pixel aspect ratio represents the width of a pixel divided by the height of a pixel. It is not the aspect ratio of the image (which is determined by the resolution of the image).

Extra Image Planes

Any number of extra image planes may be generated simultaneously. If the primary output image format supports multiple image planes, the plane name will be used to define the name of the deep raster plane. If the primary output device does not support multiple image planes, each image plane will be output to an individual file, with the name of the plane defining the file name. The formats that support multiple image planes are OpenEXR and Houdini .pic (including the “ip” device).

Image Plane

The name of the plane.

VEX Variable

The VEX variable to be output to the image plane. The variable must be either a global variable, or an exported parameter.

Note

When the N variable is output, its value may not be normalized resulting in either very small or very large values.

VEX Type

The correct type of the variable must also be specified.

Channel name

Name of the channel to write the variable data to in the output file (if the file format supports multiple named channels). Leave this field blank to use the VEX variable name as the channel name.

Different file

Turn on the checkbox next to this field to write the variable data to an output file other than the rendered image.

Note

You can specify the same “Different file” for multiple extra image planes with different channel names (if the file format supports multiple named channels).

Quantize

The storage type for the output.

Sample Filter

Opacity Filtering	Transparent surfaces will be composited using Of.
Closest Surface	Only the value of the closest surface will be output, regardless of the opacity of the surface.

Pixel Filter

Specifies the pixel filter used to combine sub-pixel samples to generate the value for the single pixel.

Gamma

Specifies the gamma correction for the image.

Gain

Each color value is multiplied by the gain prior to being quantized.

Dither

The dither amount to be applied. The dither is specified as a fraction of the quantization step (i.e. 0.5 will be one half of a quantization step). The option is ignored for floating point output.

White point

The white-point of the image used during quantization.

Light Export

Mantra supports export of variables from within illuminance loops. If the light export field is set to the name of a light object (as it appears in the IFD), and the shader is written to assign the value of the export parameter inside an illuminance loop, then the image plane will contain the value of the export parameter at the time the illuminance loop was run for the given light source. It allows the contribution of individual lights to be output into separate image planes for easy adjustment in post-compositing.

Tip

You can output the object ID and/or primitive IDs to deep raster planes, and then use them to easily select objects or primitives in the compositor.

To output the object or primitive ID, set up the following parameters:

Variable name = Op_Id (or Prim_Id)
File/Plane name = Op_Id (or Prim_Id)
Channel depth, Variable type = Floating point
Sample filter = closest surface
Pixel filter = minmax idcover (a special filtering mode for ID channels)

Sampling

Enable Depth Of Field	Mantra will render with depth of field. The parameters controlling depth of field may be found on the camera object.
Allow Motion Blur	Mantra will render the image using motion blur. The shutter parameter on the camera determines the duration of the shutter, specified as a fraction of the frame.
Motion Factor	This parameter automatically adjusts the shading quality for objects which are significantly blurred. When an object is blurred heavily, whether due to depth of field or motion blur, increasing the motion factor will automatically decrease the shading quality.
Xform Time Samples	The number of transformation blur motion samples. Each object (unless the parameter exists on the object) will have this many transforms output over the shutter duration. Increasing this number will result in smoother sub-frame motion, at a small memory and compute expense. Any number of segments may be specified.
Geo Time Samples	The number of deformation blur motion samples. Each object (unless the parameter exists on the object) will have this many copies of the geometry included in the IFD. When an object is deforming, increasing this parameter will result in smoother sub-frame motion blur. Setting this value to 2 or greater will enable Deformation Motion Blur for the given rendered objects. This option has no effect objects, which use velocity blur, since velocity blur is linear by nature. Note Any number of segments may be specified; however, duplicate geometry is sent down for each sample which may significantly impact the memory footprint of mantra.
Motion Blur Style	The type of motion blur. You can choose either a trailing, centered, or leading blur.
Pixel Samples	The number of samples which are filtered to compute the color for each pixel. Increasing the samples will improve motion blur and depth of field quality. When using the ray-tracing engines, each ray is shaded independently. Very large values for pixel samples in this case may significantly increase rendering time.
Variance Antialiasing	When the micro-polygon rendering engine is used, each vertex of each micro-polygon is shaded one time. When ray-tracing is invoked in shading, mantra is able to automatically anti-alias the ray-tracing by oversampling. When variance anti-aliasing is used, there will be at least the minimum rays sent for each shade and at most the maximum number of rays. Mantra uses variance analysis on the shading results to determine the actual number of rays. If variance anti-aliasing is disabled, the minimum number of rays will be sent for each shading sample. When primary ray-tracing engines are used, these parameters are ignored and anti-aliasing is done using the pixel samples.
Min Ray Samples	The minimum number of ray-tracing samples used in variance anti-aliasing.
Max Ray Samples	The maximum number of ray-tracing samples used when variance anti-aliasing.
Volume Step Size	This is the default volume step size form the integration through the volume when rendering volume primitives. This can be overridden on a per-object or per-primitive basis.
Decouple Shadow Step Size	The visible volume step size is usually used when computing shadow occlusion of volume primitives.
Shadow Step Size	Use this step size instead of the Volume Step Size property when computing shadows. In some cases, increasing the step size when computing shadow rays makes shadowing more efficient.

Render

Rendering Engine

See rendering engines for more information.

Micropolygon Rendering	Each primitive is diced up into micropolygons which are shaded and sampled independently.
Ray Tracing	The scene is sampled by sending rays from the camera.
Micropolygon Physically Based Rendering	Sampling is performed on micropolygons; however, all shading and illumination is performed using physically based rendering. The number of rays used to compute shading is determined by the maximum ray-samples.
Physically Based Rendering	Sampling of the scene is performed using ray-tracing and shading is computed using physically based rendering. In this case, the pixel samples determine the shading quality of the PBR engine.
Photon Map Generation	Rather than rendering an image, a photon map will be generated by sending photons from light sources into the scene.
View Dependent Photon Map	A photon map will be generated. However, the photons will be distributed by sending photons from the camera into the scene rather than from the light sources. View-dependent photon maps will usually produce better quality for global illumination but need to be regenerated for every change in view. Note Caustic photon maps cannot be generated using view-dependent photon map generation.

Tile Size

The size (in pixels) of the tiles rendered by mantra. Larger tile sizes may consume more memory.

Opacity Limit

Mantra will assume that surfaces become opaque when processing many layers of transparent surfaces, rendering with volume primitives, or when the cumulative opacity exceeds this limit.

Use Max Processors

Set the thread count to the number of CPUs of the rendering machine.

Thread Count

The number of threads used for rendering.

Create Image From Viewing Camera

Renders an image from the viewing camera. Sometimes, it is useful to skip this render, for example, when rendering shadow maps.

Auto-Generate Shadow Maps

Enable or disable shadow map generation. Each light also has its own controls to determine whether shadow maps will be generated.

Auto-Generate Environment Maps

Enable or disable environment map generation. Each object can be set up to generate an environment map of all the other objects in the scene.

Force VEX Shader Embedding

Mantra is able to load the shader directly from the OTL when Houdini uses a shader defined in an OTL. When shaders are built using VOPs, the shader must be embedded in the IFD. Enabling this option will force Houdini to embed the shaders defined by OTLs.

This option makes the IFD more self-contained so that machines which don’t have the OTL installed (or a different version of the OTL) are able to evaluate the shaders correctly.

However, if you have complicated shaders, embedding them will bloat the size of the IFD significantly.

Irradiance

Enable Irradiance Cache	This option enables the irradiance cache, which can significantly improve the performance of the irradiance and occlusion VEX function calls. It has no effect on area lights.
Irradiance Error	The maximum error tolerance between samples in the irradiance map.
Max Spacing (Pixels)	The maximum screen space between irradiance samples. Lowering this value will force more samples to be computed, creating a more accurate representation of the irradiance information.
Min Spacing (Pixels)	In some cases, you can get a very dense clustering of irradiance samples in the cache. This parameter prevents the clustering by ensuring that there are at least this many pixels between samples. Clustering usually occurs between non-smooth intersections between different primitives.

Geometry

Save Binary Geometry

Saves binary geometry in the IFD. If this option is turned off, ASCII geometry is saved in the IFD. Binary is much more efficient. ASCII is readable.

Statistics

Verbose Level

Increasing this value will cause more information to be printed out during rendering.

VEX Profiling

No VEX Profiling	No VEX Profiling is performed.
Execution Profiling	Mantra will print out information about shading computations at the conclusion of the render. This helps in identifying bottlenecks in the shading process.
Profiling and NAN detection	Prints out the shading information and will not print instructions that generate bad values (Not A Number). The output is cryptic, but can help track down errors in shaders.

Alfred Style Progress

A percentage complete value is printed out as tiles are finished. This is in the style expected by Pixar’s Alfred render queue.

The following is an example of timing information and how to read it.

Render Time: 389.000u 1.062s Memory: 72.13 MB of 74.25 MB arena size

The u value is the actual time in seconds mantra took to render the image.
The s value is the system overhead incurred in rendering the frame (disk io, swap, etc.).

Note

This value might not be 100% accurate depending on the OS and other system variables.
Arena size is the amount of memory mantra allocated to actually render the image. It does not reflect how much memory mantra actually used.

Mantra needs to grab continuous chunks of memory as it builds the data structures. Once it frees up the data, the operating system controls the arena size shrinking it where it finds continuous chunks of memory back to the free pool of available memory. This is called memory allocation and memory deallocation. You don’t want the arena size much larger than the actual memory used.

PBR

Reflect Limit	Limit the number of specular bounces for physically based rendering. Increasing this limit will produce more accurate rendering of scenes that have many inter reflections (such as scenes containing glass or fluids).
Glossy Limit	Limit the number of glossy bounces. Glossy (blurry) reflections can sometimes introduce a considerable amount of noise in the image, so limiting the number of glossy bounces can decrease noise while rendering a little less accurately.
Diffuse Limit	Limit the number of diffuse bounces. Diffuse bounces usually contribute to the majority of global illumination in a scene, so increasing the diffuse limit will produce more accurate global illumination.
Primary GI Cache File	Set the cache type to use for rendering primary (first bounce) global illumination. The primary cache file is used to look up diffuse global illumination on the first surface hit, making it possible to quickly visualize the contents of a global illumination cache file. Usually, rendering a photon map as a primary GI cache will produce overly blurry results, so this option is mostly useful for testing. When a primary GI cache is used, no diffuse bounces will be traced.
Secondary GI Cache File	Set the cache type to use for rendering secondary (second bounce) global illumination. The secondary cache file is used to look up diffuse global illumination indirectly to produce higher quality renders. This technique is similar to the “final gather” approach available in other renderers. When a secondary GI cache is used, only one diffuse bounce will be traced. Any additional global illumination will be taken from the cache file.
Caustic Cache File	Set the caustic cache file type. When the caustic cache file is set to “Photon Map”, caustics lighting will be included at all shading positions.
Cache Stores Direct Lighting	For cache file generation, disabling this option will prevent direct lighting to be stored in the cache. The default is to include all direct lighting in the cache file. Previous photon map generation algorithms in mantra excluded direct lighting from the cache file, so it is possible to achieve similar results by disabling this option.
Photon Storage Count	The number of photons to store in the photon map files. If both a global and caustic photon map file are used, this will be the total count of global and caustic photons. So, if you want to generate a high quality caustic photon map, you should disable global photon map generation.
View Photon Supersamples	The number of antialiasing samples to take for view photon map generation. Supersamples can improve the quality of a view-dependent photon map without increasing the number of photons to store.
Global Photon File	Filename for global illumination photon map generation.
Global Prefiltering	Turn on checkbox to enable prefiltering of global photon map files. Normally, global photon maps should be prefiltered to speed up renders that use the photon map.
Global Count	Number of photons to filter when rendering using a global photon map. Larger values will produce blurrier results.
Global Radius	Maximum search radius for photons. For large scenes, you should increase this value for more accurate photon map renders.
Global Accept Ratio	Proportion of photons to store to file when rendering a global photon map. Using fractional values, for example 0.5, will speed up photon prefiltering but decrease the quality of the photon map file.
Caustic Photon File	Filename for caustic photon map generation.
Caustic Prefiltering	Toggle to enable prefiltering of caustic photon map files. Normally, caustic photon maps should not be prefiltered, as caustics require higher quality filtering than global illumination.
Caustic Count	Number of photons to filter when rendering using a caustic photon map. Larger values will produce blurrier results.
Caustic Radius	Maximum search radius for photons. For large scenes, you should increase this value for more accurate photon map renders.
Caustic Accept Ratio	Proportion of photons to store to file when rendering a caustic photon map.
Photon Target Category	Category to use as a photon target for distant lights. Distant lights cannot generate photon maps without an accurate photon target, as mantra has no way to know where photons should be sent.

Scripts

Each script command refers to an hscript command which will be run, regardless of the expression language selected for the parameter. The resulting string will be run as an hscript command.

Note

It is possible to use the python, unix or source hscript commands to perform complex processing.

The commands are always run when rendering occurs. The command checks the parameters of the output driver when it is rendering a range or sending output to a command.

Before the render occurs, Houdini will automatically set the current hscript directory to point to the output driver.

Pre-Render Script	This command is run before any IFDs are generated. It is only run once per render.
Pre-Frame Script	This command is run before each IFD is generated.
Post-Frame Script	This command is run after each IFD is generated. Note Although the IFD may have been generated, this does not necessarily mean that mantra has finished rendering the image when this command is run.
Post-Render Script	This command is run one time, after all IFDs have been generated. Note Although the IFD may have been generated, this does not necessarily mean that mantra has finished rendering the image when this command is run.

Mantra Attributes

The following attributes on geometry control how mantra renders the geometry.

orient	Orientation of curve/point primitives. Curves and points will be oriented so that their normals point in the direction of the “orient” vector attribute.
v	(velocity) Used for velocity motion blur computations
uv	Default attribute for the `-u` command-line option
vm_photon, vm_surface, vm_displace, shop_vm_photon, shop_vm_surface, shop_vm_displace	Shader overrides (per primitive).
width, pscale	Controls width of curve/point primitives (see below).
scale	Not used by mantra

Note

When mantra decides the size of point primitives, it looks for the following attributes in order:

Point attribute width
Point attribute pscale
Detail attribute width
Detail attribute pscale

To decide the width of curve primitives, mantra looks for the following attributes in order:

Vertex attribute width
Point attribute width
Primitive attribute width
Detail attribute width
Point attribute pscale

The first attribute mantra finds controls the size/width of the point/curve.

Technical Tips for Advanced Users

The default set of properties for the output driver can be found in $HH/soho/parameters/IFDmantra*.ds.

You can define your own set of properties without modifying this file. Look for the #sinclude line and the parameter definition for default_output. These parameters are added in the creation script for the output driver.

Some properties on the camera will be overridden from the view port menu or the render state. Please see $HH/soho/overrides. You can see by inspecting these files, when rendering from the view port menu, the output image is always set to ip and the output will always be sent to a command (not to a disk file).

Troubleshooting

When rendering multiple images in a single IFD, such as shadow maps, reflection maps, or photon maps, mantra could complete the first image before processing the remainder of the IFD. If this happens, Houdini will be blocked from writing the IFD commands for the main image, regardless of the state of this parameter.

There are two things you can do:

Create a wrapper script around mantra which spools the IFD to a temporary disk file. After the IFD has been spooled, mantra may be invoked. Since Houdini has completed writing the IFD, it will not be blocked. The downside of this is that the wrapper script reads the IFD, writes it to disk, then mantra reads it to render. In some cases, this can be significant additional processing.
Split the multiple images into separate output drivers connected in a network (or sub-net).

Example files

Ambient_Occlusion

$HFS/houdini/help/examples/nodes/out/ifd/amb_occ_scene.otl

Load | Launch

Ambient Occlusion

Ambient occlusion is a fast technique for producing soft, diffuse lighting in open spaces by using ray tracing. It is computed by determining how much of the hemisphere above a point is blocked by other surfaces in the scene, and producing a darker lighting value when the point is heavily occluded. This technique can be useful when you need a GI-like effect without paying the price for full global illumination.

With this particular example, an Ambient Occlusion light and some geometry is provided in the form of a Digital Asset. A Light Template was used with a GI_light shader assigned to it, and it’s parameters were promoted for easy access. #image ao.jpg goes right here

Optimizing performance/quality for ambient occlusion

There are two ways to adjust the quality and performance of renders using ambient occlusion.

adjusting the number of samples
using irradiance caching.

Decreasing the sample count allows you to improve render time at the expense of some additional noise in the render. The following render uses the same shader as the image above but decreases the samples from the default of 256 to 16. This value is set on the Sampling Quality under the Occlusion tab of the asset. #image ao_lowsample.jpg goes right here

Irradiance caching is a technique that allows ambient occlusion values to be shared across a surface to improve performance. To enable irradiance caching, turn on the Enable Irradiance Cache option on the Irradiance tab of a mantra ROP. #image icache1.jpg goes right here

When using irradiance caching, it is possible for artifacts to appear near sharp edges in the scene. For example, on the rim of the teapot lid there are some pixels that are brighter than they should be. To resolve these artifacts, decrease the Max Pixel Spacing parameter on the Irradiance tab. The following image was rendered with a spacing of 3. #image icache1.jpg goes right here

Environment Maps

If you have a smooth environment map, it is possible to replace the global background color (white) with the value from an environment map. To do this, change the Environment Map parameter under Occlusion tab. #image ao_envmap.jpg goes right here

Volume_Meta

$HFS/houdini/help/examples/nodes/out/ifd/meta_volume_smoke.otl

Load | Launch

Volume Rendering - Metaballs as Volume

Metaball geometry can now be natively rendered as a volume in mantra. Metaball rendering can be enabled by checking the Metaballs as Volume parameter on the Geometry tab of a geometry object. Any point attributes on the metaballs will be interpolated to the shading position in the same manner that point attributes are interpolated for metaball surfaces.

Here is an example using randomized point color attributes:

Controlling Shadow Quality/Performance

Shadow map generation uses the Pixel Samples and Shadow Step Size parameters (in the Mantra Render Operator) to control quality and performance in exactly the same way they are used for surfaces. Since volumes often cast soft, diffuse shadows, it is often possible to use low-resolution deep shadow maps when rendering volumes, leading to much faster render times. Shadow map Resolution can be changed on the Shadow tab of a Houdini light.

Volume_Smoke

$HFS/houdini/help/examples/nodes/out/ifd/volume_smoke.otl

Load | Launch

Volume Rendering - File Referenced Smoke

Volume rendering is a new rendering approach in mantra 9.0 that allows high-quality, integrated rendering of volumetric effects like smoke, clouds, spray, and fire.

Volume rendering is suitable for rendering many types of volumetric effects. Scenes that are particularly suited to rendering with mantra volumes include:

Detailed “hero” clouds, smoke, or fire
Fields of instanced clouds, smoke, or fire

Scenes where volume rendering may not be quite so applicable include:

Scenes with a single uniform fog

In this particular example, a bgeo file (1 frame only) was exported from a fluid simulation of smoke and is now referenced using the File SOP. A material using VEX Volume Cloud is assigned to this volumetric data at the top level of the Volume Object. To see this scene in shaded mode, ensure that HOUDINI_OGL_ENABLE_SHADERS is set to 1 in the environment variables.

Controling Quality/Performance

Volume rendering uses ray marching to step through volumes. Ray marching generates shading points in the volume by uniformly stepping along rays for each pixel in the image. There are two ways to change the quality and speed of the volume ray marching:

The samples parameter on the Sampling tab of the mantra ROP. More pixel samples will produce more ray marches within that pixel leading to higher quality. Using more pixel samples will also improve antialiasing and motion blur quality for the volume.
The volumestepsize parameter on the Sampling tab of the mantra ROP. A smaller volume step size will produce more samples in the volume interior, improving quality and decreasing performance. A separate shadowstepsize can be used for shadows to separately adjust the quality of shadows.

Which parameter you should change will depend on your quality requirements for pixel antialiasing. In general, it is better to decrease the volume step size rather than increase the pixel samples because a smaller volume step size will lead to more accurate renders.

This render uses 2×2 samples and volumestepsize of 0.25. Notice the detail in the shadows.

This render uses the same scene with 4×4 samples and a volumestepsize of 1. The fine detail in the shadow has been lost and the volume is somewhat more transparent. The quality level is approximately the same.

Volume_Torus

$HFS/houdini/help/examples/nodes/out/ifd/torus_volume_smoke.otl

Load | Launch

Volume Rendering - From Primitives

Volume rendering is a new rendering approach in mantra 9.0 that allows high-quality, integrated rendering of volumetric effects like smoke, clouds, spray, and fire.

Volume rendering is suitable for rendering many types of volumetric effects such as:

Detailed “hero” clouds, smoke, or fire
Fields of instanced clouds, smoke, or fire

It is easy to create volumes from primitives without invoking the fluid solver.

In this particular example, a primitive torus is used to render some smoke volume. Using an IsoOffset SOP produces a volume that fills the interior of the torus. Then, a material using VEX Volume Cloud is assigned to the volumetric data of the torus shape. Setting the Smoke Cloud Density to 5 and the Smoke Shadow Density to 10 helps create a more smoke-like look and feel.

Here is the torus rendered with tweaks to the volume step sizes (in the Mantra Render Operator), shadow map quality (under Depth Map Options of the spotlight), and volume primitive divisions (on the IsoOffset SOP). The smoke Diffuse color was adjusted too.

Usages in other examples

Example name	Example for
Fire Pit example	Material shader	Load \| Launch
Down Hill Lava Flow	Material shader	Load \| Launch
FurBallWorkflow	Fur surface node	Load \| Launch