Mantra

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.

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.

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:

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.

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 $NRENDER will have a value of 4. $Nwill have the value:

Tip

use chs(“take”) to use this value in other parameters. See the chsexpression function for more information.

Note

The Mantra ROP will not automatically gzip based on the file extension of the .ifd file. The file.ifd.gz will contain uncompressed data. However, you can set your render command to something likegzip > foo$F4.ifd.gz to compress the file.

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.

Note

Using this parameter in conjunction with the render_viewcamera property provides a quick way of generating shadow maps for selected lights.

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.

There are several different pixel filters available.

The default is “float16″ for the first plane, and”float” for secondary planes. You can override the first plane’s value with the -b command line argument to mantra.

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.

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. The compression parameter applies to opacity values, and determines the maximum possible error in opacity for each sample. For compression greater than 0, the following relationship holds

OfError = 1/(2^(10-compression))

zbias (default = 0.001) – Used in compression to “merge” samples which are closer than some threshold. Samples that are closer together than the zbias are merged into a single sample and compute an average z value.

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

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

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

Note

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.

Houdini, TIFF, PNG formats

Houdini, OpenEXR, PNG formats

Houdini format

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.

photon – Photon map generation.

For example, with the defaultvm_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

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.

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.

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.

This option has no effect on 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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”)

shadingquality = object:shadingquality * renderer:shadingfactor

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

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.