TimesScene parsing – How long it took to get the data from the native application format to the internal Corona format. Excessive times (more than a few seconds or tens of seconds for complex scenes) can be caused by running out of RAM, using slow network drives, complex scatters and geometry models, etc. Geometry – How long it took Corona to prepare the geometry for rendering. This includes computing displacement, building, and acceleration structure, and preparing the lights for sampling. Excessive times (more than a few seconds or tens of seconds for complex scenes) are most often caused by using too detailed displacement, using too many textured lights, or running out of memory. UHD cache precomp – How long it took to calculate UHD cache. The time depends on resolution, scene complexity, and UHD cache settings (the animation preset calculates significantly longer, but it does not flicker in animation). Rendering – Total elapsed rendering time. Denoising – How long the denoising took. Denoising is optionally computed after rendering. Its running time is dependent only on resolution (number of pixels) and the number of render elements to be denoised - it has to run from scratch for each element. Estimated remaining – If any render limit is set (time, passes, or noise level), Corona computes the best possible time estimate. If no limits are set, '—' is shown and the user has to stop the render manually. The real remaining render time can differ and this estimate is frequently updated. |
TOTAL elapsed – the total elapsed rendering time. ScenePrimitives unique – Numbers of unique (non-instanced) primitives in the scene. Primitive means a single triangle, hair strand, etc. Each such primitive is stored in the memory, so this number is directly proportional to the RAM usage (1 primitive takes up about 200 Bytes). Primitives displac. – The number of unique (non-instanced) micro triangles created by displacement in the scene. Each such object takes a certain amount of memory but is generally an order of magnitude smaller than regular triangles. Primitives inst. – The number of primitives in the scene after instancing allows storing a single object in the memory just once and placing it into the scene multiple times with almost no additional memory usage. This is extremely useful e.g. for forests, grass, etc. Geometry groups – The number of unique geometry groups in the scene. One geometry group roughly corresponds to one separate mesh/object in the source scene, not counting instanced meshes. This number does not significantly influence the performance/memory usage, with a single exception; high values (thousands and more) can slow down the preprocessing phase. Instances – Number of geometry groups in the scene after instancing is applied. Each instance takes about 1000 Bytes of memory. Lights (groups) – The first value is the total number of light-emitting primitives in the scene and the second value is the number of instances that contain these primitives. High values usually mean a scene with complex illumination, where slower rendering is to be expected. Only true light emission counts - neither self-illumination, nor Light material with Emit light off count. Instancing is disabled for the light-emitting primitives, so applying Light material to a heavily instanced geometry (such as a forest) can cause a surprising increase in the preprocessing time and memory usage. |
UHD CacheRecords – Numbers of discrete points in the scene for which the illumination is computed during preprocessing and which are used for the interpolation during rendering. Complex scenes and animations, where higher precision is required, cause this number to increase, which in turn makes the precalculation slower. Success rate – The percentage of rays that were accelerated using the cache. This is the effectiveness of the cache, e.g. 70% meaning that 7 out of each 10 rays were accelerated. The higher this number, the faster is the rendering as more rays are accelerated. PerformancePasses total – The total number of passes computed. One pass in Corona means that each pixel received on average 1 sample. The number of passes directly influences the quality of antialiasing, the depth of field, and the motion blur effects. Smaller images accumulate passes faster as there are fewer pixels to process. Also if Rays/sample is too high, then too much work is spent per pixel, causing the number of passes to stay low, which slows down the antialiasing/depth of field/motion blur computation. A limit for the number of passes can be set in render settings. Noise level – An estimate of the remaining noise level in the image. A limit for the noise level can be set in render settings. Around 2% is usually being enough for the final images, 5% for the final images with denoising, and anything higher than that being suitable for the previews. Unlike the number of passes that increases linearly in time, the noise level decreases nonlinearly: the necessary time to halve the error (for example from 10% to 5%) is 4 times longer. |
Rays total – The average number of rays computed per second since the render started. Rays/s is a measure of the brute force computation power of the renderer. Comparing rays/s between different machines is a good way to compare their CPU performance. The number is also higher in simple scenes when using simple materials. Too low of a number (lower than usual for the machine) can be due to problems with CPU overheating, running out of RAM, other CPU utilization problems, or just having too complex materials/shaders. Rays actual – Number of rays computed in the last second. Rays/s is a measure of the brute force computation power of the renderer. Comparing rays/s between different machines is a good way to compare their CPU performance. The number is also higher in simple scenes when using simple materials. Too low of a number (lower than usual for the machine) can be due to problems with CPU overheating, running out of RAM, other CPU utilization problems, or just having too complex materials/shaders. Samples actual – Number of pixel samples computed in the last second. This is the rate of how fast the anti-aliasing, depth of field, and motion blur are computed. This number is the rays/s statistic divided by rays/sample. Rays/sample – How many rays are needed to compute a one-pixel sample. This is the measure of the shading complexity of the scene, with high numbers meaning that a lot of work needs to be done to compute each pixel. This can be caused by using too complex shaders (with ambient occlusion and rounded edges), materials having too high albedo, or using too high GI vs. AA balance. VFB refresh time – Shows how long the VFB window takes to redraw last time. Preview denoiser time – Shows how long it took to denoise the VFB image. | 
