Specifies the camera that the scene should be rendered through. The field contains a path to the camera's location in the scene graph. The cameraName parameter options are available by clicking the dropdown menu.

For more information, refer to the Scene Graph Location Widget Type in Common Parameter Widgets.

Specifies the renderer to use.

Sets the size of the output image.

Pads the data window of the resulting render by the specified pixel amount on each side. The frame window is unchanged.

Adjusts the pixel aspect ratio to match one of the device aspect ratio's dimensions. Either the height or the width of the screen window is adjusted to match the output resolution.

Sets how many times a point is sampled when the shutter is open. For animated parameters within Katana (such as transforms), this is how many samples are evaluated from shutter open to close. The higher the number, the more accurate the motion blur.

Specifies the timing of the opening and closing of the camera shutter.

Specifies the render crop window in normalized coordinates: xmin xmax ymin ymax, starting in the upper left-hand corner. The part of the image that renders has a dotted red line around it.

Note:  The dotted red line isn't displayed unless you are viewing the RenderSettings node.

Specifies whether all the AOVs are rendered during Preview Render, or whether only the primary pass is rendered. If you set the output to primary, the Local Assignment box turns yellow to indicate that you are using local values.

The data type to use for encoding pixels that are transmitted between a render process and Katana. You can use this to reduce the bandwidth required for transmitting images, but at the cost of a loss of fidelity.

Choose between three options:

• float : Single-precision floating-point format (32 bits).

• half : Half-precision floating-point format (16 bits).

• byte : Reduced precision resulting in the lowest bandwidth, but possibly visible banding artifacts and a loss of fidelity when stopping images up or down (8 bits). This clamps pixel values to a range between 0 and 1.

The default value can be set using the KATANA_DISPLAYDRIVER_PRECISION environment variable.

Set which Geolib3 Runtime to use. In the majority of cases, you should select Geolib3-MT. However, a small number of scenes that are not set up for concurrent scene traversal may perform better with the Classic Runtime from Katana 3.2.

See Geolib3-MT sceneTraversal Parameters for parameter details.

Choose a cache eviction strategy from one of the three options:

• Dependency protecting

• Continual

• Relaxed

For details see Performance Optimization using a Cache Eviction Strategy.

Toggles the conversion of USD data to Katana data when performing a render or with Implicit Resolvers enabled.

When turned on, Geolib3-MT performs a pre-processing step in which it examines the topology of the Op tree to identify constructs that can be potentially optimized. One optimization is the collapsing of sequences of Ops of the same type into a single instance of that Op. There are a number of benefits to this:

• Reduced function call overhead - There is a small cost involved in scheduling an Op to cook a scene graph location. By combining chains of similar Ops, it's possible to reduce this function call overhead.

• Reduced memory footprint - A chain of 10 Ops occupies 10 separate cook results in the caching subsystem, while a successfully collapsed Op Chain occupies only 1 cook result per location.

The result of evaluating a collapsed chain of Ops, when observed from the most downstream Op, should be the same as if the chain of Ops were evaluated.

Note:   Op API calls to query upstream scene graph results, such as getAttr(), does not return the expected result when called within a collapsed chain if one of those Ops within the chain was responsible for setting that attribute. In this case the Op should use getOutputAttr() instead.

The Op tree optimizer attempts to collapse any chain of Ops of the same type if it calls GeolibSetupInterface::setOpsCollapsible() during the setup() call. Callers of this function must specify the name of an attribute which Geolib3 passes to the Op's cook() call as an Op argument. This attribute contains an ordered array of attributes (ordered upstream Op to downstream Op) containing the collapsed Ops' arguments. The Op is then able to deal with this batch Op argument as appropriate.

The time interval for the time-based scene data cache eviction trigger is specified in milliseconds.

0ms disables time-based eviction.

The cook count for which the cook-based scene data cache eviction is triggered.

0 disables cook-based eviction.

Specifies the method for cache eviction.

• Fixed cache size : If the cache size reaches a set limit of the number of entries, every new entry triggers the removal of one of the least-recently used.

• Memory-based : If the used memory in the system reaches a set level, each new cache entry causes removal of a set number of the least-recently used entries.

For Memory-based, you can set three levels of memory usage: light, medium, and heavy, to increase the amount of memory used for the cache. Each level has an eviction count to set how many entries are evicted when the cache hits that level.

cacheLimitingMode: Fixed cache size

Determines the set size of the cache. Each entry in the cache is identified by a combination of a scene graph location and an Op ID.

When the cache limit is reached, every new cache entry triggers the removal of one of the least-recently used.

A smaller cache size uses less memory, but it may lead to recooking of evicted data if it gets removed prematurely, leading to reduced performance.

cacheLimitingMode: Memory-based

Set the lowest percentage level of memory usage at which new entries will trigger the removal of least-recently used entries. The number removed is set by lightEvictionCount

Set the middle percentage level of memory usage at which new entries will trigger the removal of least-recently used entries. The number removed is set by mediumEvictionCount

If cacheEviction is on, the cacheSoftLimit governs how many cook results are stored in local caches before entries are evicted using a least recently used eviction policy.

Note:  Whilst these entries may be evicted from a local cache they may be shared amongst a number of other local caches or the central (shared cache). In which case, the entries' memory won't immediately be reclaimed.

Consider the maximum depth of the scene graph and Op tree. The cacheSoftLimit controls the size of the recently used cook result cache on a per thread basis. This means any locations cooked on a particular thread, or any locations accessed during the cooking process (such as via getAttr()), are stored in the local cache and subject to eviction based on the value of the cacheSoftLimit.

If cacheEviction is turned on, the collectionFrequency governs the time, in milliseconds, between collection cycles. During a collection cycle, Geolib3-MT gathers all cache entries evicted since the previous collection cycle and if the cook result is no longer used, evict and reclaim the memory for the cook result.

Note:   Reducing the collectionFrequency interval causes more aggressive eviction of cook results leading to a reduced memory footprint but potentially at the cost of scene traversal time.

If turned on, Geolib3-MT performs a traversal of the scene graph populating an internal cache.

The extent of this traversal can be controlled by the settings under sceneTraversal.cachePrepopulation.

If turned on, Geolib3-MT first fully traverses the scene generated by any source Op (any Op with no inputs) found in the Op tree. This setting can provide benefits when loading in geometry caches or other asset types.

Note:  Empirical tests have found that source Ops are typically followed by some form of prune operation; as a result, in these cases, turning on preCookSourceOps can generate more scene graph locations than is required which can lead to increased memory consumption and traversal times.

If turned on, Geolib3-MT identifies Ops within the Op tree that can be evaluated in parallel.

An example of this is the Merge Op:

Geolib3-MT evaluates each branch in parallel, which can reduce scene traversal times.