StereoPOV: technical details

(It is safe to skip this section if not interested)

Implementation

Some technical details

Basic adjustments: Stereo_base added to camera struct.
The switch opts.Stereo_trace will be activated, if Frame.camera is stereoscopic.

While STEREO-tracing, the width of the image created is twice the number of columns specified. Thus introduced new variable Frame.Output_Screen_Width to be used while creating (or re-reading) the output file and for allocating memory for the row buffers. WriteLine() will use the width specified while opening the file. When opening partial rendered files, the line width may be adjusted downwards to fit into the preallocated arrays in order to prevent a crash. Of course, if the image width specified doesn't match the width of the continued render, the output will be rubbish, but POV-Ray won't crash.

The VistaBuffer in it's current form can't be used in STEREO-trace mode. We have two centres of projection and, moreover, even in stereoscopic perspective camera the "direction" vector is no longer orthogonal to the "up" and "right" vectors. (It seemes that with some modifications it would be possible to use the vista buffer though — to bee further investigated).

The Stereo Cache datastructure is querried after doing the ray object intersection test. It is utilized only for primary rays, not for transmitted, reflected or refracted rays. The best new intersection found will be compared with cached intersections, the latter beeing used if possible and within certain error bounds (hit tolerance). If no cached intersections were found (maybee because the cached ones were to far off the new intersection point), the new intersection will be fed to cache to be used while tracing the other half image. Cached intersections are stored at the predicted location where they could be used, and they are stored only if calculations on the other half image still have to reach this location. This includes calculating the «stereoscopic deviation» based on angle, depth of intersection and projection geometry.

For every possible sub pixel StereoCache preallocates a slot to hold at most one cache entry. The "best" (i.e. nearest to camera) intersection found is cached. So querrying the cache involves only a small number of slots to be tested, according to the current pixel or sub pixel size. Adaptive supersampling means that the current pixel size is reduced in several recursive steps.

Each cache entry is dedicated to a single ray object intersection point
and holds the following data:
  (a) - Angle of incidence and contribution to the diffuse illumination for each light source.
  (b) - Radiosity contribution
  (c) - Result of Photon gathering for the intersection point
  (d) - Local pigment and normal values of the textur(es) at this point.

StereoCache may either be inactive or operates in "put" (insert data) or "fetch" (get cached data) mode. The StereoCache system at a whole is inactive for all but primary rays. (i.e. it is operative only at trace_level==1). The cached «light list» (a) is used for all lighting calculations at given intersection point. The same holds true for the radiosity and photon contribution (b) and (c), wheras pigment and normal values (d) are different for each texture component or layer. As textures may be defined to arbitrary complexity, StereoCache assumes that for a given, fixed intersection point the evaluation and calculation order of the texture functions will be reproducible. Thus it is sufficient to store a flat list of all texture values encountered while recursivly evaluating the textures and retrieving the cached values in same order.

As this operation scheme continously creates new data blocks to be hold in cache only for a small number of main loop iterations before beeing released, StereoCache maintaines a pool of pre-allocated data blocks to be reused as needed.

StereoCache statistics

When StereoCache is used, it will issue some additional statistics after rendering is finished. A typical example may run as follows:

----------------------------------------------------------------------------
Stereo Cache                    315660          145308     46.03
 Hit vs.new I.                  177516          145308     81.86
 I. fed to cache                170352          155472     91.27
 Cached I. reused               155472          124879     80.32
       reused Intersections avg. 0.93 / 1.16 times (total/succsessfull)
----------------------------------------------------------------------------

The first number is the overall success quote of StereoCache. As the two half images are treated strictly symmetrical, this value can (theoretically) be at most 50%.
If there is a cached intersection found, it has to be compared to the new intersecion and can only be used if it's near enough (hit tolerance). The secound number gives the fraction of cached intersections compared and prefered over new ones.
If there is no cache hit, we try to fed the new intersection to cache. This is possible only if there is a chance left, that the calculations on the other half image can use this intersection. (Third number)
The fourth number counts the cached intersections really reused.
A cached intersection may be reused several times, especially while anti-aliasing. The last number pair keeps track of the average reuse count, the first figure based on the total number of Intersections fed to cache, the second figure based on the count of intersections succsessfully reused.