How to Read a Render Log

The Render Log prints the progress messages, warnings and errors to the console or to a file as kick renders an image. As well as showing the percentage completed, these detailed statistics can be used to optimize and debug scenes.

The Arnold log provides detailed statistics that are useful for debugging, optimizing and benchmarking renders. It is the first thing to examine should you encounter errors and usually the first information to send to support.


The verbosity levels vary from kick to the plugins.


0 - No Output
1 - Progress
5 - Detailed
6 - Debug


Warnings + Info



The log below contains the most common output. The first column of the log, 00:00:00, shows the time elapsed in hh:mm:ss. The second column, 773MB, shows the memory usage at that stage.

Initialization (Info)

This section shows the version of Arnold being used and its build details. It also lists the hardware specifications and operating system of the machine it was rendered on.


There is a single initialization process for the whole render session (only on the first render), with an updated process for every following render. 


Loading / Plugins

This section displays the results of importing any shaders or procedurals.

Just rendering through kick on it's own shows no plugin and the ass location.


If a plugin is being loaded (and verbosity is high enough) the shaders will be listed:

License Check

If a license is available the log will display the following.


However, if the RLM server is not running it will display a warning.

Scene Contents  

Here it will list the numbers of lights and objects (and their types) in the scene. 

Resolution / Samples

This section displays the output resolution and details about the number of samples.


Before rendering starts nodes are initialized. The stats here give insight into the objects and lights in the scene and can show warnings if anything is configured incorrectly. Note that some data is not immediately initialized, some computations are delayed until the first ray hits the object, so further information can be shown during the render.

Drivers / AOVs

Here are the drivers and AOVs used in the scene, and any warnings if they are set up incorrectly.


Now that the render is starting, the log will show how many buckets are being used and at what size. If any importance tables need to be generated, in this case for the skydome, they will be done so now, showing the average energy value. Percentage completed is shown in 5% increments along with the average rays per pixel. This value will show at a glance if your sampling settings are too high.


Once the render is complete it will be written to file (or screen) using the selected output driver. The log will show the relative path.

Scene Creation Stats

These timings show the time taken to load plugins and .ass files.

Render Time Stats

These timings show the time spent performing various tasks. Typically pixel rendering will take up most of the time, if that's not the case then looking at the node initialization and geometry stats might reveal inefficiencies. Low machine utilization may indicate that other processes on the same machine are slowing down the render. But it can also indicate that a lot of time is spent performing single threaded tasks, for example in node initialization, procedurals or mesh processing. Another possibility is that there is a lot of (slow) file access, typically for textures or volumes. Looking at the texture stats might reveal problems.

Memory Stats

Here memory used at startup and peak memory for various types of data are listed. When using a plugin the startup memory shows how much memory the host application is using, when rendering from kick the startup memory is small which typically means larger scenes can be rendered. If memory usage is too high these stats indicate which data would be most helpful to reduce.

Ray Stats

These are the number of rays of each type, per pixel and per AA sample. If the render time is high, these numbers give insight into which types of samples are most expensive to render and would be most helpful trying to reduce.

Shader Stats

The number of shader calls in various contexts are shown here, which can be useful to figure out which shader calls are most helpful to speed up.

Geometry Stats

These stats give insight into amount of geometry in the scene. If memory usage is high or scene setup takes a long time these can be used to find the objects that contribute to it most, and would benefit from being simplified or having their subdivision iterations reduced.

Texture Stats

Detailed statistics for image textures. These give insight into which textures use most memory, and which textures are untiled and would benefit from being converted to .tx files. The percentage of main cache misses should be very small for good performance, if it is high render time can be significantly increased. If the main cache misses are too high it helps to ensure only .tx files are used, reduce the number of textures, or tweak the texture settings.


When Arnold is finished, it will release any resources, memory/threads and shutdown.

  • No labels