Jholsenback: external link handling change after recent update

2009-06-23T16:01:57Z

external link handling change after recent update

WikiSysop: /* Can this problem be solved? */

2009-03-06T16:13:12Z

Can this problem be solved?

New page

<table width=100% border=1 cellspacing=0 cellpadding=5>
<tr><td width=100% bgcolor=#FFEEEE>
This document is protected, so submissions, corrections and discussions should be held on this documents [[Documentation_Talk:Tutorial Section 4.3|talk]] page.
</td></tr>
</table>
 

===Does POV-Ray support 3DNow?===
No, and most likely never will.


There are several good reasons for this:

<ul>
<li>3DNow uses single precision numbers while POV-Ray needs (yes, it needs)
double precision numbers. Single precision is not enough (this has been
tested in practice). 
(To better understand the difference between single and double precision
numbers, imagine that you could represent values between 0 and 1000 with
single precision numbers. With double precision numbers you do not get
a scale from 0 to 2000 (as one might think), but from 0 to 1000000. The
difference is enormous and single precision is not precise enough for
what POV-Ray does.)</li>
<li>Adding support for 3DNow (or any other CPU-specific feature) to POV-Ray
would make it platform-dependant and not portable. Of course one could
make a separate binary for AMD supporting 3DNow, but there are only
two ways of doing this:
<ol>
<li>Compiling POV-Ray with a compiler which automatically can make
3DNow code from C. As far as I know, no such compiler exists
which converts double precision math used in POV-Ray to single
precision math needed by 3DNow. I do not event know if there is any
compiler that supports 3DNow at all.</li>
<li>Changing the source code by hand in order to use 3DNow instructions.
This is a whole lot of work (specially because you will probably have
to use inline assembler). The source code of POV-Ray is not very
small. Would it be worth the efforts?</li>
</ol></li>
</ul>


Note: There are a few things in POV-Ray that use single
precision math (such as color handling). This is one field where some
optimization might be possible without degrading the image quality.


===Miscellaneous questions===

===Where do I suggest new features?===
"I would like to suggest some new features for the program.
Who should I talk to?"


This is best discussed on the Pov news groups (news.povray.org) in both
the general news group and the windows news group. The Pov team does
skim through the message posted there and occasionaly impliment
ideas that have been posted by users.


