Mantra render node

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.

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.

White point for the image plane.

Normally, sub-pixel samples are filtered using the pixel filter defined on an image plane. When this is turned on, each sub-pixel is output without any pixel filtering performed.

The image:resolution property will be scaled by the image:samples property to determine the actual output image resolution. For example, if image:resolution was (1024,512) and image:samples was (4,6), the image rendered would have a resolution of 4096 by 3072. Each pixel would represent a single unfiltered sub-pixel sample.

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.

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 you render a target node with this option on using HQueue, the server will split frames to render into separate tiles and render each tile as a separate job. When you render locally with this option on, Mantra will render a single tile instead of the entire frame.

Split the frame into this number of tiles horizontally, when Tile render is on.

Split the frame into this number of tiles horizontally, when Tile render is on.

Which tile to render, when rendering locally with Tile render on. Tile numbers start at 0 in the top left and increase left to right, top to bottom.

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.

Options:

• filename (default = “”) – The filename to output the deep shadow information.

• ofstorage (default = “real16”) – The storage format for Of. The value should be one of...

  • real16 – 16 bit floating point values.

  • real32 – 32 bit floating point values.

  • real64 – 64 bit floating point values.

• pzstorage (default = “real32”) – The storage format for Pz. The value should be one of...

  • real16 – 16 bit floating point values.

  • real32 – 32 bit floating point values.

  • real64 – 64 bit floating point values.

• ofsize (default = 3) – The number of components to store for opacity. This should be either 1 for monochrome (stored as the average value) or 3 for full RGB color.

• compression (default = 4) – Compression value between 0 and 10. Used to limit the number of samples which are stored in a lossy compression mode.

• zbias (default = 0.001) – Used in compression to “merge” samples which are closer than some threshold.

• depth_mode (default = “nearest”) – Used in compression to determine whether to keep the nearest, the farthest or the midpoint of samples. The possible choices for depth_mode are...

  • nearest – Choose the smallest Pz value.

  • farthest – Choose the largest Pz value.

  • midpoint – Choose the midpoint of Pz values.

• depth_interp (default = “discrete”)

  • discrete – Each depth sample represents a discrete surface.

  • continuous – Each depth sample is part of a continuum (i.e. volume).

Example: shadow filename test.rat ofsize 1

The name of the image creator. By default uses the current user’s log in name.

Houdini, TIFF, PNG formats

A text comment to include in the output file.

Houdini, OpenEXR, PNG formats

The name of the computer where this image was created.

Houdini format

The direction in which MPlay renders the image. Possible values are "middle" (middle out), "top" (top down), or "bottom" (bottom up).

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. Possible values are "None", "LZW", "AdobeDeflate", "Deflate", "PackBits", "JPEG", "PixarLog", "SGILog", "SGILog24".

See understanding mantra rendering for more information.

Though this IFD token has an integer value, it’s also possible to set the value through a string value.

• micropoly – Micropolygon scanline rendering (default).

• raytrace – All rendering will be performed using ray-tracing.

• pbrmicropoly – Physically Based Rendering using micro-polygon scanline rendering

• pbrraytrace – Physically Based Rendering using ray-tracing only.

• g – Photon map generation.

• viewpohoton – View dependent photon map generation.

• irradiance – Irradiance cache creation (partially implemented).

• metropolis – Physically Based Rendering using metropolis integration (partially implemented).

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.

When enabled, automatically set the thread count (renderer:threadcount IFD property) to the number of CPUs of the rendering machine.

When Use Max Processors (renderer:usemaxthreads IFD property) is disabled, sets the number of threads Mantra uses for rendering.

The proportion of physical memory Mantra will use for its unified cache.

For example, with the default vm_cacheratio of 0.25 and 16 Gb of physical memory, Mantra will use 4 Gb for its unified cache.

The unified cache stores dynamic, unloadable data used by the render including the following:

• 2D .rat texture tiles

• 3D .i3d texture tiles

• 3D .pc point cloud pages (when not preloaded into memory)

• Tessellated meshes required by ray tracing

  • Displacements

  • Subdivision surfaces

  • Bezier and NURBS primitives

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.

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.

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.

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

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

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.

Enable or disable photon map generation.

Enabling this checkbox will expand any variables in OTL paths, breaking the dependency on Houdini environment variables, but possibly making the IFD less portable.

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.

Mantra will render with depth of field. The parameters controlling depth of field may be found on the camera object.

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.

Enable or disable raytrace motion blur for micro-polygon rendering and photon map generation. By default, raytrace motion blur is disabled. This setting has no effect on the ray tracing rendering engines.

Automatically adjusts the shading quality for objects which are significantly blurred. Increasing the motion factor of an object will dynamically decrease the shading quality based on the rate of motion. This can significantly speed up renderings of rapid moving objects. It also affects depth of field and may improve speed of scenes with deep depth of focus.

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.

