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.
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 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:
If a license is available, the log will display the following.
However, if the RLM server is not running, it will display a warning.
When using the SYNCOLOR environment variable, kick will override the ass color management paths so the output would be:
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 that 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 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.
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.
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.