You may also contact any of the POV-Ray T.A.G. members with suggestions,
comments, or ideas for improvements to POV-Ray. You can learn more about the
POV-Ray T.A.G. and their contact information on the [http://tag.povray.org/|_new TAG web page].


===I'm getting a "Illegal grid value in dda_traversal()"===
"When I render a height field I get lots of warning messages saying
"Illegal grid value in dda_traversal()". How can I correct
that?"


(Answer by Jerry Anning)


Basically, you have a ray going "between the cracks" of
the height field due to an arithmetic accuracy problem. Sometimes it
does no harm. Sometime you get black dot or line artifacts. I know of
no successful patch so far. I also know no completely reliable
workaround. The best bet is to slightly joggle the camera position
and/or angle.


===No beep when finished?===
"How can I get rid of the beep after POV-Ray has calculated the image"



Usually using the <code>-P</code> command-line option should help
(POV-Ray will not
pause after it has calculated the image). If you are using the windows version
of POV-Ray, you can try Render -> On Completion -> Remove [v] in front
of "Beep".


===POV-Ray viruses?===
"Are there any POV-Ray viruses out there? Can one be done?"

At the time of writing this documentation, no known viruses or trojans
made with the POV-Ray Scene Description Language (SDL) are known to
exist.

Due to the properties of the POV-Ray SDL, writing a working virus
(that is, a piece of code which spreads, without the user knowing,
by copying itself to non-infected files) is very difficult, if not
impossible to do. The main obstacle in making a POV-Ray virus is
that there is no way for the SDL code to reside in memory, infecting
files when it sees them; another problem is that there is no way to
get file listings in the POV-Ray SDL, so the code cannot infect other
.pov files at parse time.

However, trojans (i.e. a malicious piece of code which attempts to
harm the system, but will not infect other files) are much more likely.
It is possible with the POV-Ray SDL to open a file and write
practically anything to it. This can be used to cause severe damage
to an unprotected file system.

Note, however, that in POV-Ray 3.5 the concept of I/O restrictions
was introduced in order to protect the user from these kinds of
malicious scripts. Setting the I/O restrictions properly will
prevent the SDL from being able to open files for writing (and
optionally even for reading). You should check that your copy of
POV-Ray 3.5 has these restrictions properly set, especially if you
render files not made by you. Note, however, that not all versions of
POV-Ray 3.5 for different platforms may have these restrictions implemented.
Consult section 1 of the POV-Ray 3.5 documentation for more details about the
I/O restrictions.

Regardless of this, it is always a good idea to run only scripts which
you have received from trusted sources. This is particularly true if
you are using a version of POV-Ray older than 3.5.

The POV-Ray community consists mostly of benevolent people and it is
generally safe to try POV-Ray scripts made by them. However, it is
often better to be safe than to be sorry.

===GUI for Unix POV-Ray?===
"Does POV-Ray for Unix have a GUI like in Windows?"


No.


POV-Ray has always been a command-line utility. Even the core code of
POV-Ray for Windows is exactly the same as the generic command-line POV-Ray.
The graphical interfaces of the Windows and Mac versions of POV-Ray are
exclusive to them (and non-portable). They are much like separate "add-ons".


There is no official GUI done for the Unix version of POV-Ray. Some
third-parties have tried to make some GUIs for it (and you might find them
in the [http://povray.org/links/|_new links collection on our website])
but it seems to be a general phenomenon that Unix people like to use just
the command-line version with a proper and powerful text editor (such as
Emacs).


I am sorry but there is no advice right now here about how to configure
Emacs in order to smoothly handle POV-Ray file editing, but I might write
a page about that some day, when I have the time.


===The shadow line artifact===

===What is the problem?===
People often find an annoying problem when applying normal modifier
patterns to objects. It is said that one image tells more than a thousand
words, and this saying also applies here. This image shows two cases where
the problem appears:


[[Image:TutImgPic1.png|Sometimes odd shadow lines appear on certain objects]]

<ul>
<li>The object in the left of the image is just a regular POV-Ray sphere with
a normal modifier made with the bump pattern.</li>
<li>The object in right of the image is a mesh of smooth triangles.</li>
</ul>

As you notice, there are two clear artifacts in the image. The sphere
has a straight shadow line which seems unnatural and the mesh has a
non-straight shadow line when it is supposed to have a straight one.


Although the artifacts look quite different in nature, they are, in fact
caused by the exact same problem.


 

[[Image:TutImgPic2.png|The image one would expect.]]


What one could expect would be something like this image (do not mind about
the bright part under the triangle mesh; this is explained later).


===What causes the problem?===
Let's start with the sphere with the perturbed normal, since it is easier
to explain.


[[Image:TutImgShadowtest.png|Shadow line test with modified normals]]
This image shows graphically what happens.


The problem happens in the "dark side" of the object, that is, the side
which does not "see" the light source.


Although the surface normal points away from the light source (ie. its angle
is >90 degrees from the light source), the perturbed normal points towards
it (ie. its angle is <90 degrees) and thus, according to the normal
vector, the light source should illuminate the point in question.


However, when doing the shadow-ray test, POV-Ray sees that the test ray
intersects with a surface (in this case the surface of the same sphere, but
at the "other side"). Thus it decides that the surface in question is
shadowing the current point and thus the light source does not illuminate it.


This is what causes the straight shadow exactly where the (non-perturbed)
surface normal is exactly at 90 degrees from the light source.

 


The problem with the mesh of smooth triangles is a bit more difficult,
although very similar (and caused by the exact same problem).


[[Image:TutImgShadowtest2.png|Shadow test of a triangle mesh]]
This image shows graphically what happens.


Although there is no explicit normal perturbation, the fact that the surface
is a mesh of smooth triangles means that there is an implicit normal
perturbation.


In order to get a smooth appearance, each vertex has a normal vector and
the normal vector at any point in the surface of the triangle is calculated
by interpolating the normal vectors of the vertices.


Here the problem happens when the shadow line should pass across a triangle
and the unperturbed normal vector of that triangle points away from the
light source. As seen in the figure, a triangle that is closer to the
light source will shadow the point in the current triangle (it is not
necessarily the adjacent triangle, but if the mesh is closed, some triangle
will surely shadow the point in question).


This means that this unfortunate triangle will be completely shadowed,
thus causing a triangular artifact in the shadow line of the mesh.

 

[[Image:TutImgPic3.png|The shadow line corresponds to the non-smooth mesh.]]
The image on the left shows more clearly why the shadow line of the smooth
triangle mesh is like it appeared in the first image of this page.


The object at the left is the same triangle mesh, but with flat triangles,
and the object at the right is the same object as in the image at the
beginning of this page.


Notice how the shadowed triangles of the flat mesh correspond exactly
to the artifacts in the shadow line of the smooth mesh. The reason for
this was explained in the figure above.

 


===Can this problem be solved?===
And how did I correct the problem in the second image at the beginning of
this page?


Firstly, do not think that it is a bug in POV-Ray. It is not a bug, but a
real problem caused be the lighting model used in the renderer engine that
is quite difficult to surpass. It is not a problem in POV-Ray in particular,
but a problem in raytracing in general. Every raytracer will have this same
problem when using perturbed surface normals (unless there is some fix coded
into it).


Perturbed surface normals are used, in fact, to simulate the perturbation
of the surface itself. When calculating the lighting of the object, the
surface normal perturbation will give the impression that the surface itself
is perturbed (eg. in the images at the beginning of this page the sphere
looks like it has a bumpy surface).


In triangle meshes the normal interpolation is used to simulate curvature
of the surface (a curvature which actually is not there).


However, since the normal vector perturbation does not affect the surface
itself in any way, this kind of artifact will be the price to pay (another
one is that although the surface looks bumpy or smooth, its silhouette will
still look straight or polygonized, but this usually is not such a big
problem).


This is a real problem that happens even to the best. For example, check
this [http://oz.irtc.org/ftp/pub/stills/1998-10-31/running.jpg|_new IRTC winner image]. Notice the straight shadow lines on the rocks (specially
in the closest rock)?


However, there are certain things that can be done to alleviate the
problem.


===Possible solutions?===
1) So what did I do to get the second image at the beginning of this page?


I just made the objects shadowless. This gets rid of the problem of the
surface shadowing the wrong point.


This, of course, has severe problems. Since the object does not cast
shadows anymore, it probably cannot be used in any real scene (although
making the rocks shadowless in the IRTC winning image mentioned above would
have perhaps helped the image a lot without making it too unrealistic).


With smooth triangle meshes it also introduces another artifact, which
can be seen in the second image at the beginning of the page. I do not know
the exact mechanism of this artifact but it is a direct consequence of the
mesh being shadowless (it may have something to do with the fact that
smooth triangles are double-illuminated in POV-Ray).


2) Perhaps a future version of POV-Ray or one of its patches may introduce
a way to stop self-shadowing (while still casting shadows on other objects).


This would alleviate the problem of the completely shadowless object since
this object could be used in real scenes and they will cast shadows on other
objects and they will not have the shadow line artifact.


However, this solution applies only to a few range of objects (mainly convex
objects). Objects where self-shadowing is essential (imagine a coffee cup,
for example) will still have problems.


3) I have proposed this sophisticated algorithm to get rid of the problem:


