Documentation:Tutorial Section 4.3

This document is protected, so submissions, corrections and discussions should be held on this documents talk page.

Does POV-Ray support 3DNow?

No, and most likely never will.

There are several good reasons for this:

• 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.)
• 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:
  1. 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.
  2. 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?

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.

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 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 -P 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 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.

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:

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

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.

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.

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).

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.

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 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:

1. 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.
2. 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.
3. If so, check if the closest intersection point of the shadow ray belongs to the current object.
4. If so, remove that intersection point from the list.

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:

1. 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).
2. 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.
3. 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).
4. 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).

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:

The source code of this image is the following:

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
}

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 double_illuminate 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 no_shadow in the object (for example to get rid of 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:

  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
  }

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

  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
  }

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

CSG speed

Appendices

This document is protected, so submissions, corrections and discussions should be held on this documents talk page.