Skip to content
07-848 2005

Application SDK

Interactive CPU Rendering

V-Ray Interactive handles changes in the scene description after rendering has started and re-renders the image immediately, progressively improving image quality. This makes this render mode preferable for use cases where the scene is changed a lot and visual feedback is required. It is slightly less efficient than...

Last updated 28 April 2026

V-Ray Interactive handles changes in the scene description after rendering has started and re-renders the image immediately, progressively improving image quality. This makes this render mode preferable for use cases where the scene is changed a lot and visual feedback is required. It is slightly less efficient than production mode, so for final rendering and specifically for distributed rendering, production mode is preferable.

The interactive engine (internally called RTEngine) supports GPU and CPU rendering. GPU rendering is covered in the next chapter. Interactive CPU mode is the default when creating a VRayRenderer object. A quick example that changes camera zoom:

Python

C++

C#.NET

Node.js

Again, we are ignoring some events in the example code, and we will cover them in the Events lesson.

The most important one OnProgressiveImageUpdated is also covered here Viewport Rendering.

Committing changes

The default behavior is to apply any scene change, such as object addition and deletion or parameter change, immediately. This causes the interactive RTEngine to stop sampling, modify the scene, discard its old samples and image so far and start sampling again. This is convenient for quick test code, but if you have some code that creates multiple objects and their properties at once, this can be quite inefficient. You can disable this with the autoCommit VRayRenderer property. You can use to change it at any time. When you disable auto-commits you have to manually call commit() to apply your accumulated changes. This way you can make efficient batches of changes.

The V-Ray team strives to make the various kinds of scene changes work directly, but there are cases when RTEngine fails to recognize that it has to update some internal data and the change may not be visible in the image. This is rare, but if you have an issue like this try to stop and start the renderer to see if the change becomes visible. If not, the issue is somewhere else. But if it works, then you might have to change your code to re-create and re-link the specific plugins involved as a workaround to avoid having to restart.

Python

C++

C#.NET

Node.js

End conditions

There are three possible conditions for the interactive rendering to stop and to consider the frame finished. They are all set through VRayRenderer methods/properties:

  • Time (interactiveTimeout setter in VRayRenderer)
  • Number of sampling passes (interactiveSampleLevel setter in VRayRenderer)
  • Noise level achieved, a.k.a. noise threshold (interactiveNoiseThreshold setter in VRayRenderer)

When any one of these conditions is met, the renderer stops. Each of them can be set to infinity with value 0, so that it is never achieved. The VRayRenderer object has a flag called keepInteractiveRunning which prevents the renderer from closing the render session when an end condition is met. If this flag is set (by default it is not) sampling will stop and the renderer will become idle (the render state called 'RENDERING_AWAITING_CHANGES'), but it will start sampling again upon any scene change. Otherwise you'd have to start the renderer again and wait for its initialization.

Sampling can also be paused manually with the pause() method. This frees up your computational resources but not your memory. Rendering is not resumed by scene changes when paused, it can only be resumed by the resume() method.

Python

C++

C#.NET

Node.js

Parameters

Options for the Interactive engine are available in SettingsRTEngine. With the exception of those named "cpu_*", they apply to Interactive GPU too:

  • trace_depth - Deprecated, use SettingsOptions::mtl_maxDepth instead. Represents the maximum number of bounces that will be computed for reflections and refractions.
  • gi_depth - The number of bounces for brute force indirect illumination. Other GI settings (i.e., whether GI is enabled or disabled) are taken from the SettingsGI plugin.
  • cpu_bundle_size - Controls the number of rays that are processed together. Smaller values may increase interactivity. It is not recommended to change this value unless you have a good reason.
  • cpu_samples_per_pixel - The number of rays that are traced for each pixel during one image pass. The greater the value, the smoother the picture from the very beginning of the rendering with GI, but interactivity may be significantly diminished, and image updates will come at longer intervals. Increasing this value also reduces the amount of data transferred from render servers back to the client machine in DR.
  • coherent tracing - True to enable coherent tracing of GI/reflections/refractions, etc. Default is false.
  • stereo mode - True to enable side-by-side stereo rendering. Default is false.
  • stereo_eye_distance - Distance between the two cameras for stereo mode.
  • stereo_focus - Focus mode (0 - none, 1 - rotation, 2 - shear)
  • progressive_samples_per_pixel - When enabled, V-Ray Interactive starts rendering the image with a lower cpu/gpu_samples_per_pixel value and then progressively increases it. This results in faster initial image updates, improving interactivity.
  • undersampling - Non-zero to use undersampling, 0 otherwise. Value of N means 1/(2^N) initial resolution in each dimension. When enabled, V-Ray Interactive starts rendering the image at a lower resolution in order to speed up the initial preview. Later, the image is rendered at its final resolution.
  • disable_render_elements - If true, V-Ray Interactive will produce only RGBA. Default is false, but render elements still have to be added explicitly.
  • max_render_time - Specifies the maximum time (in minutes) for refining the image (0 = infinite). This is set through the renderer object's constructor
  • max_sample_level - Specifies the maximum samples per pixel for refining the image (0 = infinite). This option is useful when you want to ensure consistent quality for different renders. This is set through the renderer object's constructor
  • noise_threshold - A threshold that determines when to stop refining a pixel. Higher values allow more noise in the image. Lower values try to reduce the noise. A value of 0.0 disables the threshold and sampling is not limited by noise. Recommended value range is 0.2-0.001. This is set through the renderer object's constructor
  • max_draw_interval - Maximum time in milliseconds between partial image updates. This is disabled by default (set to 0). When enabled image updates will come at most at this time interval, but only part of the frame will contain new samples.
  • min_draw_interval - Minimum time in milliseconds between image updates. This is disabled by default (set to 0). When enabled image updates will not be emitted before this interval elapses. This can help with reducing processing burden.
  • interactive - Flag used to disable some production-only features in interactive mode. Default is false.

Note that SettingsImageSampler is ignored in Interactive mode.

Feedback speed

Some of the above settings can be used to increase the speed at which image updates arrive, at the cost of being of low quality or partial:

  • For the fastest initial result, enable undersampling. This will give you a blocky image, but the user will see some result very soon.
  • After the undersampling phase, the cpu_samples_per_pixel parameter defines how often the whole image is updated. In most cases it should be ok to set this to 1. Larger values may lead to a slightly faster end result.
  • As a compromise, you can set a larger value, but also enable progressive_samples_per_pixel to have the frequent updates in the beginning when the user is more likely to make changes and interrupt the sampling pass.
  • The max_draw_interval can be used for heavy scenes and large resolutions, where even at 1 sample per pixel, the updates take a long time.
  • Conversely, if the scene is very light and the processing hardware is powerful, you may avoid too many updates and their overhead with min_draw_interval.