When doing shadow ray tests, do the following:

<ol>
<li>Make the regular shadow ray test, which gets all the intersections
of the ray with all the surfaces that are between the current point and
the light source.</li>
<li>Look if in the current point the unperturbed normal vector points
away from the light source and the perturbed normal vector points
towards the light source.</li>
<li>If so, check if the closest intersection point of the shadow ray belongs
to the current object.</li>
<li>If so, remove that intersection point from the list.</li>
</ol>


If we want to be more sure, we could also check if we are hitting the
"inside" of the surface at this closest intersection point and only then
remove it. This might be necessary for non-closed surfaces.


This algorithm will eliminate the shadowline artifact without eliminating
shadowing and self-shadowing of the object.


It has its defects, though:

<ol>
<li>For example, if the camera is inside the
object in question (and all the light sources are outside), we would expect
to get a completely shadowed view of the surface. However, if the surface
has perturbed normal, we will see some illuminated parts of the surface.
However, I think that this problem is quite irrelevant in the vast majority
of scenes (and it should be possible to turn the fix off anyways).
</li>
<li>It has several problems which can happen with non-convex objects (thanks
to Ron Parker to pointing this out). The object can shadow itself with
more than one surface. If it shadows itself from the outside (eg. a coffee
cup), there is no problem, but if it "shadows itself" from the inside (eg. a
coffee cup upside down) this shadow will be seen in an unrealistic way in
the outermost surface of the object. There might not be any easy way to
detect, which one is the case.
</li>
<li>Another problem similar to the above is that if there is another object
inside this object we are calculating, that another object will itself also
"cast a shadow" on the surface (this might be possible to fix by ignoring
all the objects inside the current object; this is possible to do in a
rather simple way; however, it is does not work in all cases).
</li>
<li>We still get the same artifact in triangle meshes
as is shown in the second image at the beginning of the page. However, I am
sure that this problem could be fixed as well (although I may be wrong,
of course).
</ol>

