How to Read a Render Log

The Render Log prints the progress messages, warnings and errors to the console or 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.

When encountering problems with renders, the first thing you should do with a log file is search for the word "ERROR". Most of the time you will find the source of the problem in that ERROR message.


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

Color Management

When using the SYNCOLOR environment variable, kick will override the ass color management paths so the output would be:

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 that 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 is shown here, which can be useful to figure out which shader calls are most helpful to speed up.

  • Primary: surface shading of non-shadow rays (this is traditional shading).
  • Transparent_shadow: surface shading of shadow rays when it goes through a transparent surface (needed to shade to know if the ray is blocked or can continue, and if it continues, has its color changed).
  • Autobump: each time autobump is computed, it has to compute displacement.
  • Background: the background shader.
  • Importance: calls made while computing importance tables.
  • Volume: volume shader calls.

You can use these shader stats to improve render times. If for instance, you see lots of transparent_shadow, that is usually an indication that your light samples are very high or you have lots of transparent objects. Another example would be if autobump is very high, you could try disabling autobump on meshes that don't seem to benefit from it as much. 

Geometry Stats

These stats give insight into the 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 the 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