When using the Ray Tracing or Physically Based Rendering rendering engine, motion factor will only affect the geometric subdivision for subdivision surfaces, NURBS/beziers, or displacements and will not change the amount of shading.

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.

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.

Controls where the blur occurs in the image relative to the position of the object at the current frame. A value of -1 blurs from the position at the previous frame to the position in the current frame. A value of 0 blurs from halfway to the previous frame to halfway to the next frame. A value of 1 blurs from the current position to the position at the next frame. You can use fractional frame values and values greater than -1 or 1 to move the blur less or more.

To change the size of the blur, change the Shutter time (shutter property).

This parameter replaces the old Motion blur style (motionstyle) parameter, which only allows values of “before” (shutter offset=-1), “center” (shutter offset=0), and “after” (shutter offset=1).

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 getBlurP() in shaders to export motion vectors.

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.

When ray-tracing VEX functions are invoked, send out additional rays to perform anti-aliasing of ray-traced effects. This will typically generate higher quality ray-tracing. The sampling is determined by image:minraysamples and image:maxraysamples.

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.

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.

The maximum number of ray-tracing samples used when variance anti-aliasing.

The variance threshold to send out additional anti-aliasing rays. When near-by samples are very similar, fewer anti-aliasing rays will be sent out. When near-by samples are different, more rays will be sent.

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.

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.

Uses an optimization to speed up raytracing of translucent objects (volumes, sprites, and transparent surfaces) which normally contain many highly transparent samples per pixel. This may make the image noisier than without stochastic transparency, so you may need to compensate by, for example, increasing the pixel samples. You should generally leave this option on.

When this option is on, mantra randomly selects a certain number of transparent samples per pixel to shade (controlled by the Transparent Samples parameter). When this option is off (the default prior to Houdini 12), mantra shades all transparent samples.

The renderer ignores this option for micropolygon rendering (except for secondary ray tracing) and for renders that only generate opacity (such as deep shadow maps). In those cases it is more efficient to composite all the transparent shading results.

Added in Houdini 12.

The number of transparent samples to shade when Stochastic Transparency is on. Higher values improve shading quality for volumes and transparent surfaces, but are slower to render.

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.

When biases are used in VEX shaders, the bias can either be performed along the ray direction or along the surface normal. If this parameter is turned on, biasing will be along the surface normal - using the “Ng” VEX variable.

If the ray direction and normal point in different directions, the normal will first be flipped and then biasing will be performed in the direction of the flipped normal. This setting is particularly useful when ray traced surfaces that are seen edge-on.

Sampling color space for variance antialiasing. Setting this to Gamma 2.2 will cause darker parts of the image to receive more samples.

Controls how PBR deals with rays that reach the ray tracing limit (for example the reflect or refract limit).

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.

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.

• diffuse – Trace all diffuse and specular bounces, but once a diffuse bounce is encountered continue tracing only diffuse reflections.

• all – All paths are traced. This option can be used to enable rendering of caustics without the use of photon maps - however when using point or small area lights, the rendered result can turn out to be extremely noisy.

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 Cf variable to avoid these spikes.

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 the minimum reflection ratio 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 leys you do analyze shader performance. Turning this on will slow down shading, especially when NAN detection is turned on.

When NAN detection is turned on, each instruction executed in VEX will be checked for invalid arithmetic operations. This will check for division by 0, numeric overflow, invalid operations. Errors like this will typically result in white or black pixels in the resulting image.

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
    

• The u value is the user time in seconds mantra took to render the image.

  Note

  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.

• The s value 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.

• The r value 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.

This property 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.

The special properties queried may be...

• tile:ncomplete – The number of tiles which have been completed.

• tile:ntiles – The total number of tiles in the image.

• tile:laptime – The number of seconds taken to render the last tile.

• tile:totaltime – The total number of seconds to render since the render began. This does not include time to load the scene, but rather is defined as the time since the first tile began rendering.

• tile:coords – The tile bounding box (in pixels).

• tile:memory – The amount of RAM in use by mantra.

import mantra
import sys

tile = mantra.property("tile:ncomplete")(0)
if tile == 1
    print mantra.property("renderer:name")
    print mantra.property("renderer:version")

A global multiplier on all per-object shading quality (vm_shadingquality) parameters in the scene. This parameter can be used to globally increase or decrease shading quality. The shading quality used for an object is determined by...

    shadingquality = object:shadingquality * renderer:shadingfactor
    

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.

There are several different measurers available, each which take some optional arguments.

This parameter controls the z-importance for nonraster measuring. See vm_measure above.

This parameter is obsolete in Houdini 12. See vm_measure.

This parameter is obsolete in Houdini 12. See vm_measure.

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.

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.

Enables the irradiance cache, which can significantly improve the performance of the irradiance and occlusion VEX function calls.

This 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.

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.

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.

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 global irradiance file.