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
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,
MB, shows the memory usage at that stage.
There is a single initialization process for the whole render session (only on the first render), with an updated process for every following render.
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:
If a license is available the log will display the following.
However, if the RLM server is not running it will display a warning.
Here it will list the numbers of lights and objects (and their types) in the scene.
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.
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.
These timings show the time taken to load plugins and .ass files.
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.
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.
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.
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.
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.
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.