The number of threads used for rendering. Set it to zero to autodetect and use as many threads as cores in the system. Negative values indicate how many cores not to use, so that -3, for instance, will use 29 threads on a 32 logical core machine. Negative values are useful when you want to reserve some of the CPU for non-Arnold tasks.
Negative numbers are also allowed. If specifying 0 threads means use all cores on a machine, then negative numbers can mean use all but that many cores. For example, threads=-2 means use all but 2 cores, while threads=2 means only use 2 cores. This is useful when you want to leave one or two cores for other tasks. One example of this is so that Houdini can be more responsive while Arnold is rendering in the Render View.
Adjusts the priority of the render threads.
Arnold can pin threads on Linux, so they don't jump between multiple processors. This can improve scalability in modern machines, multiple processors. It can be set to off, on, or auto. By default is set to auto, meaning that if the number of threads is more than half the number of logical cores on the machine, Arnold will pin the threads. If client code, for instance, a custom shader, spawn their own threads manually (with pthread_create or similar), these threads will inherit the same thread affinity, which totally breaks the point of spawning threads; in these situations, they can either set options.pin_threads to off, or they can create their threads with the Arnold API AiThreadCreate() which will un-pin the created thread.
If client code, for instance, a custom shader, spawn their own threads manually (with pthread_create or similar), these threads will inherit the same thread affinity, which totally breaks the point of spawning threads; in these situations, they can either set options.pin_threads to off, or they can create their threads with the Arnold API AiThreadCreate() which will un-pin the created thread.
Specifies the spatial order in which the image buckets (i.e. threads) will be processed. By default, buckets start in the center of the image and proceed outwards in a spiral pattern.
The size of the image buckets. The default size is 64x64 pixels, which is a good compromise; bigger buckets use more memory, while smaller buckets may perform redundant computations and filtering and thus render slower but give initial faster feedback.
The image is rendered several times with increasing AA samples until the full quality set by the AA Samples in the Render Settings is reached. Disabling this option, reverts to the usual rendering option.
The initial AA samples used for the first progressive render. Negative values sub-sample the render, allowing faster feedback in the render window.
Defines a location to search for plugins such as shaders, procedural plugins that create new node types, and volume plugins.
For example, if you load ass files from a different plugin, you may need to set the plugin_searchpath to load plugin-specific shaders (such as mtoa_shaders).
Defines a location to search for procedural nodes that load ass files (or obj or ply files).
Defines a location to search for textures.
Allows additional include search paths to be provided to OSL when compiling shaders. This option is a single string that can contain multiple search paths separated by a colon (
:) or a semi-colon (
Specify an MPlay Session label (useful with multiple workspaces).
Option to create intermediate directories for output images and ASS files.
Flush SOP cache after each frame to reclaim memory.
You can use Ctrl+LMB in the Render View to pop up a panel with the material that shaded the pixel that was clicked.
Enable properties inheritance for geometry at the expense of translation time.
Initialization and update of scene nodes can be multithreaded to lower the scene preparation time in complex scenes with many objects, shaders or lights.
Share work among all threads for the last remaining buckets.
Rendering will abort as soon as an error is detected. This is the recommended setting. In general, you should not ignore important error messages, or you'll risk crashes, rendering artifacts, and undefined behavior.
If set, rendering will stop if the license is not detected when the render begins.
Render with Watermarks (Skip License Check)
Switch this on to avoid taking an Arnold license from the license server. This will always render your image with a watermark.
A color manager is a connection between Arnold and an external color management library like OpenColorIO or synColor. Color managers hold information about the availability of different color spaces and also transform RGB colors to and from the rendering color space.
Auto Color Space
You can set the input color space or the output driver's color space to auto. If you do this, Arnold will use whatever you have set in the Auto Color Space option.
If it exists in the OCIO config, this should be set to the name of the 'sRGB Gamma' color space. This is used internally for input and output color spaces in 'auto' mode. If set by the user, this color space is also used as a reference to detect the rendering color space gamut and white point.
Rendering Color Space
Using specific implementations of a color manager it is possible to specify Arnold's rendering color space. Arnold's default rendering color space is Linear sRGB. For other color spaces Arnold will try to auto-detect chromaticities and illuminant, and will expect all data (textures and .ass file parameters) in that same color space. An important note is that different rendering color spaces will yield different render results when compared with the default sRGB linear. These color and intensity shifts will be more visible with transmission, but will also affect illumination and subsurface. Because of this, shader adjustments and texturing should happen in the same color space as the rendering one.
This is the default linear color space that Arnold will use as its rendering color space. Arnold's default color space is 'sRGB linear, ' but this can correspond to any linear color space if needed. If chromaticities for this linear color space can be guessed or are user specified certain spectral effects will take them into account, but not other adaptations for albedos, transparencies, etc. are applied.
You must set the OCIO environment variable to the config.ocio color profile path before starting Houdini. Houdini will then pick up the color spaces in the config and make them available as options for rendering color space, texture input color space and driver output color space.
The OptiX Denoiser (based on Nvidia AI technology) is integrated into Arnold for use with IPR (so that you get a very quickly denoised image as you're moving the camera and making other adjustments). It can be applied to any AOV.
Rendering with the AOV set to Denoise with OptiX
There are a couple of requirements to be aware of when using the OptiX denoiser, however:
- You must have a Nvidia GPU with a driver version of at least 390 installed. Note that the OptiX denoiser is not available on OSX.
- The OptiX denoiser does not work with Merged AOVs (unlike the Arnold Denoiser).
- If you want to use the OptiX denoiser on multiple AOVs you must apply it to each AOV.
- If you wish to have the same AOV saved to EXR in both original and denoised mode, to avoid name duplication you can add the suffix "_denoise" to the AOV name and the OptiXdenoiser will detect the original AOV.
- Depending on the scene size, you may have to lower the Min memory - Render Settings > System > OptiX denoiser > Automatic Device Selection. This is also dependant on how much memory you have on your GPU. The default settings act on the side of caution and won't use your GPU if you have less than 512Mb available so that all GPU resources aren't used or worse try to use more memory than is available on the GPU. Users can change this parameter at their own risk.
The OptiX denoiser only works on full frames rather than buckets.
The OptiX denoiser is only compatible with a Nvidia driver version of at least 390 installed.
Pepe model by Daniel M. Lara (Pepeland).