The real-time raytracing feature is activated via the Real_Time_Raytracing INI option or the +rtr command-line option. Internally, this causes POV to turn off file output and render the selected scene multiple times. Once all threads in the render have completed a single frame, the frame is sent to the frontend for display as a single message, and the threads then start rendering the same frame again (optionally changing the camera first, if clockless animation is enabled).

It is important to note that while the display preview window is only updated once per frame, the backend still uses render blocks as has been the case since the first beta of 3.7. This is important to remember since the size of the render block can affect the frame rate in a real-time render. Setting it too small can reduce performance. However setting it too large can cause idle CPU's (assuming you have an SMP system), since all threads have to wait until the last block is completed before starting on a new frame. This could impact performance if the last block(s) to be rendered (lower-right) are quite slow, and a large block size is being used.

When used with clockless animation and video capture, the RTR feature can lend itself to some interesting renders, provided a sufficiently powerful computer is used (two cores is recommended; four cores is of course better). However if you are willing to confine yourself to simple scenes and/or use low resolution (e.g. 160x120), it is still possible to use it on single CPU computers; YMMV.

Note that currently, it is not possible to save the rendered RTR output to disk. We will provide this as an option if we keep RTR in POV-Ray. Also, the current implementation does not provide any means of synchronising the camera selection with time; that is, if the frame rate changes (as it will tend to do if camera motion reveals or hides items that can slow down the render), the relative rate of camera motion will also change. If RTR turns out to be popular enough, we might investigate the possibility of the camera selection being keyed by elapsed time rather than frame count. This would allow a more consistent rate of motion at the expense of possibly having 'jerky' output if the render slows down.

As things stand, a clockless animation ('CA') scene has exactly one thing that may change from frame to frame: the camera. Each frame of a CA has an associated camera, which is declared in the SDL in the normal manner. In fact, SDL has not been changed at all to permit this feature to work. Provided that CA has been activated by using either the Clockless_Animation INI entry, or the +kla command-line option, POV's parser switches from complaining when an additional camera definition is encountered to instead storing a list of all cameras declared.

Put simply, each camera definition in the SDL represents exactly one frame of the animation, in the order that they are parsed. The number of frames thus is the number of cameras, and the normal first and last frame INI parameters are ignored. (The subset start and end still work as expected, though they do not apply during real-time raytracing).

Currently, the use of clockless animation is limited to the real-time-raytracing feature. However it is intended to expand its scope to normal rendering as well.

Here is a simplistic example of an image map that will obtain an image from a video capture device:

At this point of time the following options are supported:

width and height - the default for the video capture device.
double-buffer    - turned on
skip-initial     - 0 frames (i.e. turned off)
gamma            - 1.0

It is possible to specify just the width or height, in which case the code will default to using the first supported resolution with that size in that dimension (i.e. it won't care what the other dimension is. Specifying '-1' as a width or height is also a way of saying it is a "don't-care". If the requested size is not available, the render will fail.

skip-initial is the number of frames to skip before returning from the video device initialization. This is needed on some webcams that need a number of frames to perform their setup (such as auto exposure and auto white-balance). This matters mostly if the vidcap input is being used for something other than real-time rendering.

double-buffer is a means of telling the video capture system to store the incoming video data in a separate buffer, which is then copied to the main buffer at the end of each rendered frame. Typically this is what you would want. However it has a time penalty on SMP systems due to the use of a mutex and thus is by default turned off. This means that it is possible to see 'tearing' and similar artifacts in RTR.

gamma allows an input device to have a specific gamma correction applied to the delivered pixels prior to their being applied to the image map. Generally this is best left at 1.0.

The video source is chosen via a new menu, as shown in the image below.