https://wiki.povray.org/content?title=Documentation:Tutorial_Section_4.3&feed=atom&action=historyDocumentation:Tutorial Section 4.3 - Revision history2024-03-29T08:41:01ZRevision history for this page on the wikiMediaWiki 1.35.1https://wiki.povray.org/content?title=Documentation:Tutorial_Section_4.3&diff=1556&oldid=prevJholsenback: external link handling change after recent update2009-06-23T16:01:57Z<p>external link handling change after recent update</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 16:01, 23 June 2009</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l61" >Line 61:</td>
<td colspan="2" class="diff-lineno">Line 61:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div><p>You may also contact any of the POV-Ray T.A.G. members with suggestions,</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div><p>You may also contact any of the POV-Ray T.A.G. members with suggestions,</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>comments, or ideas for improvements to POV-Ray. You can learn more about the</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>comments, or ideas for improvements to POV-Ray. You can learn more about the</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>POV-Ray T.A.G. and their contact information on the [http://tag.povray.org<del class="diffchange diffchange-inline">/|_new <span title="Opens A New Window!"></del>TAG web page<del class="diffchange diffchange-inline"></span></del>].</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>POV-Ray T.A.G. and their contact information on the [http://tag.povray.org TAG web page].</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div></p></div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div></p></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l149" >Line 149:</td>
<td colspan="2" class="diff-lineno">Line 149:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div><p>There is no official GUI done for the Unix version of POV-Ray. Some</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div><p>There is no official GUI done for the Unix version of POV-Ray. Some</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>third-parties have tried to make some GUIs for it (and you might find them</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>third-parties have tried to make some GUIs for it (and you might find them</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>in the [http://povray.org/links/<del class="diffchange diffchange-inline">|_new <span title="Opens A New Window!"></del>links collection on our website<del class="diffchange diffchange-inline"></span></del>])</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>in the [http://povray.org/links/ links collection on our website])</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>but it seems to be a general phenomenon that Unix people like to use just</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>but it seems to be a general phenomenon that Unix people like to use just</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>the command-line version with a proper and powerful text editor (such as</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>the command-line version with a proper and powerful text editor (such as</div></td></tr>
<tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l307" >Line 307:</td>
<td colspan="2" class="diff-lineno">Line 307:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div></p></div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div></p></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div><p>This is a real problem that happens even to the best. For example, check</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div><p>This is a real problem that happens even to the best. For example, check</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>this [http://oz.irtc.org/ftp/pub/stills/1998-10-31/running.jpg<del class="diffchange diffchange-inline">|_new <span title="Opens A New Window!"></del>IRTC winner image<del class="diffchange diffchange-inline"></span></del>]. Notice the straight shadow lines on the rocks (specially</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>this [http://oz.irtc.org/ftp/pub/stills/1998-10-31/running.jpg IRTC winner image]. Notice the straight shadow lines on the rocks (specially</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>in the closest rock)?</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>in the closest rock)?</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td></tr>
</table>Jholsenbackhttps://wiki.povray.org/content?title=Documentation:Tutorial_Section_4.3&diff=1425&oldid=prevJholsenback: Protected "Documentation:Tutorial Section 4.3" [edit=sysop:move=sysop]2009-03-10T18:19:43Z<p>Protected "<a href="/content/Documentation:Tutorial_Section_4.3" title="Documentation:Tutorial Section 4.3">Documentation:Tutorial Section 4.3</a>" [edit=sysop:move=sysop]</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<tr class="diff-title" lang="en">
<td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 18:19, 10 March 2009</td>
</tr><tr><td colspan="2" class="diff-notice" lang="en"><div class="mw-diff-empty">(No difference)</div>
</td></tr></table>Jholsenbackhttps://wiki.povray.org/content?title=Documentation:Tutorial_Section_4.3&diff=1401&oldid=prevJholsenback: 1 revision(s)2009-03-10T18:02:53Z<p>1 revision(s)</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<tr class="diff-title" lang="en">
<td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="1" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 18:02, 10 March 2009</td>
</tr><tr><td colspan="2" class="diff-notice" lang="en"><div class="mw-diff-empty">(No difference)</div>
</td></tr></table>Jholsenbackhttps://wiki.povray.org/content?title=Documentation:Tutorial_Section_4.3&diff=1400&oldid=prevWikiSysop: /* Can this problem be solved? */2009-03-06T16:13:12Z<p><span dir="auto"><span class="autocomment">Can this problem be solved?</span></span></p>
<p><b>New page</b></p><div><!--<wikitalk>---><br />
<table width=100% border=1 cellspacing=0 cellpadding=5><br />
<tr><td width=100% bgcolor=#FFEEEE><br />
This document is protected, so submissions, corrections and discussions should be held on this documents [[Documentation_Talk:Tutorial Section 4.3|talk]] page.<br />
</td></tr><br />
</table><br />
<br><br />
<!--</wikitalk>---><br />
===Does POV-Ray support 3DNow?===<br />
<p>No, and most likely never will.<br />
<br />
</p><br />
<p>There are several good reasons for this:<br />
<br />
<ul><br />
<li>3DNow uses single precision numbers while POV-Ray needs (yes, it needs)<br />
double precision numbers. Single precision is not enough (this has been<br />
tested in practice).<br><br />
(To better understand the difference between single and double precision<br />
numbers, imagine that you could represent values between 0 and 1000 with<br />
single precision numbers. With double precision numbers you do not get<br />
a scale from 0 to 2000 (as one might think), but from 0 to 1000000. The<br />
difference is enormous and single precision is not precise enough for<br />
what POV-Ray does.)</li><br />
<li>Adding support for 3DNow (or any other CPU-specific feature) to POV-Ray<br />
would make it platform-dependant and not portable. Of course one could<br />
make a separate binary for AMD supporting 3DNow, but there are only<br />
two ways of doing this:<br />
<ol><br />
<li>Compiling POV-Ray with a compiler which automatically can make<br />
3DNow code from C. As far as I know, no such compiler exists<br />
which converts double precision math used in POV-Ray to single<br />
precision math needed by 3DNow. I do not event know if there is any<br />
compiler that supports 3DNow at all.</li><br />
<li>Changing the source code by hand in order to use 3DNow instructions.<br />
This is a whole lot of work (specially because you will probably have<br />
to use inline assembler). The source code of POV-Ray is not very<br />
small. Would it be worth the efforts?</li><br />
</ol></li><br />
</ul><br />
<br />
</p><br />
<p>Note: There are a few things in POV-Ray that use single<br />
precision math (such as color handling). This is one field where some<br />
optimization might be possible without degrading the image quality.<br />
</p><br />
<br />
===Miscellaneous questions===<br />
<br />
===Where do I suggest new features?===<br />
<p><em>&quot;I would like to suggest some new features for the program.<br />
Who should I talk to?&quot;</em><br />
<br />
</p><br />
<p>This is best discussed on the Pov news groups (news.povray.org) in both<br />
the general news group and the windows news group. The Pov team does<br />
skim through the message posted there and occasionaly impliment<br />
ideas that have been posted by users.<br />
<br />
</p><br />
<p>You may also contact any of the POV-Ray T.A.G. members with suggestions,<br />
comments, or ideas for improvements to POV-Ray. You can learn more about the<br />
POV-Ray T.A.G. and their contact information on the [http://tag.povray.org/|_new <span title="Opens A New Window!">TAG web page</span>].<br />
</p><br />
<br />
===I'm getting a "Illegal grid value in dda_traversal()"===<br />
<p><em>&quot;When I render a height field I get lots of warning messages saying<br />
&quot;Illegal grid value in dda_traversal()&quot;. How can I correct<br />
that?&quot;</em><br />
<br />
</p><br />
<p>(Answer by Jerry Anning)<br />
<br />
</p><br />
<p>Basically, you have a ray going &quot;between the cracks&quot; of<br />
the height field due to an arithmetic accuracy problem. Sometimes it<br />
does no harm. Sometime you get black dot or line artifacts. I know of<br />
no successful patch so far. I also know no completely reliable<br />
workaround. The best bet is to slightly joggle the camera position<br />
and/or angle.<br />
</p><br />
<br />
===No beep when finished?===<br />
<p><em>&quot;How can I get rid of the beep after POV-Ray has calculated the image&quot;<br />
</em><br />
<br />
</p><br />
<p>Usually using the <code>-P</code> command-line option should help<br />
(POV-Ray will not<br />
pause after it has calculated the image). If you are using the windows version<br />
of POV-Ray, you can try Render -&gt; On Completion -&gt; Remove [v] in front<br />
of &quot;Beep&quot;.<br />
</p><br />
<br />
===POV-Ray viruses?===<br />
<p><em>&quot;Are there any POV-Ray viruses out there? Can one be done?&quot;</em></p><br />
<br />
<p>At the time of writing this documentation, no known viruses or trojans<br />
made with the POV-Ray Scene Description Language (SDL) are known to<br />
exist.</p><br />
<br />
<p>Due to the properties of the POV-Ray SDL, writing a working virus<br />
(that is, a piece of code which spreads, without the user knowing,<br />
by copying itself to non-infected files) is very difficult, if not<br />
impossible to do. The main obstacle in making a POV-Ray virus is<br />
that there is no way for the SDL code to reside in memory, infecting<br />
files when it sees them; another problem is that there is no way to<br />
get file listings in the POV-Ray SDL, so the code cannot infect other<br />
.pov files at parse time.</p><br />
<br />
<p>However, trojans (i.e. a malicious piece of code which attempts to<br />
harm the system, but will not infect other files) are much more likely.<br />
It is possible with the POV-Ray SDL to open a file and write<br />
practically anything to it. This can be used to cause severe damage<br />
to an unprotected file system.</p><br />
<br />
<p>Note, however, that in POV-Ray 3.5 the concept of I/O restrictions<br />
was introduced in order to protect the user from these kinds of<br />
malicious scripts. Setting the I/O restrictions properly will<br />
prevent the SDL from being able to open files for writing (and<br />
optionally even for reading). You should check that your copy of<br />
POV-Ray 3.5 has these restrictions properly set, especially if you<br />
render files not made by you. Note, however, that not all versions of<br />
POV-Ray 3.5 for different platforms may have these restrictions implemented.<br />
Consult section 1 of the POV-Ray 3.5 documentation for more details about the<br />
I/O restrictions.</p><br />
<br />
<p>Regardless of this, it is always a good idea to run only scripts which<br />
you have received from trusted sources. This is particularly true if<br />
you are using a version of POV-Ray older than 3.5.</p><br />
<br />
<p>The POV-Ray community consists mostly of benevolent people and it is<br />
generally safe to try POV-Ray scripts made by them. However, it is<br />
often better to be safe than to be sorry.</p><br />
<br />
===GUI for Unix POV-Ray?===<br />
<p><em>&quot;Does POV-Ray for Unix have a GUI like in Windows?&quot;</em><br />
<br />
</p><br />
<p>No.<br />
<br />
</p><br />
<p>POV-Ray has always been a command-line utility. Even the core code of<br />
POV-Ray for Windows is exactly the same as the generic command-line POV-Ray.<br />
The graphical interfaces of the Windows and Mac versions of POV-Ray are<br />
exclusive to them (and non-portable). They are much like separate &quot;add-ons&quot;.<br />
<br />
</p><br />
<p>There is no official GUI done for the Unix version of POV-Ray. Some<br />
third-parties have tried to make some GUIs for it (and you might find them<br />
in the [http://povray.org/links/|_new <span title="Opens A New Window!">links collection on our website</span>])<br />
but it seems to be a general phenomenon that Unix people like to use just<br />
the command-line version with a proper and powerful text editor (such as<br />
Emacs).<br />
<br />
</p><br />
<p>I am sorry but there is no advice right now here about how to configure<br />
Emacs in order to smoothly handle POV-Ray file editing, but I might write<br />
a page about that some day, when I have the time.<br />
</p><br />
<br />
===The shadow line artifact===<br />
<br />
===What is the problem?===<br />
<p>People often find an annoying problem when applying normal modifier<br />
patterns to objects. It is said that one image tells more than a thousand<br />
words, and this saying also applies here. This image shows two cases where<br />
the problem appears:<br />
</p><br />
<br />
<p>[[Image:TutImgPic1.png|Sometimes odd shadow lines appear on certain objects]]</p><br />
<br />
<ul><br />
<li>The object in the left of the image is just a regular POV-Ray sphere with<br />
a normal modifier made with the bump pattern.</li><br />
<li>The object in right of the image is a mesh of smooth triangles.</li><br />
</ul><br />
<br />
<p>As you notice, there are two clear artifacts in the image. The sphere<br />
has a straight shadow line which seems unnatural and the mesh has a<br />
non-straight shadow line when it is supposed to have a straight one.<br />
</p><br />
<br />
<p>Although the artifacts look quite different in nature, they are, in fact<br />
caused by the exact same problem.<br />
</p><br />
<br />
<br><br />
<br />
<p>[[Image:TutImgPic2.png|The image one would expect.]]</p><br />
<br />
<p><br />
What one could expect would be something like this image (do not mind about<br />
the bright part under the triangle mesh; this is explained later).<br />
</p><br />
<br />
===What causes the problem?===<br />
<p>Let's start with the sphere with the perturbed normal, since it is easier<br />
to explain.<br />
<br />
</p><br />
<p>[[Image:TutImgShadowtest.png|Shadow line test with modified normals]]</p><br />
<p>This image shows graphically what happens.<br />
<br />
</p><br />
<p>The problem happens in the &quot;dark side&quot; of the object, that is, the side<br />
which does not &quot;see&quot; the light source.<br />
<br />
</p><br />
<p>Although the surface normal points away from the light source (ie. its angle<br />
is &gt;90 degrees from the light source), the perturbed normal points towards<br />
it (ie. its angle is &lt;90 degrees) and thus, according to the normal<br />
vector, the light source should illuminate the point in question.<br />
<br />
</p><br />
<p>However, when doing the shadow-ray test, POV-Ray sees that the test ray<br />
intersects with a surface (in this case the surface of the same sphere, but<br />
at the &quot;other side&quot;). Thus it decides that the surface in question is<br />
shadowing the current point and thus the light source does not illuminate it.<br />
<br />
</p><br />
<p>This is what causes the straight shadow exactly where the (non-perturbed)<br />
surface normal is exactly at 90 degrees from the light source.<br />
<br />
<br><br />
<br />
<br />
</p><br />
<p>The problem with the mesh of smooth triangles is a bit more difficult,<br />
although very similar (and caused by the exact same problem).<br />
<br />
</p><br />
<p>[[Image:TutImgShadowtest2.png|Shadow test of a triangle mesh]]</p><br />
<p>This image shows graphically what happens.<br />
<br />
</p><br />
<p>Although there is no explicit normal perturbation, the fact that the surface<br />
is a mesh of smooth triangles means that there is an implicit normal<br />
perturbation.<br />
<br />
</p><br />
<p>In order to get a smooth appearance, each vertex has a normal vector and<br />
the normal vector at any point in the surface of the triangle is calculated<br />
by interpolating the normal vectors of the vertices.<br />
<br />
</p><br />
<p>Here the problem happens when the shadow line should pass across a triangle<br />
and the unperturbed normal vector of that triangle points away from the<br />
light source. As seen in the figure, a triangle that is closer to the<br />
light source will shadow the point in the current triangle (it is not<br />
necessarily the adjacent triangle, but if the mesh is closed, some triangle<br />
will surely shadow the point in question).<br />
<br />
</p><br />
<p>This means that this unfortunate triangle will be completely shadowed,<br />
thus causing a triangular artifact in the shadow line of the mesh.<br />
<br />
<br><br />
</p><br />
<p>[[Image:TutImgPic3.png|The shadow line corresponds to the non-smooth mesh.]]</p><br />
<p>The image on the left shows more clearly why the shadow line of the smooth<br />
triangle mesh is like it appeared in the first image of this page.<br />
<br />
</p><br />
<p>The object at the left is the same triangle mesh, but with flat triangles,<br />
and the object at the right is the same object as in the image at the<br />
beginning of this page.<br />
<br />
</p><br />
<p>Notice how the shadowed triangles of the flat mesh correspond exactly<br />
to the artifacts in the shadow line of the smooth mesh. The reason for<br />
this was explained in the figure above.<br />
<br />
<br><br />
</p><br />
<br />
===Can this problem be solved?===<br />
<p>And how did I correct the problem in the second image at the beginning of<br />
this page?<br />
<br />
</p><br />
<p>Firstly, do not think that it is a bug in POV-Ray. It is not a bug, but a<br />
real problem caused be the lighting model used in the renderer engine that<br />
is quite difficult to surpass. It is not a problem in POV-Ray in particular,<br />
but a problem in raytracing in general. Every raytracer will have this same<br />
problem when using perturbed surface normals (unless there is some fix coded<br />
into it).<br />
<br />
</p><br />
<p>Perturbed surface normals are used, in fact, to simulate the perturbation<br />
of the surface itself. When calculating the lighting of the object, the<br />
surface normal perturbation will give the impression that the surface itself<br />
is perturbed (eg. in the images at the beginning of this page the sphere<br />
looks like it has a bumpy surface).<br />
<br />
</p><br />
<p>In triangle meshes the normal interpolation is used to simulate curvature<br />
of the surface (a curvature which actually is not there).<br />
<br />
</p><br />
<p>However, since the normal vector perturbation does not affect the surface<br />
itself in any way, this kind of artifact will be the price to pay (another<br />
one is that although the surface looks bumpy or smooth, its silhouette will<br />
still look straight or polygonized, but this usually is not such a big<br />
problem).<br />
<br />
</p><br />
<p>This is a real problem that happens even to the best. For example, check<br />
this [http://oz.irtc.org/ftp/pub/stills/1998-10-31/running.jpg|_new <span title="Opens A New Window!">IRTC winner image</span>]. Notice the straight shadow lines on the rocks (specially<br />
in the closest rock)?<br />
<br />
</p><br />
<p>However, there are certain things that can be done to alleviate the<br />
problem.<br />
</p><br />
<br />
===Possible solutions?===<br />
<p>1) So what did I do to get the second image at the beginning of this page?<br />
<br />
</p><br />
<p>I just made the objects shadowless. This gets rid of the problem of the<br />
surface shadowing the wrong point.<br />
<br />
</p><br />
<p>This, of course, has severe problems. Since the object does not cast<br />
shadows anymore, it probably cannot be used in any real scene (although<br />
making the rocks shadowless in the IRTC winning image mentioned above would<br />
have perhaps helped the image a lot without making it too unrealistic).<br />
<br />
</p><br />
<p>With smooth triangle meshes it also introduces another artifact, which<br />
can be seen in the second image at the beginning of the page. I do not know<br />
the exact mechanism of this artifact but it is a direct consequence of the<br />
mesh being shadowless (it may have something to do with the fact that<br />
smooth triangles are double-illuminated in POV-Ray).<br />
<br />
<br />
<br />
</p><br />
<p>2) Perhaps a future version of POV-Ray or one of its patches may introduce<br />
a way to stop self-shadowing (while still casting shadows on other objects).<br />
<br />
</p><br />
<p>This would alleviate the problem of the completely shadowless object since<br />
this object could be used in real scenes and they will cast shadows on other<br />
objects and they will not have the shadow line artifact.<br />
<br />
</p><br />
<p>However, this solution applies only to a few range of objects (mainly convex<br />
objects). Objects where self-shadowing is essential (imagine a coffee cup,<br />
for example) will still have problems.<br />
<br />
<br />
<br />
</p><br />
<p>3) I have proposed this sophisticated algorithm to get rid of the problem:<br />
<br />
</p><br />
<p>When doing shadow ray tests, do the following:<br />
<br />
<ol><br />
<li>Make the regular shadow ray test, which gets all the intersections<br />
of the ray with all the surfaces that are between the current point and<br />
the light source.</li><br />
<li>Look if in the current point the unperturbed normal vector points<br />
away from the light source and the perturbed normal vector points<br />
towards the light source.</li><br />
<li>If so, check if the closest intersection point of the shadow ray belongs<br />
to the current object.</li><br />
<li>If so, remove that intersection point from the list.</li><br />
</ol><br />
<br />
</p><br />
<p>If we want to be more sure, we could also check if we are hitting the<br />
&quot;inside&quot; of the surface at this closest intersection point and only then<br />
remove it. This might be necessary for non-closed surfaces.<br />
<br />
</p><br />
<p>This algorithm will eliminate the shadowline artifact without eliminating<br />
shadowing and self-shadowing of the object.<br />
<br />
</p><br />
<p>It has its defects, though:</p><br />
<br />
<ol><br />
<li>For example, if the camera is inside the<br />
object in question (and all the light sources are outside), we would expect<br />
to get a completely shadowed view of the surface. However, if the surface<br />
has perturbed normal, we will see some illuminated parts of the surface.<br />
However, I think that this problem is quite irrelevant in the vast majority<br />
of scenes (and it should be possible to turn the fix off anyways).<br />
</li><br />
<li>It has several problems which can happen with non-convex objects (thanks<br />
to Ron Parker to pointing this out). The object can shadow itself with<br />
more than one surface. If it shadows itself from the outside (eg. a coffee<br />
cup), there is no problem, but if it &quot;shadows itself&quot; from the inside (eg. a<br />
coffee cup upside down) this shadow will be seen in an unrealistic way in<br />
the outermost surface of the object. There might not be any easy way to<br />
detect, which one is the case.<br />
</li><br />
<li>Another problem similar to the above is that if there is another object<br />
inside this object we are calculating, that another object will itself also<br />
&quot;cast a shadow&quot; on the surface (this might be possible to fix by ignoring<br />
all the objects inside the current object; this is possible to do in a<br />
rather simple way; however, it is does not work in all cases).<br />
</li><br />
<li>We still get the same artifact in triangle meshes<br />
as is shown in the second image at the beginning of the page. However, I am<br />
sure that this problem could be fixed as well (although I may be wrong,<br />
of course).<br />
</ol><br />
<br />
===Smooth triangle artifact===<br />
<br />
===What is the problem?===<br />
<p>There is a peculiar problem with smooth triangles which shows as a lighting<br />
artifact in certain cases. This can happen in individual smooth triangles,<br />
meshes with smooth triangles and smooth heightfields. The problem also<br />
manifests itself when using the slope pattern in the same situation.<br />
This image shows the two cases:<br />
</p><br />
<br />
<p>[[Image:TutImgStartifacts.png|Lighting and slope pattern artifacts in a smooth triangle]]</p><br />
<br />
<p>The source code of this image is the following:</p><br />
<br />
<pre><br />
camera { right x*4 location &lt;0,1,-5&gt; look_at 0 angle 35 }<br />
light_source { y*100, 1 }<br />
light_source { -y*100, x }<br />
<br />
smooth_triangle<br />
{ &lt;-.5,0,-1&gt;,&lt;-1,1,-1&gt;, &lt;.5,0,-1&gt;,&lt;1,1,-1&gt;, &lt;0,0,1&gt;,&lt;0,1,1&gt;<br />
pigment { rgb 1 }<br />
translate -x*.6<br />
}<br />
smooth_triangle<br />
{ &lt;-.5,0,-1&gt;,&lt;-1,1,-1&gt;, &lt;.5,0,-1&gt;,&lt;1,1,-1&gt;, &lt;0,0,1&gt;,&lt;0,1,1&gt;<br />
pigment { slope y color_map { [0 rgb z][1 rgb x+y] } }<br />
finish { ambient 1 }<br />
translate x*.6<br />
}<br />
</pre><br />
<br />
<p>The triangle at the left is a regular smooth triangle which is illuminated<br />
by a white light source from above. There is also a red light source<br />
illuminating the triangle from below. As you can see, the farther part of the<br />
triangle is wrongly illuminated as red. No part of the triangle should be<br />
illuminated by the red light source because the upper side of the triangle<br />
is nowhere facing down.</p><br />
<br />
<p>The triangle at the right is the same smooth triangle with a slope<br />
pattern applied to it, which goes from blue (in the negative y direction)<br />
to yellow (in the positive y direction). Lighting has been eliminated by<br />
specifying a high ambient. As all the parts of the upper side<br />
of the triangle are pointing upwards, the whole triangle should be colored<br />
with shades of yellow, but as you can see, the same farther part is<br />
wrongly colored blue.</p><br />
<br />
<p>(If you guessed that the problem happens when the normal vector of the<br />
triangle is pointing away from the camera, then you guessed right.)</p><br />
<br />
===What causes the problem?===<br />
<p>The problem is caused by the rendering algorithm used in POV-Ray. The<br />
following text is quite technical, so if you just want to read about<br />
possible solutions to this problem, you can skip to the next subsection.</p><br />
<br />
<p>The problem is that the rendering engine assumes that objects return<br />
the <em>true</em> normal vector for the given point in their surface. For an<br />
object to render correctly, it <em>must</em> give the exact normal vector<br />
(ie. a vector which is exactly perpendicular to the surface at that point).</p><br />
<br />
<p>Smooth meshes and heightfields do not do this. They return normal vectors<br />
which are not perpendicular to the actual surface. This causes errors in the<br />
rendering.</p><br />
<br />
<p>What happens is that when the rendering engine shoots a ray and it hits<br />
the surface of an object, the engine asks the object &quot;what is the normal vector<br />
at this point in your surface?&quot;.<br />
Now, if the angle between the returned normal vector and the ray vector<br />
is less than 90 degrees (that is, the normal vector points away from the<br />
point of view of the starting point of the ray), then the engine reverses<br />
the returned normal vector. This is essential for the lighting to work<br />
properly (if the normal is not reversed in this case, you would get all kind<br />
of errors in lighting, ie. surfaces which are illuminated from behind when<br />
they should not, or surface which are not illuminated even though they are<br />
facing a light source).</p><br />
<br />
<p>This assumes that the normal vector returned by the object is a <em>true</em><br />
normal vector, and it works perfectly when this is so.</p><br />
<br />
<p>However, if the object returns an erroneous normal vector, ie. a vector<br />
which is not perpendicular to the surface, rendering errors can occur.</p><br />
<br />
<p>Smooth triangles and heightfields do this, and the price to pay are the<br />
artifacts in the lighting in certain situations.</p><br />
<br />
<p>The artifact is produced when the true normal vector would have an angle<br />
larger than 90 degrees with the ray, but the the actual vector returned by<br />
the object has an angle smaller than 90 degrees with the ray.<br />
In this case the rendering engine reverses the normal vector even though<br />
it should not. This is because it assumes that it is the true normal vector<br />
when in fact it is not.</p><br />
<br />
<p>This problem could be solved by making the decision of inverting the<br />
returned normal vector according to the true normal vector of the surface<br />
instead of the returned vector. However, due to the internal implementation<br />
of the rendering engine in the current POV-Ray 3.5, doing this is not<br />
trivial. It may be fixed in POV-Ray 4.0, where the rendering engine will<br />
be written again and this kind of things can be taken into account from<br />
the very beginning.</p><br />
<br />
===Can this problem be solved?===<br />
<p>You can get rid of the lighting artifact by applying<br />
<code>double_illuminate</code> to the object in question.<br />
When a surface is double illuminated, it does not matter which way its normal<br />
points - it will always be illuminated regardless of which side the light<br />
source is. Of course it should not matter that the object is now illuminated<br />
from both sides. If this is a problem, then the problem is not easily<br />
solvable.</p><br />
<br />
<p>Note that in the example given at the beginning of this<br />
section<br />
this solution does not work: It would illuminate the whole triangle with both<br />
light sources! However, this solution works well with closed triangle meshes,<br />
where the inner side of the mesh is shadowed by the mesh itself. However,<br />
if you are using <code>no_shadow</code> in the object (for example to<br />
get rid of<br />
<!--<linkto "the shadow line artifact">shadow line artifacts</linkto>--->[[Documentation:Tutorial Section 4.3#The shadow line artifact|shadow line artifacts]]),<br />
new problems can arise in the lighting (such as bright<br />
parts in places where there should not be any; these are all cause by this<br />
same problem).</p><br />
<br />
<p>The slope pattern is more problematic and there is no generic solution<br />
which will work in all cases. Fortunately the most common use of the slope<br />
pattern is in heightfields, and there a solution is possible:</p><br />
<br />
<p>If you are having this problem in a smooth heightfield, the solution is<br />
to mirror the color_map (or whatever map you are using) around 0.5. This way<br />
it does not matter if the normal is reversed. That is, if you had something<br />
like this in a heightfield:</p><br />
<br />
<pre><br />
slope y color_map<br />
{ [0.50 rgb &lt;.5,.5,.5&gt;] // rock<br />
[0.75 rgb &lt;.8,.4,.1&gt;] // ground<br />
[1.00 rgb &lt;.4,1,.4&gt;] // grass<br />
}<br />
</pre><br />
<br />
<p>you simply have to mirror the map around 0.5, ie. add the values from<br />
0 to 0.5 in reverse order:</p><br />
<br />
<pre><br />
slope y color_map<br />
{ [0.00 rgb &lt;.4,1,.4&gt;] // grass<br />
[0.25 rgb &lt;.8,.4,.1&gt;] // ground<br />
[0.50 rgb &lt;.5,.5,.5&gt;] // rock<br />
[0.75 rgb &lt;.8,.4,.1&gt;] // ground<br />
[1.00 rgb &lt;.4,1,.4&gt;] // grass<br />
}<br />
</pre><br />
<br />
<p>Besides this you should, of course, apply <code>double_illuminate</code><br />
to the heightfield in order to get the proper lighting.</p><br />
<!--<wikinav>---><br />
<br><br />
<table width=100% border=0 cellspacing=0 cellpadding=5><br />
<tr><td width=50% bgcolor=#EEEEEF><br />
[[Documentation:Tutorial Section 4.2#CSG speed|CSG speed]]</td><br />
<td width=50% bgcolor=#EEEEEF align=right><br />
[[Documentation:Tutorial Section 5#Appendices|Appendices]]</td></tr><br />
</table><br />
<!--</wikinav>---><br />
<!--<wikitalk>---><br />
<br><br />
<table width=100% border=1 cellspacing=0 cellpadding=5><br />
<tr><td width=100% bgcolor=#FFEEEE><br />
This document is protected, so submissions, corrections and discussions should be held on this documents [[Documentation_Talk:Tutorial Section 4.3|talk]] page.<br />
</td></tr><br />
</table><br />
<!--</wikitalk>---></div>WikiSysop