Renders the scene using Houdini’s standard mantra renderer and generates IFD files.
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.
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).
ipinstead 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.
Begins the render with the last render control settings.
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 behavior of the 'Override Frame Range' in the Render Control dialog.
Two possible cases where you'd want the strict behavior:
Otherwise, you will usually set this to non-strict.
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.
For example, if the parameters are set to:
There will be 4 frames rendered (10.5, 11, 11.5, and 12), so
|Render With Take|
The output driver will switch to this take before rendering and then restore the current take when rendering is done.
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.
Choosing a target version of mantra allows you to generate an IFD targeted to a specific build of mantra.
The camera object which defines the scene.
The command (i.e. mantra) where the IFD file is sent. This will be disabled if the IFD file is saved to disk.
The location where the IFD file is saved to disk. You must turn on the Disk File checkbox to enable this parameter.
|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.
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.
|Show In Viewport|
Enabling this checkbox will cause the driver to show up in the viewport menu. By default, SOHO output drivers to not appear in the viewport menu.
The parameters on this tab determine which objects and lights are included in the IFD.
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.
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.
Objects forced to be output as matte objects.
Objects forced to be output at phantom objects.
Objects in this parameter are excluded from the scene, regardless of whether they are selected in the Candidate Objects or Force Objects.
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.
Using this parameter in conjunction with the render_viewcamera property provides a quick way of generating shadow maps for selected 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.
The lights in this parameter are added to the IFD regardless of the value in their dimmer channels.
These lights will be excluded from the scene, even if they are selected in Candidate Lights or Force Lights__.
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.
If there are no lights in the scene, a headlight is created by default. To disable, turn off this checkbox.
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.
The image or device where the resulting image will be rendered. You can set this value to
The image format or device for the output image. If you leave this at the default value of Infer from filename, the image format will be selected based on the file extension (eg. .pic will automatically generate a Houdini format image.)
Specifies the pixel filter used to combine sub-pixel samples to generate the value for the single pixel. The filter is normally specified as a filter type (eg. gauss) followed by an x and y filter width in pixels. To blur the image, increase the filter width.
There are several different pixel filters available.
Controls how transparent samples are combined to produce the color values for individual pixel samples. The sample filter is used to composite transparent surfaces before the pixel filter produces final pixel colors.
The storage type for the primary plane image. The type of quantization used will affect image quality and size. If you need to adjust the image’s dynamic range in compositing, you should normally leave this value at the default of 16-bit floating point.
The white-point of the image used during quantization. Normally you should leave this parameter at the default value of 1 unless you wish to darken or lighten the image.
Normally, sub-pixel samples are filtered using the pixel filter defined on an image plane. When this checkbox is turned on, each sub-pixel is output without any pixel filtering performed.
|Override Camera Resolution|
Normally, the resolution channels on the camera determine the output resolution. Enabling this parameter allows an alternate resolution to be used.
A specific resolution can be specified using this parameter, or alternatively, a fraction of the camera’s 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). This parameter does not affect rendering, it is only used to change how images are displayed - by stretching the pixels by this factor.
When generating an image, mantra runs the sample filter to composite samples to a single color. Mantra then runs the pixel filter to produce the final color for a pixel. A deep resolver is used to store information about each sample prior to sample filtering. This allows the image resolver to store information about each individual sample before compositing.
The .rat file to generate when the Deep Camera Map resolver is used.
|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).
For each light the deep raster plane name is prefixed with a mangled version of the path to the light. This can be specified manually by adding the rendering parameter Export Plane Prefix to the light sources. You can set the export prefix to an empty string on the output driver if you are generating deep rasters for a single light source in all cases. This will eliminate the prefix for all light sources.
The name of the image creator. By default uses the current user’s log in name.
A text comment to include in the output file.
The name of the computer where this image was created.
|MPlay Tile Order|
The direction that MPlay displays the rendered the image.
When rendering to MPlay, all Houdini sessions will send the output to the same MPlay flipbook. This can be problematic when running multiple Houdini sessions. The MPlay Label lets you specify a label for the MPlay associated with the output driver. Only renders which match the given label will be sent to that MPlay.
Display gamma for MPlay, from 0.0 to 4.0.
JPEG Quality, integer from 10 to 100.
Type of image compression to use in TIFF files.
Compression type for EXR format images.
See understanding mantra rendering for more information.
The size (in pixels) of the tiles rendered by mantra. Larger tile sizes may consume more memory.
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. This prevents additional rendering behind opaque layers.
|Use Max Processors|
When enabled, automatically set the thread count to the number of CPUs of the rendering machine.
When Use Max Processors is disabled, set the number of threads used for rendering.
|Ray Tracing Accelerator|
Controls the type of ray tracing accelerator used by mantra. A ray tracing accelerator is a spatial data structure used to optimize the performance of ray intersection tests against complex geometry.
|KD-Tree Memory Factor|
Change the memory/performance tradeoff used when constructing KD-Tree acceleration data structures. Values larger than 1 will cause mantra to use proportionally more memory and take longer to optimize the tree in an attempt to make ray tracing faster. Smaller values will cause mantra to use proportionally less memory and take less time to optimize the tree, while possibly compromising ray tracing performance. The default value of 1 will try to balance the amount of memory used by ray tracing data structures with the amount of memory used by geometry.
If you are noticing long tree construction times, try decreasing the KD memory factor to 0.1. If your render is too slow after tree construction, increase the value until you find a good balance of tree construction time vs. render performance.
|Geometry Cache Size|
The number of megabytes used for the geometry cache.
|Texture Cache Size|
The number of megabytes used for texture caching. This includes all texture caching.
|UV Render Object|
The name of the object to be rendered in UV space. Mantra is able to render an object in UV space rather than 3D space.
Only one object may be rendered in UV space.
The name of the attribute used in UV un-wrapping.
Perform hidden surface removal. When hidden surface removal is disabled, all surfaces in the camera’s frustum will be rendered, regardless of whether they are occluded. This can impact render time significantly.
|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.
|Auto-Generate Photon Maps|
Enable or disable photon map generation.
|Output OTLs with full paths|
Enabling this checkbox will expand any variables in OTL paths, breaking the dependency on Houdini environment variables, but possibly making the IFD less portable.
|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.
|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. The Xform Time Samples and Geo Time Samples parameters should be used in motion blur renders to control how motion blur is computed. By default, only transformation motion blur with 2 segments will be computed - meaning that animated SOPs will not produce blur in the render. To enable motion blur for moving geometry, it’s necessary to increase the Geo Time Samples.
|Raytrace Motion Blur|
Enable or disable raytrace motion blur for micropolygon rendering and photon map generation. By default, raytrace motion blur is disabled. This setting has no effect on the ray tracing rendering engines.
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.
Motion factor reduces shading quality using the following formula:
new shading quality = shading quality / max(pixels of motion * (1/16), 1)
Objects traveling more than 16 pixels within the frame will have their shading quality reduced by the above factor. For example, an object blurred over 32 pixels with a shading quality of 1 will have the quality reduced to 0.5. You should not use very large values for this parameter. Values between 0 and 1 are reasonable.
|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, though the default of 2 is often adequate unless significant nonlinear motion occurs within the shutter time for a frame.
|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 it is necessary to increase this parameter to a value of 2 to see motion blurred geometry. Any number of segments may be specified, though a value of 2 is often adequate unless significant nonlinear motion occurs within the shutter time for a frame.
This option has no effect on objects which use velocity blur, since velocity blur is linear by nature.
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.
The terminology refers to time, that is “leading” blur will open the shutter ahead of the current frame.
|Allow Image Motion Blur|
This checkbox controls whether mantra computes motion blur for direct visibility. If this checkbox is disabled, mantra will render without motion blur but still compute motion blurred positions so that you can use
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. Two sample values are specified for x and y, with the total number of pixel samples is determined by multiplying these values together. Normally both values are set to the same amount, with common pixel sampling settings being 3×3, 8×8, and 16×16.
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. However, often large pixel sample values are necessary with the Physically Based Rendering engine to eliminate noise.
A floating point value which adds noise to pixel sampling patterns. A value of 1 will fully randomize pixel sampling patterns, while a value of 0 turns of pixel jitter resulting in stairstep artifacts when too few pixel samples are used. Jitter only applies to pixel antialiasing and does not apply to motion blur or depth of field sampling, which are always randomized.
This property will “lock” the sampling patterns from frame-to-frame. This minimizes the buzzing caused by noise when rendering animations. The noise is still present, but is more consistent frame-to-frame.
|Ray 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.
For Physically Based Rendering, this parameter can also be used to boost the number of samples taken for each shading point without increasing the pixel samples.
|Max Ray Samples|
The maximum number of ray-tracing samples used when variance anti-aliasing.
The noise threshold used for ray variance antialiasing. Lower values produce less noisy images.
|Volume Step Size|
The distance in world space between volume samples when rendering volume primitives. Larger step sizes can be used to decrease quality and improve performance, and smaller step sizes should be used to increase quality. This parameter should be set based on the scale of your scene. For example, if your volume primitive is 100 units wide, the volume step sizes should be increased to 1 or 10 to accommodate the scale of your scene.
|Volume Shadow Quality|
A factor to proportionally decrease the sampling quality for volume shadows. Smaller values will cause mantra to use a larger step size for shadow rays. A value of 1 will produce equal quality for shadow rays and shading rays.
An integer value that controls initialization of pixel sampling patterns. Different random seeds will produce different pixel sampling patterns.
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).
To see glossy or diffuse bounces, it is also necessary to increase the reflect limit. The reflect limit is a global limiter on all types of bounces, not just reflections and refractions.
The maximum refraction bounces.
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.
This only works with PBR and with the GI Light object in raytrace/micropolygon because diffuse bounces need to be traced by a shader, and when you're rendering with micropolygon/raytrace, most shaders do not calculate diffuse bounces themselves. The PBR shader and the GI Light both include a computation of diffuse lighting.
The maximum volume bounces allowed in PBR mode.
Global raytracing bias to be used for PBR rendering, specified in world space units. Increase the raytracing bias only if doing so eliminates rendering artifacts in your render. For really small scenes (1 unit in size), it is sometimes necessary to decrease the raytracing bias.
|Bias Along Normal|
When biases are used in VEX shaders, the bias can either be performed along the ray direction or along the surface normal. When this checkbox is turned on, biasing will be along the surface normal.
Sampling color space for variance antialiasing. Setting this to Gamma 2.2 will cause darker parts of the image to receive more samples.
|At Ray Limit|
Controls how PBR deals with rays that reach the ray tracing limit, such as the reflect or refract limit.
|Smooth Grid Colors|
When micro-polygon rendering, shading normally occurs at micro-polygon vertices at the beginning of the frame. Enabling this checkbox causes the vertex colors to be Gouraud shaded to determine the color for a sample.
Turn this checkbox off when you are trying to match a background plate to eliminate any filtering which might occur on the plate. The Gouraud interpolation will cause softening of the map.
The shader to use for physically based rendering. If no shader is specified, the default VEX Pathtracer shader is used. Normally you should not need to assign a shader for this parameter unless you are a shader writer and need to make adjustments to the PBR shading algorithm.
|PBR Photon Shader|
The shader to use for photon map generation. If no shader is specified, the default VEX Photon Tracer shader is used. Normally you should not need to assign a shader for this parameter unless you are a shader writer and need to make adjustments to the PBR photon tracing algorithm.
The type of path tracing to perform in PBR mode.
When performing shading, mantra places no limits on values which may be returned. However, when performing Physically Based Rendering, it’s possible to get very large values for some rays. These extrema will show cause color spikes, which cannot be smoothed out without sending huge numbers of rays. The color limit is used to clamp the value of the
|Min Reflection Ratio|
Enables a minimum amount of secondary ray tracing even when the surface bsdf reflects only a small amount of light. Normally, when mantra encounters a surface that reflects only 10% of the incoming light, ray tracing will be optimized by sending 10x fewer secondary rays, potentially leading to unwanted noise in the image. Increasing this parameter will ensure that the specified proportion of rays are traced as a minimum even for surfaces that have a low reflectivity.
Increasing this value will cause more information to be printed out during rendering. To see render time and memory information, set the verbosity level to 1. To see more detailed information about the render, set this parameter to 3. Larger values print out progressively more information.
VEX profiling can significantly decrease rendering time, so only enable it for debugging.
|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: 4.52u 6.30s 4.24r Memory: 23.40 MB of 23.59 MB arena size. VM Size: 345.11 MB
uvalue is the user time in seconds mantra took to render the image.
This value might not be 100% accurate depending on the OS and other system variables. On Linux, this value will indicate the total time for all threads to render, so rendering with more than one processor may inflate the user time.
svalue is the system overhead incurred in rendering the frame (disk io, swap, etc.). A large system time may indicate a large amount of time spend reading or writing files.
rvalue is the wall clock time to render. This is the most important value as it gives a clear indication for the total amount of time spent rendering.
Arena size is the amount of memory mantra allocated to actually render the image. It does not reflect how much memory mantra actually used.
VM size is the virtual memory size for the mantra program. This is the amount of memory reported by the operating system and may significantly exceed the amount of memory that mantra is actually using.
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.
|Python Tile Callback|
This parameter specifies a python callback which can be called at the completion of each tile rendered. There is a built-in mantra module which allows information to be queried. There is a single function available in the mantra module. The property function allows querying of any global rendering property as well as some other special properties. The result of the property call is always a list of values.
|Shading Quality Multiplier|
A global multiplier on all shading rates in the scene. Each object has a
|Ray Shading Quality Multiplier|
Mantra allows a separate
When primitives are rendered in mantra, they are split into smaller primitives if they are too big to be rendered. The primitives are measured to determine if they are too big using the measurer.
|Z-Importance/Ray Measuring/Ray Z-Importance|
See Micropolygon Measuring above.
|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.
|Save Geometry Groups|
Controls whether geometry groups are saved to the IFD. Groups can require a significant amount of storage and are normally unused during rendering, so leaving this option disabled will improve IFD generation time and reduce file size.
|Enable Irradiance Cache|
This option enables the irradiance cache, which can significantly improve the performance of the irradiance and occlusion VEX function calls.
Enable Irradiance Cache has no effect when using area lights or the PBR rendering engines. Normally the irradiance cache should only be used with a VEX Global Illumination light or with shaders that use the occlusion() or irradiance() functions.
The maximum error tolerance between samples in the irradiance map. Normally you should only decrease this value from the default of 0.1 if there are artifacts in the render.
|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.
|Irradiance Cache File|
The file to store the irradiance cache. If multiple objects specify the same file, the cache file will contain samples from all objects.
The Read/Write mode for the file.
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.
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.
This command is run before any IFDs are generated. It is only run once per render.
This command is run before each IFD is generated.
This command is run after each IFD is generated.
Although the IFD may have been generated, this does not necessarily mean that mantra has finished rendering the image when this command is run.
This command is run one time, after all IFDs have been generated.
Although the IFD may have been generated, this does not necessarily mean that mantra has finished rendering the image when this command is run.
The following attributes on geometry control how mantra renders the geometry.
Orientation of curve/point primitives. Curves and points will be oriented so that their normals point in the direction of the orient vector attribute.
(velocity) Used for velocity motion blur computations.
Default attribute for the
Shader overrides (per primitive).
Controls width of curve/point primitives (see below).
Not used by mantra.
When mantra decides the size of point primitives, it looks for the following attributes in order:
To decide the width of curve primitives, mantra looks for the following attributes in order:
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
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).
|Ambient Occlusion||Load | Launch|
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. An Environment Light was used, and it’s parameters were promoted for easy access.
Optimizing performance/quality for ambient occlusion
There are two ways to adjust the quality and performance of renders using ambient occlusion.
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.
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.
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.
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.
|MotionVector||Load | Launch|
The example demonstrates how to generate a motion vector layer for post-velocity compositing. Load the example and render 5 frames. Then in the image viewer, switch from 'C' (colour) to 'motion_vector' to see the results.
|Volume Rendering - File Referenced Smoke||Load | Launch|
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.
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 Rendering - From Primitives||Load | Launch|
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.
|Volume Rendering - Metaballs as Volume||Load | Launch|
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.
Other examples that use this node
|Example for||Example name|
|FLIP Solver||FlipFluidWire||Load | Launch|
|Environment Light||PortalBox||Load | Launch|
|Light||TransparentShadows||Load | Launch|
|RainbowGeometryLight||Load | Launch|
|Indirect Light||IndirectLightBox||Load | Launch|
|Indirect Light||TubeCaustic||Load | Launch|
|Fetch||Fetch||Load | Launch|
|Down Hill Lava Flow||Load | Launch|
|Fire Pit example||Load | Launch|
|Mantra: VEX Volume Procedural||VolumeNoiseIso||Load | Launch|
|Fur||FurBallWorkflow||Load | Launch|
|Iso Offset||Brickify||Load | Launch|