===Smooth triangle artifact===

===What is the problem?===
There is a peculiar problem with smooth triangles which shows as a lighting
artifact in certain cases. This can happen in individual smooth triangles,
meshes with smooth triangles and smooth heightfields. The problem also
manifests itself when using the slope pattern in the same situation.
This image shows the two cases:


[[Image:TutImgStartifacts.png|Lighting and slope pattern artifacts in a smooth triangle]]

The source code of this image is the following:

<pre>
camera { right x*4 location <0,1,-5> look_at 0 angle 35 }
light_source { y*100, 1 }
light_source { -y*100, x }

smooth_triangle
{ <-.5,0,-1>,<-1,1,-1>, <.5,0,-1>,<1,1,-1>, <0,0,1>,<0,1,1>
pigment { rgb 1 }
translate -x*.6
}
smooth_triangle
{ <-.5,0,-1>,<-1,1,-1>, <.5,0,-1>,<1,1,-1>, <0,0,1>,<0,1,1>
pigment { slope y color_map { [0 rgb z][1 rgb x+y] } }
finish { ambient 1 }
translate x*.6
}
</pre>

The triangle at the left is a regular smooth triangle which is illuminated
by a white light source from above. There is also a red light source
illuminating the triangle from below. As you can see, the farther part of the
triangle is wrongly illuminated as red. No part of the triangle should be
illuminated by the red light source because the upper side of the triangle
is nowhere facing down.

The triangle at the right is the same smooth triangle with a slope
pattern applied to it, which goes from blue (in the negative y direction)
to yellow (in the positive y direction). Lighting has been eliminated by
specifying a high ambient. As all the parts of the upper side
of the triangle are pointing upwards, the whole triangle should be colored
with shades of yellow, but as you can see, the same farther part is
wrongly colored blue.

(If you guessed that the problem happens when the normal vector of the
triangle is pointing away from the camera, then you guessed right.)

===What causes the problem?===
The problem is caused by the rendering algorithm used in POV-Ray. The
following text is quite technical, so if you just want to read about
possible solutions to this problem, you can skip to the next subsection.

The problem is that the rendering engine assumes that objects return
the true normal vector for the given point in their surface. For an
object to render correctly, it must give the exact normal vector
(ie. a vector which is exactly perpendicular to the surface at that point).

Smooth meshes and heightfields do not do this. They return normal vectors
which are not perpendicular to the actual surface. This causes errors in the
rendering.

What happens is that when the rendering engine shoots a ray and it hits
the surface of an object, the engine asks the object "what is the normal vector
at this point in your surface?".
Now, if the angle between the returned normal vector and the ray vector
is less than 90 degrees (that is, the normal vector points away from the
point of view of the starting point of the ray), then the engine reverses
the returned normal vector. This is essential for the lighting to work
properly (if the normal is not reversed in this case, you would get all kind
of errors in lighting, ie. surfaces which are illuminated from behind when
they should not, or surface which are not illuminated even though they are
facing a light source).

This assumes that the normal vector returned by the object is a true
normal vector, and it works perfectly when this is so.

However, if the object returns an erroneous normal vector, ie. a vector
which is not perpendicular to the surface, rendering errors can occur.

Smooth triangles and heightfields do this, and the price to pay are the
artifacts in the lighting in certain situations.

The artifact is produced when the true normal vector would have an angle
larger than 90 degrees with the ray, but the the actual vector returned by
the object has an angle smaller than 90 degrees with the ray.
In this case the rendering engine reverses the normal vector even though
it should not. This is because it assumes that it is the true normal vector
when in fact it is not.

