POV-Ray : Beta : Real-Time Raytracing
  Real-Time Raytracing  

The beta 17 release of POV-Ray contains a provisional implementation of a real-time raytracing feature. This feature may or may not remain; there is no guarantee that it will be part of the final 3.7 release. In addition to the RTR feature, there are two other related features that also are provided for testing purposes: clockless animation and video capture (the latter is currently available on Win32 only).

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.

  Clockless Animation  

Clockless Animation is a very specific form of POV-Ray's animation feature set which allows a series of images to be rendered without re-parsing the scene file. Traditionally the clock variable is used to control animation scene content. For this to work as expected, it is necessary to re-parse the scene file. As the aim of clockless animation is to avoid such re-parsing, the clock is not able to be used in its normal manner; it is from this fact that the feature name derives. Note also that, in addition to not re-parsing the scene file, neither is the scene re-bounded. This implies that no finite objects may move between frames of the render. Clockless Animation enforces this by not providing any means to do so.

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.

  Video Capture  

Video capture is a highly experimental feature that will certainly change prior to release, if indeed it is kept at all. Currently it is only implemented on the Windows platform. Video Capture ('vidcap') allows a video source (e.g. webcam) to be fed into a rendering just as if it were a still image. Currently, this is done by overloading the 'sys' filetype in image maps; if vidcap is kept for final release this will definitely change.

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

pigment { image_map {sys ":vidcap:" map_type 0} }
and a more complex one:
pigment { image_map {sys ":vidcap:width=640:height=480:double-buffer=0:skip-initial=0:gamma=1.0" map_type 0} }
The requirements are that the image type is 'sys' and that the image filename starts with the text ':vidcap:'. The text following the :vidcap: (if any) is considered to be additional options which are then provided to the platform-specific video capture support code.


At this point of time the following options are supported:

If omitted, defaults are:
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.

Windows setup

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

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.