Difference between revisions of "Reference:Tracing Options"

From POV-Wiki
Jump to navigation Jump to search
m (1 revision: Reference Migration Initial Load)
m (technical correction)
 
(31 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
[[Category:Command-Line and INI-File Options]]
 
[[Category:Command-Line and INI-File Options]]
{{#indexentry:Options, tracing|Options, rendering}}
+
{{#indexentry:Options, tracing}}
 +
{{#indexentry:Options, rendering}}
 
<p>There is more than one way to trace a ray. Sometimes there is a trade-off
 
<p>There is more than one way to trace a ray. Sometimes there is a trade-off
 
between quality and speed. Sometimes options designed to make tracing faster
 
between quality and speed. Sometimes options designed to make tracing faster
Line 6: Line 7:
 
trace rays with the appropriate speed and quality settings.</p>
 
trace rays with the appropriate speed and quality settings.</p>
  
{{#indexentry:Work_Threads|+wt}}
 
 
==Symmetric MultiProcessing==
 
==Symmetric MultiProcessing==
 +
{{#indexentry:Work_Threads}}
 +
{{#indexentry:+wt}}
 
<p>Central to the many feature enhancements offered with version 3.7, POV-Ray now supports Symmetric MultiProcessing or SMP. The command line option <code>Work_Threads=</code><em>n</em> or the <code>+WT</code><em>n</em> switch allows you to specify the number of <em>work threads</em> to be used while rendering a scene. On Windows systems, the default is the number of detected cores. On Linux/Unix and OSX based systems, the default is first based on the number of detected cores, otherwise, the number of configured cores. If detection is not possible the default is set to 4. In <em>all</em> cases the maximum value is 512.</p>
 
<p>Central to the many feature enhancements offered with version 3.7, POV-Ray now supports Symmetric MultiProcessing or SMP. The command line option <code>Work_Threads=</code><em>n</em> or the <code>+WT</code><em>n</em> switch allows you to specify the number of <em>work threads</em> to be used while rendering a scene. On Windows systems, the default is the number of detected cores. On Linux/Unix and OSX based systems, the default is first based on the number of detected cores, otherwise, the number of configured cores. If detection is not possible the default is set to 4. In <em>all</em> cases the maximum value is 512.</p>
  
{{#indexentry:Render_Block_Size|+bs}}
 
 
==Render Block Size==
 
==Render Block Size==
<p>POV-Ray provides a mechanism to specify the render block size via either an INI-style option <code>Render_Block_Size=n</code> or on the command-line <code>+BS</code><em>n</em>, where <em>n</em> is an integer larger than or equal to 4. This represents the edge size of the square used to distribute work to the render threads, and thus the number of pixels in each block will be n squared. The default value is 32. If you specify a value that is greater than the larger of the width or height of the image being rendered, it is clipped to that value. Using render block sizes of less than eight can impact performance, particularly on large images that render quickly, as it significantly increases the amount of message traffic between the render backend and the graphical frontend, which communicate using a shared-memory queue.</p>
+
{{#indexentry:Render_Block_Size}}
 +
{{#indexentry:+bs}}
 +
<p>POV-Ray provides a mechanism to specify the render block size via either an INI-style option <code>Render_Block_Size=n</code> or on the command-line <code>+BS</code><em>n</em>, where <em>n</em> is an integer larger than or equal to 4. This represents the edge size of the square used to distribute work to the render threads, and thus the number of pixels in each block will be n squared. The default value is 32. If you specify a value that is greater than the larger of the width or height of the image being rendered, it is clipped to that value. Using render block sizes of less than eight can impact performance, particularly on large images that render quickly, as it significantly increases the amount of message traffic between the render back-end and the graphical front-end, which communicate using a shared-memory queue.</p>
  
{{#indexentry:Render_Pattern|+rp}}
 
 
===Render Pattern===
 
===Render Pattern===
 +
{{#indexentry:Render_Pattern}}
 +
{{#indexentry:+rp}}
 
<p>POV-Ray provides a mechanism to specify the order of render block via either an INI-style option <code>Render_Pattern</code>=<em>n</em> or on the command-line <code>+RP</code><em>n</em>, where <em>n</em> is an integer between 0 and 5. This represents the various orders for the distribution of the blocks to the render threads. The default value is 0.</p>
 
<p>POV-Ray provides a mechanism to specify the order of render block via either an INI-style option <code>Render_Pattern</code>=<em>n</em> or on the command-line <code>+RP</code><em>n</em>, where <em>n</em> is an integer between 0 and 5. This represents the various orders for the distribution of the blocks to the render threads. The default value is 0.</p>
  
Line 122: Line 126:
 
</table>
 
</table>
  
{{#indexentry:Render_Block_Step|+rs}}
 
 
===Render Block Step===
 
===Render Block Step===
 +
{{#indexentry:Render_Block_Step}}
 +
{{#indexentry:+rs}}
 
<p>Whatever the chosen pattern (with <code>+RP</code>), the number of the next processed block can be incremented by more than 1, to jump over blocks, via either an INI-style option <code>Render_Block_Step</code>=<em>n</em> or on the command-line <code>+RS</code><em>n</em>, where <em>n</em> is a positive non zero integer. The provided value of <em>n</em> gets reduced automatically to a smaller value if the provided value would lead to a situation where the some blocks would not get rendered.</p>
 
<p>Whatever the chosen pattern (with <code>+RP</code>), the number of the next processed block can be incremented by more than 1, to jump over blocks, via either an INI-style option <code>Render_Block_Step</code>=<em>n</em> or on the command-line <code>+RS</code><em>n</em>, where <em>n</em> is a positive non zero integer. The provided value of <em>n</em> gets reduced automatically to a smaller value if the provided value would lead to a situation where the some blocks would not get rendered.</p>
  
Line 201: Line 206:
 
<p>The default is 9 if not specified.</p>
 
<p>The default is 9 if not specified.</p>
  
 +
==Automatic Bounding Control==
 
{{#indexentry:Options, bounding, automatic}}
 
{{#indexentry:Options, bounding, automatic}}
==Automatic Bounding Control==
 
 
<table width="100%" class="option-list">
 
<table width="100%" class="option-list">
 
<tr>
 
<tr>
Line 211: Line 216:
  
 
<tr>
 
<tr>
<td><code>+MB</code>{{#indexentry:+mb}}</td>
+
<td><code>+B</code>{{#indexentry:+mb}}</td>
  
<td>Turn bounding on; Set threshold to 25 or previous amount</td>
+
<td>Turn bounding on; Set threshold to 3 or previous amount</td>
 
</tr>
 
</tr>
  
 
<tr>
 
<tr>
<td><code>-MB</code>{{#indexentry:-mb}}</td>
+
<td><code>-B</code>{{#indexentry:-mb}}</td>
  
 
<td>Turn bounding off</td>
 
<td>Turn bounding off</td>
Line 290: Line 295:
 
The <code> Bounding_Threshold=</code><em>n</em> or <code>
 
The <code> Bounding_Threshold=</code><em>n</em> or <code>
 
+MB</code><em>n</em> switch allows you to set the minimum number of objects
 
+MB</code><em>n</em> switch allows you to set the minimum number of objects
necessary before bounding is used. The default is <code>+MB25</code> which
+
necessary before bounding is used. The default is <code>+MB3</code> which
means that if your scene has fewer than 25 objects POV-Ray will automatically
+
means that if your scene has fewer than 3 objects POV-Ray will automatically
turn bounding off because the overhead is not worth it. Generally it is
+
turn bounding off because the overhead is not worth it.</p>
a good idea to use a much lower threshold like <code>+MB5</code>.</p>
 
<p>
 
Additionally POV-Ray uses systems known as <em>vista buffers</em> and <em>
 
light buffers</em> to further speed things up. These systems only work when
 
bounding is on and when there are a sufficient number of objects to meet the
 
bounding threshold. The vista buffer is created by projecting the bounding
 
box hierarchy onto the screen and determining the rectangular areas that are
 
covered by each of the elements in the hierarchy. Only those objects whose
 
rectangles enclose a given pixel are tested by the primary viewing ray. The
 
vista buffer can only be used with perspective and orthographic cameras
 
because they rely on a fixed viewpoint and a reasonable projection (i. e.
 
straight lines have to stay straight lines after the projection).</p>
 
<p>
 
The light buffer is created by enclosing each light source in an imaginary
 
box and projecting the bounding box hierarchy onto each of its six sides.
 
Since this relies on a fixed light source, light buffers will not be used for
 
area lights.</p>
 
<p>
 
Reflected and transmitted rays do not take advantage of the light and vista
 
buffer.</p>
 
<p>
 
The default settings are <code> Vista_Buffer=on</code> or <code>+UV</code>
 
and <code> Light_Buffer=on</code> or <code>+UL</code>. The option to turn
 
these features off is available to demonstrate their usefulness and as
 
protection against unforeseen bugs which might exist in any of these bounding
 
systems.</p>
 
 
<p>
 
<p>
 
In general, any finite object and many types of CSG of finite objects will
 
In general, any finite object and many types of CSG of finite objects will
Line 331: Line 310:
 
add manual bounding objects as was necessary in earlier versions of POV-Ray
 
add manual bounding objects as was necessary in earlier versions of POV-Ray
 
unless you use many infinite objects.</p>
 
unless you use many infinite objects.</p>
 +
<p class="Note"><strong>Note:</strong>
 +
As of version 3.7 the <code>Vista_Buffer</code> and <code>Light_Buffer</code> options have been deprecated.</p>
  
 +
==Removing User Bounding==
 
{{#indexentry:Options, bounding, manual}}
 
{{#indexentry:Options, bounding, manual}}
==Removing User Bounding==
 
 
<table width="100%" class="option-list">
 
<table width="100%" class="option-list">
 
<tr>
 
<tr>
Line 394: Line 375:
 
<code>Split_Unions=off</code>.</p>
 
<code>Split_Unions=off</code>.</p>
  
 +
==BSP Bounding==
 
{{#indexentry:Options, bounding, BSP}}
 
{{#indexentry:Options, bounding, BSP}}
==BSP Bounding==
+
{{#indexentry:Binary Space Partitioning}}
 +
{{#indexentry:BSP}}
 +
{{#indexentry:Options, +BM1}}
 +
{{#indexentry:Options, +BM2}}
 
<p>BSP (Binary Space Partitioning) tree bounding is now available. To turn it on use <code>+BM2</code> or <code>Bounding_Method=2</code> in the INI file or on the command-line. When it is in use you will get some additional statistics in the output pane regarding the built tree.</p>
 
<p>BSP (Binary Space Partitioning) tree bounding is now available. To turn it on use <code>+BM2</code> or <code>Bounding_Method=2</code> in the INI file or on the command-line. When it is in use you will get some additional statistics in the output pane regarding the built tree.</p>
 
<p>Please keep in mind that this implementation of BSP is highly beta and will not speed up scenes in many cases (and in fact may slow some down). In particular the building of the tree can take a long time and lots of memory in severe cases. Using the BSP tree rather than our traditional BVH (Bounding Volume Hierarchy) system (default or <code>+BM1</code>) is a choice best made for specific scenes that will benefit from the way the BSP operates, and in particular if the render is long enough to offset the build time. The BSP tree build time will be constant for a given scene and set of BSP parameters, regardless of the output resolution. A 30-second BSP build may not be a good choice on a 60-second test render but may be acceptable for a 60-minute final render if the use of BSP adds a few pixels per second.</p>
 
<p>Please keep in mind that this implementation of BSP is highly beta and will not speed up scenes in many cases (and in fact may slow some down). In particular the building of the tree can take a long time and lots of memory in severe cases. Using the BSP tree rather than our traditional BVH (Bounding Volume Hierarchy) system (default or <code>+BM1</code>) is a choice best made for specific scenes that will benefit from the way the BSP operates, and in particular if the render is long enough to offset the build time. The BSP tree build time will be constant for a given scene and set of BSP parameters, regardless of the output resolution. A 30-second BSP build may not be a good choice on a 60-second test render but may be acceptable for a 60-minute final render if the use of BSP adds a few pixels per second.</p>
 
<p>On some scenes the difference however will be dramatic, with short build times and radically increased render speed.</p>
 
<p>On some scenes the difference however will be dramatic, with short build times and radically increased render speed.</p>
 
<p>We have provided some BSP-related options via the INI file and encourage you to experiment with them to see if you can get better results than the default values built in to POV-Ray. We will listen to feedback from this and if necessary tweak the defaults.</p>
 
<p>We have provided some BSP-related options via the INI file and encourage you to experiment with them to see if you can get better results than the default values built in to POV-Ray. We will listen to feedback from this and if necessary tweak the defaults.</p>
<p class="Note"><strong>Note:</strong> We do not guarantee that all of the following INI file settings will remain in the final release of 3.7</p>
+
<p class="Note"><strong>Note:</strong> We do not guarantee that all of the following INI file settings will remain in future releases.</p>
 
<pre>
 
<pre>
 
   BSP_MaxDepth=128
 
   BSP_MaxDepth=128
Line 408: Line 393:
 
   BSP_MissChance=0.2
 
   BSP_MissChance=0.2
 
</pre>
 
</pre>
<p>The values shown above are the default. You can also get the defaults if you use a value of 0 for any of the above, or of course just by not specifying the option at all. For an explanation of what the values mean you may refer to Ray Tracing News [http://tog.acm.org/resources/RTNews/html/rtnv17n1.html#art8 article] by Eric Haines.</p>
+
<p>The values shown above are the default. You can also get the defaults if you use a value of 0 for any of the above, or of course just by not specifying the option at all. For an explanation of what the values mean you may refer to Ray Tracing News [http://www.realtimerendering.com/resources/RTNews/html/rtnv17n1.html#art8 article] by Eric Haines.</p>
 
<p>See the distribution file <code>~scenes/bsp/Tango.pov</code> for a good example of a scene that benefits from the BSP bounding.</p>
 
<p>See the distribution file <code>~scenes/bsp/Tango.pov</code> for a good example of a scene that benefits from the BSP bounding.</p>
 
<p>Tango.pov rendered at 800x600, no AA</p>
 
<p>Tango.pov rendered at 800x600, no AA</p>
Line 416: Line 401:
 
</ul>
 
</ul>
  
 +
==Stochastic Seed==
 +
{{#indexentry:Options, stochastic_seed}}
 +
<table width="100%" class="option-list">
 +
<tr>
 +
<td width="30%"><code>Stochastic_Seed=</code>n{{#indexentry:Stochastic_Seed, ini-option}}</td>
 +
<td width="70%">Sets a value for the stochastic seed {{New}} in version 3.8</td>
 +
</tr>
 +
 +
<tr>
 +
<td><code>+SS</code>n{{#indexentry:+ss}}</td>
 +
<td>Same as <code>Stochastic_Seed=</code>n</td>
 +
</tr>
 +
</table>
 +
<p>By default some stochastic mechanisms in POV-Ray intentionally give different results for each render, with the intent that multiple renders can be averaged to get a higher-quality image. To this end, the corresponding pseudo-random number generators are seeded with a value
 +
derived from the current date and time.</p>
 +
<p>If the <code>Stochastic_Seed=</code>n or <code>+SS</code>n option is specified, the seed will instead be derived from the specified value, allowing to produce exactly the same output each time by specifying that same value. Alternatively, the mechanism may be co-opted to prevent separate renders started at the same time from producing identical results, by explicitly specifying different values.</p>
 +
<p class="Note"><strong>Note:</strong> Even if the seed is set identically, other factors may cause differences in the result. For example the render block size <code>+BS</code>n or the render pattern <code>+RP</code>n options. Results may also differ between versions of POV-Ray.</p>
 +
<p>Presently anti-aliasing sampling method 3 is the only feature that is sensitive to the stochastic seed setting.</p>
 +
 +
==Anti-Aliasing Options==
 
{{#indexentry:Options, anti-aliasing}}
 
{{#indexentry:Options, anti-aliasing}}
==Anti-Aliasing Options==
 
 
<table width="100%" class="option-list">
 
<table width="100%" class="option-list">
 
<tr>
 
<tr>
Line 436: Line 440:
 
<tr>
 
<tr>
 
<td><code>Sampling_Method=</code>n{{#indexentry:Sampling_Method, ini-option}}</td>
 
<td><code>Sampling_Method=</code>n{{#indexentry:Sampling_Method, ini-option}}</td>
<td>Sets aa-sampling method (only <code>1</code> or <code>2</code> are
+
<td>Sets aa-sampling method (either <code>1</code>, <code>2</code> or <code>3</code> the later is {{New}} in version 3.8 )</td>
valid)</td>
 
 
</tr>
 
</tr>
  
Line 489: Line 492:
 
<td><code>-J</code>n.n</td>
 
<td><code>-J</code>n.n</td>
 
<td>Sets aa-jitter off (jitter amount n.n in future)</td>
 
<td>Sets aa-jitter off (jitter amount n.n in future)</td>
 +
</tr>
 +
 +
<tr>
 +
<td><code>Antialias_Confidence=</code>n.n{{#indexentry:Antialias_Confidence, ini-option}}</td>
 +
<td>Sets method <code>3</code> <em>confidence</em> to n.n {{New}} in version 3.8</td>
 +
</tr>
 +
 +
<tr>
 +
<td><code>+AC</code>n.n{{#indexentry:+ac}}</td>
 +
<td>Same as <code>Antialias_Confidence=</code>n.n {{New}} in version 3.8</td>
 
</tr>
 
</tr>
  
Line 513: Line 526:
  
 
<p>The ray-tracing process is in effect a discrete, digital sampling of the image with typically one sample per pixel. Such sampling can introduce a variety of errors. This includes a jagged, stair-step appearance in sloping or curved lines, a broken look for thin lines, moir&eacute; patterns of interference and lost detail or missing objects, which are so small they reside between adjacent pixels. The effect that is responsible for those errors is called <em>aliasing</em>.</p>
 
<p>The ray-tracing process is in effect a discrete, digital sampling of the image with typically one sample per pixel. Such sampling can introduce a variety of errors. This includes a jagged, stair-step appearance in sloping or curved lines, a broken look for thin lines, moir&eacute; patterns of interference and lost detail or missing objects, which are so small they reside between adjacent pixels. The effect that is responsible for those errors is called <em>aliasing</em>.</p>
<p>Anti-aliasing is any technique used to help eliminate such errors or to reduce the negative impact they have on the image. In general, anti-aliasing makes the ray-traced image look <em> smoother</em>. The <code>Antialias=on</code> option or <code>+A</code> switch turns on POV-Ray's anti-aliasing system.</p>
+
<p>Anti-aliasing is any technique used to help eliminate such errors or to reduce the negative impact they have on the image. In general, anti-aliasing makes the ray-traced image look <em> smoother</em>. The <code>Antialias=on</code> option or <code>+A</code> option turns on POV-Ray's anti-aliasing system.</p>
 
<p>When anti-aliasing is turned on, POV-Ray attempts to reduce the errors by shooting more than one viewing ray into each pixel and averaging the results to determine the pixel's apparent color. This technique is called super-sampling and can improve the appearance of the final image but it drastically increases the time required to render a scene since many more calculations have to be done.</p>
 
<p>When anti-aliasing is turned on, POV-Ray attempts to reduce the errors by shooting more than one viewing ray into each pixel and averaging the results to determine the pixel's apparent color. This technique is called super-sampling and can improve the appearance of the final image but it drastically increases the time required to render a scene since many more calculations have to be done.</p>
<p>POV-Ray gives you the option to use one of two alternate super-sampling methods. The <code> Sampling_Method=</code><em>n</em> option or <code>+AM</code><em>n</em> switch selects either type <code>1</code> or type <code>2</code>. Selecting one of those methods does not turn anti-aliasing on. This has to be done by using the <code>+A</code> command line switch or <code>Antialias=on</code> option.</p>
+
<p>POV-Ray gives you the option to use one of three sampling methods. Two alternate super-sampling methods and one over-sampling method. The <code>Sampling_Method=</code><em>n</em> option or <code>+AM</code><em>n</em> option selects either type <code>1</code>, type <code>2</code> or type <code>3</code>. Selecting one of those methods does not turn on anti-aliasing. This has to be done by using the <code>+A</code> command line option or <code>Antialias=on</code> option.</p>
<p>Type 1 is an adaptive, non-recursive, super-sampling method. It is <em>adaptive</em> because not every pixel is super-sampled. Type 2 is an adaptive and recursive super-sampling method. It is <em>recursive</em> because the pixel is sub-divided and sub-sub-divided recursively. The <em>adaptive</em> nature of type 2 is the variable depth of recursion.</p>
+
 
<p>In the default, non-recursive method (<code>+AM1</code>), POV-Ray initially traces one ray per pixel. If the color of a pixel differs from its neighbors (to the left or above) by at least the set threshold value then the pixel is super-sampled by shooting a given, fixed number of additional rays. The default threshold is 0.3 but it may be changed using the <code>Antialias_Threshold=</code><em>n.n</em> option. When the switches are used, the threshold may optionally follow the <code>+A</code>. For example <code>+A0.1</code> turns anti-aliasing on and sets the threshold to 0.1.</p>
+
===Sampling Methods Synopsis===
 +
<ul>
 +
  <li>Type 1: an adaptive non-recursive super-sampling method. It is <em>adaptive</em> because not every pixel is super-sampled</li>
 +
  <li>Type 2: an adaptive <em>and</em> recursive super-sampling method. It is <em>recursive</em> because the pixel is sub-divided recursively. The <em>adaptive</em> nature of type 2 is the variable recursion depth</li>
 +
  <li>Type 3: an adaptive non-recursive stochastic oversampling method. The <em>adaptive</em> nature of type 3 is <em>confidence</em> and <em>threshold</em></li>
 +
</ul>
 +
 
 +
===Sampling Method 1===
 +
<p><code>+AM1</code> is an adaptive non-recursive method. If anti-aliasing is enabled it is the default. POV-Ray initially traces one ray per pixel. If the color of a pixel differs from its neighbors (to the left or above) by at least the set threshold value then the pixel is super-sampled by shooting a given, fixed number of additional rays. The default threshold is 0.3 but it may be changed using the <code>Antialias_Threshold=</code><em>n.n</em> option. When the switches are used, the threshold may optionally follow the <code>+A</code>. For example <code>+A0.1</code> turns anti-aliasing on and sets the threshold to 0.1.</p>
 
<p>The threshold comparison is computed as follows. If r1, g1, b1 and r2, g2, b2 are the rgb components of two pixels then the difference between pixels is computed by</p>
 
<p>The threshold comparison is computed as follows. If r1, g1, b1 and r2, g2, b2 are the rgb components of two pixels then the difference between pixels is computed by</p>
 
<pre>
 
<pre>
Line 524: Line 545:
 
<p>If this difference is greater than the threshold then both pixels are super-sampled. The rgb values are in the range from 0.0 to 1.0 thus the most two pixels can differ is 3.0. If the anti-aliasing threshold is 0.0 then every pixel is super-sampled. If the threshold is 3.0 then no anti-aliasing is done. Lower threshold means more anti-aliasing and less speed. Use anti-aliasing for your final version of a picture, not the rough draft. The lower the contrast, the lower the threshold should be. Higher contrast pictures can get away with higher tolerance values. Good values seem to be around 0.2 to 0.4.</p>
 
<p>If this difference is greater than the threshold then both pixels are super-sampled. The rgb values are in the range from 0.0 to 1.0 thus the most two pixels can differ is 3.0. If the anti-aliasing threshold is 0.0 then every pixel is super-sampled. If the threshold is 3.0 then no anti-aliasing is done. Lower threshold means more anti-aliasing and less speed. Use anti-aliasing for your final version of a picture, not the rough draft. The lower the contrast, the lower the threshold should be. Higher contrast pictures can get away with higher tolerance values. Good values seem to be around 0.2 to 0.4.</p>
 
<p>When using the non-recursive method, the default number of super-samples is nine per pixel, located on a 3*3 grid. The <code>
 
<p>When using the non-recursive method, the default number of super-samples is nine per pixel, located on a 3*3 grid. The <code>
Antialias_Depth=</code><em>n</em> option or <code> +R</code><em>n</em> switch controls the number of rows and columns of samples taken for a super-sampled pixel. For example <code>+R4</code> would give 4*4=16 samples per pixel.</p>
+
Antialias_Depth=</code><em>n</em> option or <code>+R</code><em>n</em> option controls the number of rows and columns of samples taken for a super-sampled pixel. For example <code>+R4</code> would give 4*4=16 samples per pixel.</p>
<p>The second, adaptive, recursive super-sampling method starts by tracing four rays at the corners of each pixel. If the resulting colors differ more than the threshold amount additional samples will be taken. This is done recursively, i.e. the pixel is divided into four sub-pixels that are separately traced and tested for further subdivision. The advantage of this method is the reduced number of rays that have to be traced. Samples that are common among adjacent pixels and sub-pixels are stored and reused to avoid re-tracing of rays. The recursive character of this method makes the super-sampling concentrate on those parts of the pixel that are more likely to need super-sampling (see figure below).</p>
+
 
 +
===Sampling Method 2===
 +
<p><code>+AM2</code> is an adaptive, recursive super-sampling method. It starts by tracing four rays at the corners of each pixel. If the resulting colors differ more than the threshold amount additional samples will be taken. This is done recursively, i.e. the pixel is divided into four sub-pixels that are separately traced and tested for further subdivision. The advantage of this method is the reduced number of rays that have to be traced. Samples that are common among adjacent pixels and sub-pixels are stored and reused to avoid re-tracing of rays. The recursive character of this method makes the super-sampling concentrate on those parts of the pixel that are more likely to need super-sampling (see figure below).</p>
  
 
<table class="centered" width="622px" cellpadding="0" cellspacing="10">
 
<table class="centered" width="622px" cellpadding="0" cellspacing="10">
Line 538: Line 561:
 
</table>
 
</table>
  
<p>The maximum number of subdivisions is specified by the <code>Antialias_Depth=</code><em>n</em> option or <code>+R</code><em>n</em> switch. This is different from the adaptive, non-recursive method where the total number of super-samples is specified. A maximum number of <em>n</em> subdivisions results in a maximum number of samples per pixel that is given by the following table. Where the first column represents anti-alias depth or <code>+R</code><em>n</em> option. The second column is the number of additional samples per super-sampled pixel for the non-recursive method <code>+AM1</code>. Lastly the third column is the maximum number of samples per super-sampled pixel for the recursive method <code>+AM2</code>.</p>
+
<p>The maximum number of subdivisions is specified by the <code>Antialias_Depth=</code><em>n</em> option or <code>+R</code><em>n</em> option. This is different from the adaptive, non-recursive method where the total number of super-samples is specified. A maximum number of <em>n</em> subdivisions results in a maximum number of samples per pixel that is given by the following table. Where the first column represents anti-alias depth or <code>+R</code><em>n</em> option. The second column is the number of additional samples per super-sampled pixel for the non-recursive method <code>+AM1</code>. Lastly the third column is the maximum number of samples per super-sampled pixel for the recursive method <code>+AM2</code>.</p>
  
 
<table width="50%">
 
<table width="50%">
Line 596: Line 619:
 
</table>
 
</table>
  
<p class="Note"><strong>Note:</strong> The maximum number of samples in the recursive case is hardly ever reached for a given pixel. If the recursive method is used with no anti-aliasing each pixel will be the average of the rays traced at its corners. In most cases a recursion level of three is sufficient.</p>
+
<p class="Note"><strong>Note:</strong> The maximum number of samples in the recursive case is hardly ever reached for a given pixel. If the recursive method is used and the anti-aliasing threshold is not reached, each pixel will be the average of the rays traced at its corners. In others words, you get the average of those four pixels with no further sub-sampling. In most cases a recursion level of three is sufficient.</p>
<p>Another way to reduce aliasing artifacts is to introduce noise into the sampling process. This is called <em>jittering</em> and works because the human visual system is much more forgiving to noise than it is to regular patterns. The location of the super-samples is jittered or wiggled a tiny amount when anti-aliasing is used. Jittering is used by default but it may be turned off with the <code>Jitter=off</code> option or <code>-J</code> switch. The amount of jittering can be set with the <code>Jitter_Amount=</code><em>n.n</em> option. When using switches the jitter scale may be specified after the <code>+J</code><em>n.n</em> switch. For example <code>+J0.5</code> uses half the normal jitter. The default amount of 1.0 is the maximum jitter which will insure that all super-samples remain inside the original pixel. </p>
+
 
 +
===Sampling Method 3===
 +
<p><code>+AM3</code> is {{New}} in version 3.8 and it's an adaptive, non-recursive stochastic oversampling method. This method repeatedly iterates over the pixels to be rendered, jittering each ray randomly within the pixel on each pass, while keeping track of statistical parameters such as average color and mean deviation. On subsequent passes, the algorithm ceases to over-sample pixels where the
 +
statistical parameters for the pixel itself and its immediate four neighbors indicate that the result is <em>probably</em> good enough.</p>
 +
<p>What constitutes <em>probably</em> good enough is determined by a <em>confidence</em> parameter specified by the <code>Antialias_Confidence=</code>n.n or <code>+AC</code>n.n option, as well as a <em>threshold</em> parameter specified by the <code>Antialias_Threshold=</code>n.n or <code>+A</code>n.n option.</p>
 +
<p>The <em>threshold</em> determines what absolute sampling error (i.e. difference between the computed pixel color and the theoretically correct one) you consider acceptable, while the <em>confidence</em> specifies how sure you want to be that a pixel that <em>seems</em> acceptable actually <em>is</em> acceptable. In effect, this determines how many pixels in the resulting image <em>will</em> indeed be acceptable. For example, if you specify a confidence of 0.95, then you can expect approximately 95% of all pixels to be within the threshold, as compared to a theoretically correct image. Of the remaining ones, many will be off by slightly more than the threshold, while only few will be significantly off. Extreme outlines are possible but extremely unlikely.</p>
 +
<p>Recommended values are a <em>threshold</em> of 0.3 or lower, and a <em>confidence</em> of 0.9 or higher. They are the defaults.</p>
 +
<p>The total number of rays shot per pixel is limited by the <code>Antialias_Depth=</code>n or <code>+R</code>n parameter. As with the other methods the parameter is limited to the range from 1 to 9, with the actual maximum number of rays per pixel being 4<sup>n</sup>.</p>
 +
<p>By default, the sub-pixel jittering is different for each render, thus giving slightly different results, with the intent that multiple renders can be averaged to get a higher-quality image. Conversely you can produce exactly the same output each time. See also: [[Reference:Tracing Options#Stochastic Seed|Stochastic Seed]]</p>
 +
<p class="Note"><strong>Note:</strong> The jitter sequence is also affected by the actual image content, and will thus always differ between the frames of an animation.</p>
 +
<p>Since oversampling method 3 is a very generic adaptive oversampling algorithm, its performance in pure edge anti-aliasing is generally inferior to the other methods, however it is ideally suited to suppress random image noise created by other stochastic mechanisms, such as
 +
jittered area lights, subsurface light transport, or micro-normals based blurred reflections. It has also proven well-suited for eliminating moir&eacute; patterns.</p>
 +
 
 +
===Common Properties===
 +
<p>Another way to reduce anti-aliasing artifacts is to introduce noise into the sampling process. This is called <em>jittering</em> and works because the human visual system is much more forgiving to noise than it is to regular patterns. It is <em>inherent</em> to anti-aliasing method 3 because it <em>always</em> uses a constant amount of jitter. When using one of the other methods the location of the super-samples is also jittered or wiggled a tiny amount by default. Alternately it may be turned off with the <code>Jitter=off</code> option or <code>-J</code> option. The amount of jittering can be set with the <code>Jitter_Amount=</code>n.n option. When using those options the jitter scale may be specified after the <code>+J</code>n.n option. For example <code>+J0.5</code> uses half the normal jitter. The default amount of 1.0 is the maximum jitter which will insure that all super-samples remain inside the original pixel. </p>
 
<p class="Note"><strong>Note:</strong> The jittering noise is random and non-repeatable so you should avoid using jitter in animation sequences as the anti-aliased pixels will vary and flicker annoyingly from frame to frame.</p>
 
<p class="Note"><strong>Note:</strong> The jittering noise is random and non-repeatable so you should avoid using jitter in animation sequences as the anti-aliased pixels will vary and flicker annoyingly from frame to frame.</p>
 
<p>If anti-aliasing is not used one sample per pixel is taken regardless of the super-sampling method specified.</p>
 
<p>If anti-aliasing is not used one sample per pixel is taken regardless of the super-sampling method specified.</p>
<p>As the human eye is more sensitive to absolute brightness differences at a low overall brigtness than at higher ones, super-sampling based on linear light intensity differences would yield either poor anti-aliasing in darker regions, or unnecessary super-sampling in brighter regions of the image. To avoid this, POV-Ray compares ''gamma-adjusted'' values instead. (Note that this only affects the comparison operation; the averaging of the super-samples is done in whatever <em>working color space</em> is specified in the scene file via the <code>assumed_gamma</code> keyword.) The <code>Antialias_Gamma=</code><em>n.n</em> command line option or <code>+AG</code><em>n.n</em> sets the gamma to apply before comparison, defaulting to 2.5. Note that the value is actually the inverse of the gamma applied, in order to use the same value range as the display and file gamma settings. Neutral behavior can be achieved using <code>Antialias_Gamma=1.0</code></p>
+
<p>As the human eye is more sensitive to absolute brightness differences at a low overall brigtness than at higher ones, super-sampling based on linear light intensity differences would yield either poor anti-aliasing in darker regions, or unnecessary super-sampling in brighter regions of the image. To avoid this, POV-Ray compares <em>gamma-adjusted</em> values instead.</p>
<p class="Note"><strong>Note:</strong> The <code>[[Reference:Camera#Mesh_projection|mesh_camera]]</code> feature added in version 3.7 also makes extreme super-sampling possible.  See the distribution file <code>~scenes/camera/mesh_camera/ess/README.txt</code> for additional information.</p>
+
<p class="Note"><strong>Note:</strong> This only affects the comparison operation. The averaging of the super-samples is done in whatever <em>working color space</em> is specified in the scene file via the <code>assumed_gamma</code> keyword.</p>
 +
<p>The <code>Antialias_Gamma=</code>n.n command line option or <code>+AG</code>n.n sets the gamma to apply before comparison. The default is 2.5. This value is actually the inverse of the gamma applied, in order to use the same value range as the display and file gamma settings. If the image contains an alpha channel, that channel will <em>also</em> be considered in the comparisons, like the color channels, except that unlike the other channels it is <em>not</em> subject to <code>Antialias_Gamma</code>. Neutral behavior can be achieved using <code>Antialias_Gamma=1.0</code></p>
 +
<p class="Note"><strong>Note:</strong> The <code>[[Reference:Camera#Mesh projection|mesh_camera]]</code> feature added in version 3.7 also makes extreme super-sampling possible.  See the distribution file <code>~scenes/camera/mesh_camera/ess/README.txt</code> for additional information.</p>
  
 +
==Radiosity Options==
 
{{#indexentry:Options, radiosity}}
 
{{#indexentry:Options, radiosity}}
==Radiosity Options==
+
 
 
===Radiosity High Reproducibility===
 
===Radiosity High Reproducibility===
<p>As of version 3.7 a new radiosity mode has been introduced. When specifying <code>High_Reproducibility</code> or <code>+HR</code> on the command line, POV-Ray will spend extra effort to make sure renders are deterministic despite SMP (currently, radiosity is the only code to use this flag; in HR mode, radiosity pretrace starts out with fewer threads, and some extra rules are imposed on sample re-use that may cause surplus samples to be gathered).</p>
+
<p>As of version 3.7 a new radiosity mode has been introduced. When specifying <code>High_Reproducibility</code> or <code>+HR</code> on the command line, POV-Ray will spend extra effort to make sure renders are deterministic despite SMP. Currently radiosity is the only code to use this flag; in <code>+HR</code> mode, radiosity pretrace starts out with fewer threads, and some extra rules are imposed on sample re-use that may cause surplus samples to be gathered.</p>
 +
<p class="Note"><strong>Note:</strong> The <em>high reproducibility</em> mode is not intended for use with radiosity alone, and it will need more work to guarantee the same improved reproducibility in other features. Even though it works well with radiosity, this addition is still <em>experimental</em>.</p>
  
 
===Radiosity Load and Save===
 
===Radiosity Load and Save===
Line 620: Line 661:
  
 
===Radiosity Vain Pretrace===
 
===Radiosity Vain Pretrace===
<p>Also new as of version 3.7 an option has been added speed up radiosity pretrace:</p>
+
<p>Also new as of version 3.7 an option has been added to speed up radiosity pretrace:</p>
 
<p>As some computations don't contribute to the generation of radiosity samples, they can safely be skipped during radiosity pretrace to gain some speed if the pretrace's other role as a coarse preview is not required.</p>
 
<p>As some computations don't contribute to the generation of radiosity samples, they can safely be skipped during radiosity pretrace to gain some speed if the pretrace's other role as a coarse preview is not required.</p>
 
<p>The following .ini file/command line options control whether pretrace performs all computations so it can double-feature as a coarse preview  (vain pretrace):</p>
 
<p>The following .ini file/command line options control whether pretrace performs all computations so it can double-feature as a coarse preview  (vain pretrace):</p>
Line 629: Line 670:
 
</pre>
 
</pre>
 
<p class="Note"><strong>Note:</strong> With vain pretrace off, preview will look remarkably odd during the radiosity pretrace phase; this is normal, and no reason to be alarmed.</p>
 
<p class="Note"><strong>Note:</strong> With vain pretrace off, preview will look remarkably odd during the radiosity pretrace phase; this is normal, and no reason to be alarmed.</p>
<p>At the moment, turning vain pretrace off will affect only classic lighting computations (diffuse lighting, higlights and iridescence); other features expendable during pretrace may follow in future versions.</p>
+
<p>At the moment, turning vain pretrace off will affect only classic lighting computations (diffuse lighting, highlights and iridescence); other features expendable during pretrace may follow in future versions.</p>

Latest revision as of 13:21, 27 July 2020

There is more than one way to trace a ray. Sometimes there is a trade-off between quality and speed. Sometimes options designed to make tracing faster can slow things down. This section covers options that tell POV-Ray how to trace rays with the appropriate speed and quality settings.

Symmetric MultiProcessing

Central to the many feature enhancements offered with version 3.7, POV-Ray now supports Symmetric MultiProcessing or SMP. The command line option Work_Threads=n or the +WTn switch allows you to specify the number of work threads to be used while rendering a scene. On Windows systems, the default is the number of detected cores. On Linux/Unix and OSX based systems, the default is first based on the number of detected cores, otherwise, the number of configured cores. If detection is not possible the default is set to 4. In all cases the maximum value is 512.

Render Block Size

POV-Ray provides a mechanism to specify the render block size via either an INI-style option Render_Block_Size=n or on the command-line +BSn, where n is an integer larger than or equal to 4. This represents the edge size of the square used to distribute work to the render threads, and thus the number of pixels in each block will be n squared. The default value is 32. If you specify a value that is greater than the larger of the width or height of the image being rendered, it is clipped to that value. Using render block sizes of less than eight can impact performance, particularly on large images that render quickly, as it significantly increases the amount of message traffic between the render back-end and the graphical front-end, which communicate using a shared-memory queue.

Render Pattern

POV-Ray provides a mechanism to specify the order of render block via either an INI-style option Render_Pattern=n or on the command-line +RPn, where n is an integer between 0 and 5. This represents the various orders for the distribution of the blocks to the render threads. The default value is 0.

If you specify a value that is greater than the maximum number of patterns, it will revert to the default. Using a different Render_Pattern has only an effect on the preview of the rendered image, as the first blocks might be placed differently, but does not change the final image once the render has been completed.

RefImgRenderPatternRo0.png

Pattern 0: is the classical order. The first block is in the top left corner, and it progress from left to right, and then it continues on the next row of blocks. Just like reading text.

Pattern 0

Pattern 1: is the same as pattern 0, but the rows and columns are swapped. It starts at the top left corner and it progress from top to bottom.

RefImgRenderPatternRo1.png

Pattern 1

RefImgRenderPatternRo2.png

Pattern 2: The top row is processed first, starting at each corner and meeting at the center of the row, then the bottom row is processed the same way. The last block is at the very center of the image.

Pattern 2

Pattern 3: Is the opposite order of pattern 2, the first block is at the center of the image, the expansion being firstly horizontal.

RefImgRenderPatternRo3.png

Pattern 3

RefImgRenderPatternRo4.png

Pattern 4: Is the same as pattern 2, except that the rows and columns have been swapped.

Pattern 4

Pattern 5: Is the same as pattern 3, but the rows and columns are swapped, however the expansion from the center of the image is firstly vertical.

RefImgRenderPatternRo5.png

Pattern 5

Render Block Step

Whatever the chosen pattern (with +RP), the number of the next processed block can be incremented by more than 1, to jump over blocks, via either an INI-style option Render_Block_Step=n or on the command-line +RSn, where n is a positive non zero integer. The provided value of n gets reduced automatically to a smaller value if the provided value would lead to a situation where the some blocks would not get rendered.

Assuming an image made of 40 blocks, with +RS9, the order of block numbers would be:

0, 9, 18, 27, 36, 5, 14, 23, 32, 1, 10, 19, 28, 37, 6, 15, 24, 33, 2, 11, 20, 29, 38, 7, 16, 25, 34, 3, 12, 21, 30, 39, 8, 17, 26, 35, 4, 13, 22, 31.

The same 40 blocks with +RS8 would in fact use +RS7 instead. As would a +RS2 in fact be reduced to +RS1 the default.

Quality Settings

Quality=n
Set quality value to n (0 <= n <= 11)
+Qn
Same as Quality=n

The Quality=n option or +Qn switch allows you to specify the image rendering quality. You may choose to lower the quality for test rendering and raise it for final renders. The quality adjustments are made by eliminating some of the calculations that are normally performed. For example settings below 4 do not render shadows. Settings below 8 do not use reflection or refraction. The duplicate values allow for future expansion. The values correspond to the following quality levels:

0, 1 Just show quick colors. Use full ambient lighting only. Quick colors are used only at 5 or below.
2, 3 Show specified diffuse and ambient light.
4 Render shadows, but no extended lights.
5 Render shadows, including extended lights.
6, 7 Compute texture patterns, compute photons
8 Compute reflected, refracted, and transmitted rays.
9, 10, 11 Compute media, radiosity and subsurface light transport.

The default is 9 if not specified.

Automatic Bounding Control

Bounding=bool
Turn bounding on/off
+B
Turn bounding on; Set threshold to 3 or previous amount
-B
Turn bounding off
Bounding_Threshold=n
Set bound threshold to n
+MBn Turn bounding on; bound threshold to n
-MBn Turn bounding off; set future threshold to n
Light_Buffer=bool
Turn light buffer on/off
+UL
Turn light buffer on
-UL
Turn light buffer off
Vista_Buffer=bool
Turn vista buffer on/off
+UV
Turn vista buffer on
-UV
Turn vista buffer off

POV-Ray uses a variety of spatial sub-division systems to speed up ray-object intersection tests. The primary system uses a hierarchy of nested bounding boxes. This system compartmentalizes all finite objects in a scene into invisible rectangular boxes that are arranged in a tree-like hierarchy. Before testing the objects within the bounding boxes the tree is descended and only those objects are tested whose bounds are hit by a ray. This can greatly improve rendering speed. However for scenes with only a few objects the overhead of using a bounding system is not worth the effort. The Bounding=off option or -MB switch allows you to force bounding off. The default value is on.

The Bounding_Threshold=n or +MBn switch allows you to set the minimum number of objects necessary before bounding is used. The default is +MB3 which means that if your scene has fewer than 3 objects POV-Ray will automatically turn bounding off because the overhead is not worth it.

In general, any finite object and many types of CSG of finite objects will properly respond to this bounding system. In addition blobs and meshes use an additional internal bounding system. These systems are not affected by the above switch. They can be switched off using the appropriate syntax in the scene file (see Blob and Mesh for details).

Text objects are split into individual letters that are bounded using the bounding box hierarchy. Some CSG combinations of finite and infinite objects are also automatically bound. The end result is that you will rarely need to add manual bounding objects as was necessary in earlier versions of POV-Ray unless you use many infinite objects.

Note: As of version 3.7 the Vista_Buffer and Light_Buffer options have been deprecated.

Removing User Bounding

Remove_Bounds=bool
Turn unnecessary bounds removal on/off
+UR
Turn unnecessary bounds removal on
-UR
Turn unnecessary bounds removal off
Split_Unions=bool
Turn split bounded unions on/off
+SU
Turn split bounded unions on
-SU
Turn split bounded unions off

Early versions of POV-Ray had no system of automatic bounding or spatial sub-division to speed up ray-object intersection tests. Users had to manually create bounding boxes to speed up the rendering. Since version 3.0, POV-Ray has had more sophisticated automatic bounding than any previous version. In many cases the manual bounding on older scenes is slower than the new automatic systems. Therefore POV-Ray removes manual bounding when it knows it will help. In rare instances you may want to keep manual bounding. Some older scenes incorrectly used bounding when they should have used clipping. If POV-Ray removes the bounds in these scenes the image will not look right. To turn off the automatic removal of manual bounds you should specify Remove_Bounds=off or use -UR. The default is Remove_Bounds=on.

One area where the jury is still out is the splitting of manually bounded unions. Unbounded unions are always split into their component parts so that automatic bounding works better. Most users do not bound unions because they know that doing so is usually slower. If you do manually bound a union we presume you really want it bound. For safety sake we do not presume to remove such bounds. If you want to remove manual bounds from unions you should specify Split_Unions=on or use +SU. The default is Split_Unions=off.

BSP Bounding

BSP (Binary Space Partitioning) tree bounding is now available. To turn it on use +BM2 or Bounding_Method=2 in the INI file or on the command-line. When it is in use you will get some additional statistics in the output pane regarding the built tree.

Please keep in mind that this implementation of BSP is highly beta and will not speed up scenes in many cases (and in fact may slow some down). In particular the building of the tree can take a long time and lots of memory in severe cases. Using the BSP tree rather than our traditional BVH (Bounding Volume Hierarchy) system (default or +BM1) is a choice best made for specific scenes that will benefit from the way the BSP operates, and in particular if the render is long enough to offset the build time. The BSP tree build time will be constant for a given scene and set of BSP parameters, regardless of the output resolution. A 30-second BSP build may not be a good choice on a 60-second test render but may be acceptable for a 60-minute final render if the use of BSP adds a few pixels per second.

On some scenes the difference however will be dramatic, with short build times and radically increased render speed.

We have provided some BSP-related options via the INI file and encourage you to experiment with them to see if you can get better results than the default values built in to POV-Ray. We will listen to feedback from this and if necessary tweak the defaults.

Note: We do not guarantee that all of the following INI file settings will remain in future releases.

  BSP_MaxDepth=128
  BSP_BaseAccessCost=1.0
  BSP_ChildAccessCost=1.5
  BSP_IsectCost=150.0
  BSP_MissChance=0.2

The values shown above are the default. You can also get the defaults if you use a value of 0 for any of the above, or of course just by not specifying the option at all. For an explanation of what the values mean you may refer to Ray Tracing News article by Eric Haines.

See the distribution file ~scenes/bsp/Tango.pov for a good example of a scene that benefits from the BSP bounding.

Tango.pov rendered at 800x600, no AA

  • With +BM1 : 70 seconds total
  • With +BM2 : 48 seconds total

Stochastic Seed

Stochastic_Seed=n
Sets a value for the stochastic seed New in version 3.8
+SSn
Same as Stochastic_Seed=n

By default some stochastic mechanisms in POV-Ray intentionally give different results for each render, with the intent that multiple renders can be averaged to get a higher-quality image. To this end, the corresponding pseudo-random number generators are seeded with a value derived from the current date and time.

If the Stochastic_Seed=n or +SSn option is specified, the seed will instead be derived from the specified value, allowing to produce exactly the same output each time by specifying that same value. Alternatively, the mechanism may be co-opted to prevent separate renders started at the same time from producing identical results, by explicitly specifying different values.

Note: Even if the seed is set identically, other factors may cause differences in the result. For example the render block size +BSn or the render pattern +RPn options. Results may also differ between versions of POV-Ray.

Presently anti-aliasing sampling method 3 is the only feature that is sensitive to the stochastic seed setting.

Anti-Aliasing Options

Antialias=bool
Turns anti-aliasing on/off
+A
Turns aa on with threshold 0.3 or previous amount
-A
Turns anti-aliasing off
Sampling_Method=n
Sets aa-sampling method (either 1, 2 or 3 the later is New in version 3.8 )
+AMn
Same as Sampling_Method=n
Antialias_Threshold=n.n
Sets anti-aliasing threshold
+An.n Sets aa on with aa-threshold at n.n
-An.n Sets aa off (aa-threshold n.n in future)
Jitter=bool
Sets aa-jitter on/off
+J
Sets aa-jitter on with 1.0 or previous amount
-J
Sets aa-jitter off
Jitter_Amount=n.n
Sets aa-jitter amount to n.n. If n.n <= 0 aa-jitter is set off
+Jn.n Sets aa-jitter on; jitter amount to n.n. If n.n <= 0 aa-jitter is set off
-Jn.n Sets aa-jitter off (jitter amount n.n in future)
Antialias_Confidence=n.n
Sets method 3 confidence to n.n New in version 3.8
+ACn.n
Same as Antialias_Confidence=n.n New in version 3.8
Antialias_Depth=n
Sets aa-depth (1 <= n <= 9)
+Rn
Same as Antialias_Depth=n
Antialias_Gamma=n.n
Sets the anti-aliasing gamma to n.n
+AGn.n
Same as Antialias_Gamma=n.n

The ray-tracing process is in effect a discrete, digital sampling of the image with typically one sample per pixel. Such sampling can introduce a variety of errors. This includes a jagged, stair-step appearance in sloping or curved lines, a broken look for thin lines, moiré patterns of interference and lost detail or missing objects, which are so small they reside between adjacent pixels. The effect that is responsible for those errors is called aliasing.

Anti-aliasing is any technique used to help eliminate such errors or to reduce the negative impact they have on the image. In general, anti-aliasing makes the ray-traced image look smoother. The Antialias=on option or +A option turns on POV-Ray's anti-aliasing system.

When anti-aliasing is turned on, POV-Ray attempts to reduce the errors by shooting more than one viewing ray into each pixel and averaging the results to determine the pixel's apparent color. This technique is called super-sampling and can improve the appearance of the final image but it drastically increases the time required to render a scene since many more calculations have to be done.

POV-Ray gives you the option to use one of three sampling methods. Two alternate super-sampling methods and one over-sampling method. The Sampling_Method=n option or +AMn option selects either type 1, type 2 or type 3. Selecting one of those methods does not turn on anti-aliasing. This has to be done by using the +A command line option or Antialias=on option.

Sampling Methods Synopsis

  • Type 1: an adaptive non-recursive super-sampling method. It is adaptive because not every pixel is super-sampled
  • Type 2: an adaptive and recursive super-sampling method. It is recursive because the pixel is sub-divided recursively. The adaptive nature of type 2 is the variable recursion depth
  • Type 3: an adaptive non-recursive stochastic oversampling method. The adaptive nature of type 3 is confidence and threshold

Sampling Method 1

+AM1 is an adaptive non-recursive method. If anti-aliasing is enabled it is the default. POV-Ray initially traces one ray per pixel. If the color of a pixel differs from its neighbors (to the left or above) by at least the set threshold value then the pixel is super-sampled by shooting a given, fixed number of additional rays. The default threshold is 0.3 but it may be changed using the Antialias_Threshold=n.n option. When the switches are used, the threshold may optionally follow the +A. For example +A0.1 turns anti-aliasing on and sets the threshold to 0.1.

The threshold comparison is computed as follows. If r1, g1, b1 and r2, g2, b2 are the rgb components of two pixels then the difference between pixels is computed by

diff = abs(r1-r2) + abs(g1-g2) + abs(b1-b2)

If this difference is greater than the threshold then both pixels are super-sampled. The rgb values are in the range from 0.0 to 1.0 thus the most two pixels can differ is 3.0. If the anti-aliasing threshold is 0.0 then every pixel is super-sampled. If the threshold is 3.0 then no anti-aliasing is done. Lower threshold means more anti-aliasing and less speed. Use anti-aliasing for your final version of a picture, not the rough draft. The lower the contrast, the lower the threshold should be. Higher contrast pictures can get away with higher tolerance values. Good values seem to be around 0.2 to 0.4.

When using the non-recursive method, the default number of super-samples is nine per pixel, located on a 3*3 grid. The Antialias_Depth=n option or +Rn option controls the number of rows and columns of samples taken for a super-sampled pixel. For example +R4 would give 4*4=16 samples per pixel.

Sampling Method 2

+AM2 is an adaptive, recursive super-sampling method. It starts by tracing four rays at the corners of each pixel. If the resulting colors differ more than the threshold amount additional samples will be taken. This is done recursively, i.e. the pixel is divided into four sub-pixels that are separately traced and tested for further subdivision. The advantage of this method is the reduced number of rays that have to be traced. Samples that are common among adjacent pixels and sub-pixels are stored and reused to avoid re-tracing of rays. The recursive character of this method makes the super-sampling concentrate on those parts of the pixel that are more likely to need super-sampling (see figure below).

RefImgRecsuper.gif

Example of how the recursive super-sampling works.

The maximum number of subdivisions is specified by the Antialias_Depth=n option or +Rn option. This is different from the adaptive, non-recursive method where the total number of super-samples is specified. A maximum number of n subdivisions results in a maximum number of samples per pixel that is given by the following table. Where the first column represents anti-alias depth or +Rn option. The second column is the number of additional samples per super-sampled pixel for the non-recursive method +AM1. Lastly the third column is the maximum number of samples per super-sampled pixel for the recursive method +AM2.

1 1 9
2 4 25
3 9 81
4 16 289
5 25 1089
6 36 4225
7 49 16641
8 64 66049
9 81 263169

Note: The maximum number of samples in the recursive case is hardly ever reached for a given pixel. If the recursive method is used and the anti-aliasing threshold is not reached, each pixel will be the average of the rays traced at its corners. In others words, you get the average of those four pixels with no further sub-sampling. In most cases a recursion level of three is sufficient.

Sampling Method 3

+AM3 is New in version 3.8 and it's an adaptive, non-recursive stochastic oversampling method. This method repeatedly iterates over the pixels to be rendered, jittering each ray randomly within the pixel on each pass, while keeping track of statistical parameters such as average color and mean deviation. On subsequent passes, the algorithm ceases to over-sample pixels where the statistical parameters for the pixel itself and its immediate four neighbors indicate that the result is probably good enough.

What constitutes probably good enough is determined by a confidence parameter specified by the Antialias_Confidence=n.n or +ACn.n option, as well as a threshold parameter specified by the Antialias_Threshold=n.n or +An.n option.

The threshold determines what absolute sampling error (i.e. difference between the computed pixel color and the theoretically correct one) you consider acceptable, while the confidence specifies how sure you want to be that a pixel that seems acceptable actually is acceptable. In effect, this determines how many pixels in the resulting image will indeed be acceptable. For example, if you specify a confidence of 0.95, then you can expect approximately 95% of all pixels to be within the threshold, as compared to a theoretically correct image. Of the remaining ones, many will be off by slightly more than the threshold, while only few will be significantly off. Extreme outlines are possible but extremely unlikely.

Recommended values are a threshold of 0.3 or lower, and a confidence of 0.9 or higher. They are the defaults.

The total number of rays shot per pixel is limited by the Antialias_Depth=n or +Rn parameter. As with the other methods the parameter is limited to the range from 1 to 9, with the actual maximum number of rays per pixel being 4n.

By default, the sub-pixel jittering is different for each render, thus giving slightly different results, with the intent that multiple renders can be averaged to get a higher-quality image. Conversely you can produce exactly the same output each time. See also: Stochastic Seed

Note: The jitter sequence is also affected by the actual image content, and will thus always differ between the frames of an animation.

Since oversampling method 3 is a very generic adaptive oversampling algorithm, its performance in pure edge anti-aliasing is generally inferior to the other methods, however it is ideally suited to suppress random image noise created by other stochastic mechanisms, such as jittered area lights, subsurface light transport, or micro-normals based blurred reflections. It has also proven well-suited for eliminating moiré patterns.

Common Properties

Another way to reduce anti-aliasing artifacts is to introduce noise into the sampling process. This is called jittering and works because the human visual system is much more forgiving to noise than it is to regular patterns. It is inherent to anti-aliasing method 3 because it always uses a constant amount of jitter. When using one of the other methods the location of the super-samples is also jittered or wiggled a tiny amount by default. Alternately it may be turned off with the Jitter=off option or -J option. The amount of jittering can be set with the Jitter_Amount=n.n option. When using those options the jitter scale may be specified after the +Jn.n option. For example +J0.5 uses half the normal jitter. The default amount of 1.0 is the maximum jitter which will insure that all super-samples remain inside the original pixel.

Note: The jittering noise is random and non-repeatable so you should avoid using jitter in animation sequences as the anti-aliased pixels will vary and flicker annoyingly from frame to frame.

If anti-aliasing is not used one sample per pixel is taken regardless of the super-sampling method specified.

As the human eye is more sensitive to absolute brightness differences at a low overall brigtness than at higher ones, super-sampling based on linear light intensity differences would yield either poor anti-aliasing in darker regions, or unnecessary super-sampling in brighter regions of the image. To avoid this, POV-Ray compares gamma-adjusted values instead.

Note: This only affects the comparison operation. The averaging of the super-samples is done in whatever working color space is specified in the scene file via the assumed_gamma keyword.

The Antialias_Gamma=n.n command line option or +AGn.n sets the gamma to apply before comparison. The default is 2.5. This value is actually the inverse of the gamma applied, in order to use the same value range as the display and file gamma settings. If the image contains an alpha channel, that channel will also be considered in the comparisons, like the color channels, except that unlike the other channels it is not subject to Antialias_Gamma. Neutral behavior can be achieved using Antialias_Gamma=1.0

Note: The mesh_camera feature added in version 3.7 also makes extreme super-sampling possible. See the distribution file ~scenes/camera/mesh_camera/ess/README.txt for additional information.

Radiosity Options

Radiosity High Reproducibility

As of version 3.7 a new radiosity mode has been introduced. When specifying High_Reproducibility or +HR on the command line, POV-Ray will spend extra effort to make sure renders are deterministic despite SMP. Currently radiosity is the only code to use this flag; in +HR mode, radiosity pretrace starts out with fewer threads, and some extra rules are imposed on sample re-use that may cause surplus samples to be gathered.

Note: The high reproducibility mode is not intended for use with radiosity alone, and it will need more work to guarantee the same improved reproducibility in other features. Even though it works well with radiosity, this addition is still experimental.

Radiosity Load and Save

The following .ini / command line parameters are recognized:

Radiosity_File_Name="<name>"	or +RF"<name>"	to set the cache file name
Radiosity_From_File=<on/off>	or +RFI	to enable reading the radiosity file at startup
Radiosity_To_File=<on/off>	or +RFO	to enable writing new samples to the radiosity file

Note: The parameter names are preliminary, and may still be subject to change; there is a potential conflict between the shorthand forms.

If both +RFI and +RFO are specified, new samples gathered are appended; otherwise, +RFO causes the file to be overwritten if it exists.

New samples gathered are written whenever an SMP block is completed. Tests indicate that this is almost neutral regarding performance, compared to operation with radiosity file output disabled.

Radiosity Vain Pretrace

Also new as of version 3.7 an option has been added to speed up radiosity pretrace:

As some computations don't contribute to the generation of radiosity samples, they can safely be skipped during radiosity pretrace to gain some speed if the pretrace's other role as a coarse preview is not required.

The following .ini file/command line options control whether pretrace performs all computations so it can double-feature as a coarse preview (vain pretrace):

Radiosity_Vain_Pretrace=bool	turns vain pretrace on/off
+RVP				turns vain pretrace on (default)
-RVP				turns vain pretrace off

Note: With vain pretrace off, preview will look remarkably odd during the radiosity pretrace phase; this is normal, and no reason to be alarmed.

At the moment, turning vain pretrace off will affect only classic lighting computations (diffuse lighting, highlights and iridescence); other features expendable during pretrace may follow in future versions.