This problem could be solved by making the decision of inverting the
returned normal vector according to the true normal vector of the surface
instead of the returned vector. However, due to the internal implementation
of the rendering engine in the current POV-Ray 3.5, doing this is not
trivial. It may be fixed in POV-Ray 4.0, where the rendering engine will
be written again and this kind of things can be taken into account from
the very beginning.

===Can this problem be solved?===
You can get rid of the lighting artifact by applying
<code>double_illuminate</code> to the object in question.
When a surface is double illuminated, it does not matter which way its normal
points - it will always be illuminated regardless of which side the light
source is. Of course it should not matter that the object is now illuminated
from both sides. If this is a problem, then the problem is not easily
solvable.

Note that in the example given at the beginning of this
section
this solution does not work: It would illuminate the whole triangle with both
light sources! However, this solution works well with closed triangle meshes,
where the inner side of the mesh is shadowed by the mesh itself. However,
if you are using <code>no_shadow</code> in the object (for example to
get rid of
[[Documentation:Tutorial Section 4.3#The shadow line artifact|shadow line artifacts]]),
new problems can arise in the lighting (such as bright
parts in places where there should not be any; these are all cause by this
same problem).

The slope pattern is more problematic and there is no generic solution
which will work in all cases. Fortunately the most common use of the slope
pattern is in heightfields, and there a solution is possible:

If you are having this problem in a smooth heightfield, the solution is
to mirror the color_map (or whatever map you are using) around 0.5. This way
it does not matter if the normal is reversed. That is, if you had something
like this in a heightfield:

<pre>
slope y color_map
{ [0.50 rgb <.5,.5,.5>] // rock
[0.75 rgb <.8,.4,.1>] // ground
[1.00 rgb <.4,1,.4>] // grass
}
</pre>

you simply have to mirror the map around 0.5, ie. add the values from
0 to 0.5 in reverse order:

<pre>
slope y color_map
{ [0.00 rgb <.4,1,.4>] // grass
[0.25 rgb <.8,.4,.1>] // ground
[0.50 rgb <.5,.5,.5>] // rock
[0.75 rgb <.8,.4,.1>] // ground
[1.00 rgb <.4,1,.4>] // grass
}
</pre>

Besides this you should, of course, apply <code>double_illuminate</code>
to the heightfield in order to get the proper lighting.

 
<table width=100% border=0 cellspacing=0 cellpadding=5>
<tr><td width=50% bgcolor=#EEEEEF>
[[Documentation:Tutorial Section 4.2#CSG speed|CSG speed]]</td>
<td width=50% bgcolor=#EEEEEF align=right>
[[Documentation:Tutorial Section 5#Appendices|Appendices]]</td></tr>
</table>


 
<table width=100% border=1 cellspacing=0 cellpadding=5>
<tr><td width=100% bgcolor=#FFEEEE>
This document is protected, so submissions, corrections and discussions should be held on this documents [[Documentation_Talk:Tutorial Section 4.3|talk]] page.
</td></tr>
</table>

@@ Line 61: / Line 61: @@
 <p>You may also contact any of the POV-Ray T.A.G. members with suggestions,
 comments, or ideas for improvements to POV-Ray. You can learn more about the
-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>].
+POV-Ray T.A.G. and their contact information on the [http://tag.povray.org TAG web page].
 </p>
@@ Line 149: / Line 149: @@
 <p>There is no official GUI done for the Unix version of POV-Ray. Some
 third-parties have tried to make some GUIs for it (and you might find them
-in the [http://povray.org/links/|_new <span title="Opens A New Window!">links collection on our website</span>])
+in the [http://povray.org/links/ links collection on our website])
 but it seems to be a general phenomenon that Unix people like to use just
 the command-line version with a proper and powerful text editor (such as
@@ Line 307: / Line 307: @@
 </p>
 <p>This is a real problem that happens even to the best. For example, check
-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
+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
 in the closest rock)?

Documentation:Tutorial Section 4.3 - Revision history

Jholsenback: external link handling change after recent update

Jholsenback: Protected "Documentation:Tutorial Section 4.3" [edit=sysop:move=sysop]

Jholsenback: 1 revision(s)

WikiSysop: /* Can this problem be solved? */

← Older revision	Revision as of 18:19, 10 March 2009
(No difference)

← Older revision	Revision as of 18:02, 10 March 2009
(No difference)