Difference between revisions of "Documentation Talk:Tutorial Section 3"

Revision as of 11:22, 23 May 2016

First, we would like to digress a moment to talk about the difference between a lathe and a surface of revolution object (SOR). The SOR object, described in a separate tutorial, may seem terribly similar to the lathe at first glance. It too declares a series of points and connects them with curving lines and then rotates them around the y-axis. The lathe has advantages, such as linear, quadratic, cubic and bezier spline support.

Plus, the simpler mathematics used by a SOR does not allow the curve to double back over the same y-coordinates, thus, if using a SOR, any sudden twist which cuts back down over the same heights that the curve previously covered will trigger an error. For example, suppose we wanted a lathe to arc up from <0,0> to <2,2>, then to dip back down to <4,0>. Rotated around the y-axis, this would produce something like a gelatin mold - a rounded semi torus, hollow in the middle. But with the SOR, as soon as the curve doubled back on itself in the y-direction, it would become an illegal declaration.

picked up suggested changes -- jholsenback

Difference between revisions of "Documentation Talk:Tutorial Section 3"

Revision as of 11:22, 23 May 2016

Navigation menu

Search

@@ Line 1: / Line 1: @@
-<!--<wikitalk>--->
-<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 3|talk]] page.
-</td></tr>
-</table>
-<br>
-<!--</wikitalk>--->
-==Advanced Features==
-<!--<sectiondesc desc=<"advanced tutorial">--->
-===Spline Based Shapes===
-<!--<indexentry "Shapes, spline based">--->
-<p>After we have gained some experience with the simpler shapes available in
-POV-Ray it is time to go on to the more advanced, thrilling shapes.</p>
-<p>
-We should be aware that the shapes described in this and the following two chapters are not trivial to
-understand. We need not be worried though if we do not know how to use
-them or how they work. We just try the examples and play with the features
-described in the reference chapter. There is nothing better than learning by
-doing.</p>
-<p>
-You may wish to skip to the chapter &quot;<!--<linkto "Simple Texture Options">Simple Texture Options</linkto>--->[[Documentation:Tutorial Section 2.1#Simple Texture Options|Simple Texture Options]]&quot;
-before proceeding with these advanced shapes.</p>
-====Lathe Object====
-<!--<indexentry "lathe, tutorial">--->
-<p>In the real world, <code><!--<linkto "lathe">lathe</linkto>--->[[Documentation:Reference Section 4#Lathe|lathe]]</code> refers to a process of making
-patterned rounded shapes by spinning the source material in place and carving
-pieces out as it turns. The results can be elaborate, smoothly rounded,
-elegant looking artefacts such as table legs, pottery, etc. In POV-Ray, a
-lathe object is used for creating much the same kind of items, although we
-are referring to the object itself rather than the means of production.</p>
-<p>
-Here is some source for a really basic lathe.</p>
-<pre>
-  #include &quot;colors.inc&quot;
-  background{White}
-  camera {
-    angle 10
-    location &lt;1, 9, -50&gt;
-    look_at &lt;0, 2, 0&gt;
-  }
-  light_source {
-    &lt;20, 20, -20&gt; color White
-  }
-  lathe {
-    linear_spline
-,
-    &lt;0,0&gt;, &lt;1,1&gt;, &lt;3,2&gt;, &lt;2,3&gt;, &lt;2,4&gt;, &lt;0,4&gt;
-    pigment { Blue }
-    finish {
-      ambient .3
-      phong .75
-    }
-  }
-</pre>
-<p>[[Image:TutImgLatheobj.png|A simple lathe object.]]</p>
-<p>We render this, and what we see is a fairly simply type of lathe, which
-looks like a child's top. Let's take a look at how this code produced
-the effect.</p>
-<p>
-First, a set of six points is declared which the raytracer connects with
-lines. We note that there are only two components in the vectors which
-describe these points. The lines that are drawn are assumed to be in the
-x-y-plane, therefore it is as if all the z-components were assumed to be
-zero. The use of a two-dimensional vector is mandatory (Attempting to use a
-D vector would trigger an error... with one exception, which we will explore
-later in the discussion of splines).</p>
-<p>
-Once the lines are determined, the ray-tracer rotates this line around the
-y-axis, and we can imagine a trail being left through space as it goes, with
-the surface of that trail being the surface of our object.</p>
-<p>
-The specified points are connected with straight lines because we used the
-<code>linear_spline</code> keyword. There are other types of splines
-available with the lathe, which will result in smooth curving lines, and even
-rounded curving points of transition, but we will get back to that in a
-moment.</p>
 <p>
 First, we would like to digress a moment to talk about the difference
@@ Line 96: / Line 16: @@
 curve doubled back on itself in the y-direction, it would become an illegal
 declaration.</p>
-<p>
-Still, the SOR has one powerful strong point: because it uses simpler order
-mathematics, it generally tends to render faster than an equivalent lathe. So
-in the end, it is a matter of: we use a SOR if its limitations will allow, but
-when we need a more flexible shape, we go with the lathe instead.</p>
-=====Understanding The Concept of Splines=====
-<!--<indexentry "Splines, understanding the concept of">--->
-<p>It would be helpful, in order to understand splines, if we had a sort of
-<em>Spline Workshop</em> where we could practice manipulating types and
-points of splines and see what the effects were like. So let's make one!
-Now that we know how to create a basic lathe, it will be easy:</p>
-<pre>
-#include &quot;colors.inc&quot;
-  camera {
-    orthographic
-    up &lt;0, 5, 0&gt;
-    right &lt;5, 0, 0&gt;
-    location &lt;2.5, 2.5, -100&gt;
-    look_at &lt;2.5, 2.5, 0&gt;
-  }
-  /* set the control points to be used */
-  #declare Red_Point    = &lt;1.00, 0.00&gt;;
-  #declare Orange_Point = &lt;1.75, 1.00&gt;;
-  #declare Yellow_Point = &lt;2.50, 2.00&gt;;
-  #declare Green_Point  = &lt;2.00, 3.00&gt;;
-  #declare Blue_Point   = &lt;1.50, 4.00&gt;;
-  /* make the control points visible */
-  cylinder { Red_Point, Red_Point - &lt;0,0,20&gt;, .1
-    pigment { Red }
-    finish { ambient 1 }
-  }
-  cylinder { Orange_Point, Orange_Point - &lt;0,0,20&gt;, .1
-    pigment { Orange }
-    finish { ambient 1 }
-  }
-  cylinder { Yellow_Point, Yellow_Point - &lt;0,0,20&gt;, .1
-    pigment { Yellow }
-    finish { ambient 1 }
-  }
-  cylinder { Green_Point, Green_Point - &lt;0,0,20&gt;, .1
-    pigment { Green }
-    finish { ambient 1 }
-  }
-  cylinder { Blue_Point, Blue_Point- &lt;0,0,20&gt;, .1
-    pigment { Blue }
-    finish { ambient 1 }
-  }
-  /* something to make the curve show up */
-  lathe {
-    linear_spline
-,
-    Red_Point,
-    Orange_Point,
-    Yellow_Point,
-    Green_Point,
-    Blue_Point
-    pigment { White }
-    finish { ambient 1 }
-  }
-</pre>
-<p><!--<img src="tut_img/spline.png" alt="A simple &quot;Spline Workshop&quot;.">--->[[Image:TutImgSpline.png|A simple Spline Workshop]]</p>
-<p>Now, we take a deep breath. We know that all looks a bit weird, but with
-some simple explanations, we can easily see what all this does.</p>
-<p>
-First, we are using the orthographic camera. If we have not read up on
-that yet, a quick summary is: it renders the scene <em>flat</em>, eliminating
-perspective distortion so that in a side view, the objects look like they
-were drawn on a piece of graph paper (like in the side view of a modeler or
-CAD package). There are several uses for this practical new type of camera,
-but here it is allowing us to see our lathe and cylinders<em> edge on</em>,
-so that what we see is almost like a cross section of the curve which makes
-the lathe, rather than the lathe itself. To further that effect, we
-eliminated shadowing with the <code>ambient 1</code> finish, which of course
-also eliminates the need for lighting. We have also positioned this
-particular side view so that &lt;0,0&gt; appears at the lower left of our
-scene.</p>
-<p>
-Next, we declared a set of points. We note that we used 3D vectors for these
-points rather than the 2D vectors we expect in a lathe. That is the
-exception we mentioned earlier. When we declare a 3D point, then use it in a
-lathe, the lathe only uses the first two components of the vector, and
-whatever is in the third component is simply ignored. This is handy here,
-since it makes this example possible.</p>
-<p>
-Next we do two things with the declared points. First we use them to place
-small diameter cylinders at the locations of the points with the circular
-caps facing the camera. Then we re-use those same vectors to determine the
-lathe.</p>
-<p>
-Since trying to declare a 2D vector can have some odd results, and is not
-really what our cylinder declarations need anyway, we can take advantage of
-the lathe's tendency to ignore the third component by just setting the
-z-coordinate in these 3D vectors to zero.</p>
-<p>
-The end result is: when we render this code, we see a white lathe against a
-black background showing us how the curve we have declared looks, and the
-circular ends of the cylinders show us where along the x-y-plane our control
-points are. In this case, it is very simple. The linear spline has been
-used so our curve is just straight lines zig-zagging between the points. We
-change the declarations of <code>Red_Point</code> and <code>Blue_Point</code>
-to read as follows.</p>
-<pre>
-  #declare Red_Point  = &lt;2.00, 0.00&gt;;
-  #declare Blue_Point = &lt;0.00, 4.00&gt;;
-</pre>
-<p>[[Image:TutImgMvspline.png|Moving some points of the spline.]]</p>
-<p>We re-render and, as we can see, all that happens is that the straight
-line segments just move to accommodate the new position of the red and blue
-points. Linear splines are so simple, we could manipulate them in our sleep,
-no?</p>
-<p>
-Let's try something different. First, we change the points to the
-following.</p>
-<pre>
-  #declare Red_Point    = &lt;1.00, 0.00&gt;;
-  #declare Orange_Point = &lt;2.00, 1.00&gt;;
-  #declare Yellow_Point = &lt;3.50, 2.00&gt;;
-  #declare Green_Point  = &lt;2.00, 3.00&gt;;
-  #declare Blue_Point   = &lt;1.50, 4.00&gt;;
-</pre>
-<p>[[Image:TutImgQuspline.png|A quadratic spline lathe.]]</p>
-<p>We then go down to the lathe declaration and change <code>linear_spline</code>
-to <code>quadratic_spline</code>. We re-render and what do we have? Well,
-there is a couple of things worthy of note this time. First, we will see
-that instead of straight lines we have smooth arcs connecting the points.
-These arcs are made from quadratic curves, so our lathe looks much more
-interesting this time. Also, <code>Red_Point</code> is no longer connected
-to the curve. What happened?</p>
-<p>
-Well, while any two points can determine a straight line, it takes three to
-determine a quadratic curve. POV-Ray looks not only to the two points to be
-connected, but to the point immediately preceding them to determine the
-formula of the quadratic curve that will be used to connect them. The problem
-comes in at the beginning of the curve. Beyond the first point in the curve
-there is no <em>previous</em> point. So we need to declare one. Therefore,
-when using a quadratic spline, we must remember that the first point we
-specify is only there so that POV-Ray can determine what curve to connect the
-first two points with. It will not show up as part of the actual curve.</p>
-<p>
-There is just one more thing about this lathe example. Even though our
-curve is now put together with smooth curving lines, the transitions between
-those lines is... well, kind of choppy, no? This curve looks like the lines
-between each individual point have been terribly mismatched. Depending on
-what we are trying to make, this could be acceptable, or, we might long for a
-more smoothly curving shape. Fortunately, if the latter is true, we have
-another option.</p>
-<p>
-The quadratic spline takes longer to render than a linear spline. The math
-is more complex. Taking longer still is the cubic spline, yet for a really
-smoothed out shape this is the only way to go. We go back into our example,
-and simply replace <code>quadratic_spline</code> with <code>
-cubic_spline</code>. We render one more
-time, and take a look at what we have.</p>
-<p>[[Image:TutImgCuspline.png|A cubic spline lathe.]]</p>
-<p> While a quadratic spline takes three points to determine the curve, a
-cubic needs four. So, as we might expect, <code>Blue_Point</code> has now
-dropped out of the curve, just as <code>Red_Point</code> did, as the first
-and last points of our curve are now only control points for shaping the
-curves between the remaining points. But look at the transition from <code>
-Orange_Point</code> to <code>Yellow_Point</code> and then back to <code>
-Green_Point</code>. Now, rather than looking mismatched, our curve segments
-look like one smoothly joined curve.</p>
-<p> finally there is another kind of quadratic spline, the <code>bezier_spline</code>.
-This one takes four points per section. The start point, the end points and in between,
-two control points. To use it, we will have to make a few changes to our work shop.
-Delete the Yellow point, delete the Yellow cylinder. Change the points to:</p>
-<pre>
-  #declare Red_Point    = &lt;2.00, 1.00&gt;;
-  #declare Orange_Point = &lt;3.00, 1.50&gt;;
-  #declare Green_Point  = &lt;3.00, 3.50&gt;;
-  #declare Blue_Point   = &lt;2.00, 4.00&gt;;
-</pre>
-<p>And change the lathe to:</p>
-<pre>
-  lathe {
-    bezier_spline
-,
-    Red_Point,
-    Orange_Point,
-    Green_Point,
-    Blue_Point
-    pigment { White }
-    finish { ambient 1 }
-  }
-</pre>
-<p> The, green and orange, control points are not connected to the curve. Move them around a bit,
-for example <code>#declare Orange_Point = &lt;1.00, 1.50&gt;;</code>. The line that can be drawn
-from the start point to its closest control point (red to orange) shows the tangent of the curve
-at the start point. Same for the end point, blue to green.</p>
-<p>[[Image:TutImgBezspline1.png|a bezier_spline lathe]]</p>
-<p> One spline segment is nice, two is nicer. So we will add another segment and connect it to the
-blue point. One segment has four points, so two segments have eight. The first point of the second
-segment is the same as the last point of the first segment. The blue point. So we only have to
-declare three more points. Also we have to move the camera a bit and add more cylinders. Here is
-the complete scene again:</p>
-<pre>
-#include &quot;colors.inc&quot;
-  camera {
-    orthographic
-    up &lt;0, 7, 0&gt;
-    right &lt;7, 0, 0&gt;
-    location &lt;3.5, 4, -100&gt;
-    look_at &lt;3.5, 4, 0&gt;
-  }
-  /* set the control points to be used */
-  #declare Red_Point    = &lt;2.00, 1.00&gt;;
-  #declare Orange_Point = &lt;1.00, 1.50&gt;;
-  #declare Green_Point  = &lt;3.00, 3.50&gt;;
-  #declare Blue_Point   = &lt;2.00, 4.00&gt;;
-  #declare Green_Point2 = &lt;3.00, 4.50&gt;;
-  #declare Orange_Point2= &lt;1.00, 6.50&gt;;
-  #declare Red_Point2   = &lt;2.00, 7.00&gt;;
-  /* make the control points visible */
-  cylinder { Red_Point, Red_Point - &lt;0,0,20&gt;, .1
-    pigment { Red } finish { ambient 1 }
-  }
-  cylinder { Orange_Point, Orange_Point - &lt;0,0,20&gt;, .1
-    pigment { Orange } finish { ambient 1 }
-  }
-  cylinder { Green_Point, Green_Point - &lt;0,0,20&gt;, .1
-    pigment { Green } finish { ambient 1 }
-  }
-  cylinder { Blue_Point, Blue_Point- &lt;0,0,20&gt;, .1
-    pigment { Blue } finish { ambient 1 }
-  }
-  cylinder { Green_Point2, Green_Point2 - &lt;0,0,20&gt;, .1
-    pigment { Green } finish { ambient 1 }
-  }
-  cylinder { Orange_Point2, Orange_Point2 - &lt;0,0,20&gt;, .1
-    pigment { Orange } finish { ambient 1 }
-  }
-  cylinder { Red_Point2, Red_Point2 - &lt;0,0,20&gt;, .1
-    pigment { Red } finish { ambient 1 }
-  }
-  /* something to make the curve show up */
-  lathe {
-    bezier_spline
-,
-    Red_Point, Orange_Point, Green_Point, Blue_Point
-    Blue_Point, Green_Point2, Orange_Point2, Red_Point2
-    pigment { White }
-    finish { ambient 1 }
-  }
-</pre>
-<p>[[Image:TutImgBezspline2.png|two bezier_spline segments, not smooth]]</p>
-<p>
-A nice curve, but what if we want a smooth curve? Let us have a look at the tangents
-on the Blue_point, draw the lines Green_Point, Blue_point and Green_Point2, Blue_point.
-Look at the angle they make, it is as sharp as the dent in the curve. What if we make
-the angle bigger? What if we make the angle 180°? Try a few positions for Green_point2
-and end with <code>#declare Green_Point2 = &lt;1.00, 4.50&gt;;</code>. A smooth curve.
-If we make sure that the two control points and the connection point are on one line,
-the curve is perfectly smooth. In general this can be achieved by
-<code>#declare Green_Point2 = Blue_Point+(Blue_Point-Green_Point);</code></p>
-<p>[[Image:TutImgBezspline3.png|smooth bezier_spline lathe]]</p>
-<p> The concept of splines is a handy and necessary one, which will be seen
-again in the prism and polygon objects. But with a little tinkering we can
-quickly get a feel for working with them.</p>
-====Surface of Revolution Object====
-<!--<indexentry "sor, tutorial">--->
-<p>Bottles, vases and glasses make nice objects in ray-traced scenes. We want
-to create a golden cup using the <em>surface of revolution</em> object (SOR
-object).</p>
-<p>
-We first start by thinking about the shape of the final object. It is quite
-difficult to come up with a set of points that describe a given curve without
-the help of a modeling program supporting POV-Ray's surface of revolution
-object. If such a program is available we should take advantage of it.</p>
-<p>[[Image:TutImgPtcubobj.gif|The point configuration of our cup object.]]</p>
-<p>We will use the point configuration shown in the figure above. There are
-eight points describing the curve that will be rotated about the y-axis to
-get our cup. The curve was calculated using the method described in the
-reference section (see &quot;<!--<linkto "Surface of Revolution">Surface of Revolution</linkto>--->[[Documentation:Reference Section 4.1#Surface of Revolution|Surface of Revolution]]&quot;).</p>
-<p>
-Now it is time to come up with a scene that uses the above SOR object. We
-create a file called <code>sordemo.pov</code> and enter the following text.</p>
-<pre>
-  #include &quot;colors.inc&quot;
-  #include &quot;golds.inc&quot;
-  camera {
-    location &lt;10, 15, -20&gt;
-    look_at &lt;0, 5, 0&gt;
-    angle 45
-  }
-  background { color rgb&lt;0.2, 0.4, 0.8&gt;  }
-  light_source { &lt;100, 100, -100&gt; color rgb 1 }
-  plane {
-    y, 0
-    pigment { checker color Red, color Green scale 10 }
-  }
-  sor {
-,
-    &lt;0.0,  -0.5&gt;,
-    &lt;3.0,   0.0&gt;,
-    &lt;1.0,   0.2&gt;,
-    &lt;0.5,   0.4&gt;,
-    &lt;0.5,   4.0&gt;,
-    &lt;1.0,   5.0&gt;,
-    &lt;3.0,  10.0&gt;,
-    &lt;4.0,  11.0&gt;
-    open
-    texture { T_Gold_1B }
-  }
-</pre>
-<p>The scene contains our cup object resting on a checkered plane. Tracing
-this scene results in the image below.</p>
-<p>[[Image:TutImgSorobj.png|A surface of revolution object.]]</p>
-<p>The surface of revolution is described by starting with the number of
-points followed by the points. Points from second to last but one are listed
-with ascending heights. Each of them determines the radius of the curve for
-a given height. E. g. the first valid point (second listed) tells POV-Ray
-that at height 0.0 the radius is 3. We should take care that each point has
-a larger height than its predecessor. If this is not the case the program
-will abort with an error message. First and last point from the list are
-used to determine slope at beginning and end of curve and can be defined for
-any height.</p>
-====Prism Object====
-<!--<indexentry "prism, tutorial">--->
-<p>The prism is essentially a polygon or closed curve which is swept along a
-linear path. We can imagine the shape so swept leaving a trail in space, and
-the surface of that trail is the surface of our prism. The curve or polygon
-making up a prism's face can be a composite of any number of sub-shapes,
-can use any kind of three different splines, and can either keep a constant
-width as it is swept, or slowly tapering off to a fine point on one end. But
-before this gets too confusing, let's start one step at a time with the
-simplest form of prism. We enter and render the following POV code (see file
-<code>prismdm1.pov</code>).</p>
-<pre>
-  #include &quot;colors.inc&quot;
-  background{White}
-  camera {
-    angle 20
-    location &lt;2, 10, -30&gt;
-    look_at &lt;0, 1, 0&gt;
-  }
-  light_source { &lt;20, 20, -20&gt; color White }
-  prism {
-    linear_sweep
-    linear_spline
-, // sweep the following shape from here ...
-, // ... up through here
-, // the number of points making up the shape ...
-    &lt;3,5&gt;, &lt;-3,5&gt;, &lt;-5,0&gt;, &lt;-3,-5&gt;, &lt;3, -5&gt;, &lt;5,0&gt;, &lt;3,5&gt;
-    pigment { Green }
-  }
-</pre>
-<p>[[Image:TutImgHexprism.png|A hexagonal prism shape.]]</p>
-<p>This produces a hexagonal polygon, which is then swept from y=0 through
-y=1. In other words, we now have an extruded hexagon. One point to note is
-that although this is a six sided figure, we have used a total of seven
-points. That is because the polygon is supposed to be a closed shape, which
-we do here by making the final point the same as the first. Technically, with
-linear polygons, if we did not do this, POV-Ray would automatically join
-the two ends with a line to force it to close, although a warning would be
-issued. However, this only works with linear splines, so we must not get
-too casual about those warning messages!</p>
-=====Teaching An Old Spline New Tricks=====
-<!--<indexentry "Spline, new tricks" "cubic_spline, tutorial">--->
-<p>If we followed the section on splines covered under the lathe tutorial
-(see section &quot;<!--<linkto "Understanding The Concept of Splines">Understanding The Concept of Splines</linkto>--->[[Documentation:Tutorial Section 3#Understanding The Concept of Splines|Understanding The Concept of Splines]]&quot;), we know that
-there are two additional kinds of splines besides linear: the quadratic and
-the cubic spline. Sure enough, we can use these with prisms to make a more
-free form, smoothly curving type of prism.</p>
-<p>
-There is just one catch, and we should read this section carefully to keep
-from tearing our hair out over mysterious &quot;too few points in prism&quot;
-messages which keep our prism from rendering. We can probably guess where
-this is heading: how to close a non-linear spline. Unlike the linear spline,
-which simply draws a line between the last and first points if we forget to
-make the last point equal to the first, quadratic and cubic splines are a
-little more fussy.</p>
-<p>
-First of all, we remember that quadratic splines determine the equation of
-the curve which connects any two points based on those two points and the
-previous point, so the first point in any quadratic spline is just <em>
-control point</em> and will not actually be part of the curve. What this
-means is: when we make our shape out of a quadratic spline, we must match the
-second point to the last, since the first point is not on the curve -
-it is just a control point needed for computational purposes.</p>
-<p>
-Likewise, cubic splines need both the first and last points to be control
-points, therefore, to close a shape made with a cubic spline, we must match
-the second point to the second from last point. If we do not match the
-correct points on a quadratic or cubic shape, that is when we will get the
-&quot;too few points in prism&quot; error. POV-Ray is still waiting for us to
-close the shape, and when it runs out of points without seeing the closure,
-an error is issued.</p>
-<p>
-Confused? Okay, how about an example? We replace the prism in our last bit
-of code with this one (see file <code>prismdm2.pov</code>).</p>
-<pre>
-  prism {
-    cubic_spline
-, // sweep the following shape from here ...
-, // ... up through here
-, // the number of points making up the shape ...
-    &lt; 3, -5&gt;, // point#1 (control point... not on curve)
-    &lt; 3,  5&gt;, // point#2  ... THIS POINT ...
-    &lt;-5,  0&gt;, // point#3
-    &lt; 3, -5&gt;, // point#4
-    &lt; 3,  5&gt;, // point#5 ... MUST MATCH THIS POINT
-    &lt;-5,  0&gt;  // point#6 (control point... not on curve)
-    pigment { Green }
-  }
-</pre>
-<p>[[Image:TutImgCubprism.png|A cubic, triangular prism shape.]]</p>
-<p>This simple prism produces what looks like an extruded triangle with its
-corners sanded smoothly off. Points two, three and four are the corners of
-the triangle and point five closes the shape by returning to the location of
-point two. As for points one and six, they are our control points, and
-are not part of the shape - they are just there to help compute what
-curves to use between the other points.</p>
-=====Smooth Transitions=====
-<p>Now a handy thing to note is that we have made point one equal point four,
-and also point six equals point three. Yes, this is important. Although this
-prism would still be legally closed if the control points were not what
-we have made them, the curve transitions between points would not be as
-smooth. We change points one and six to &lt;4,6&gt; and &lt;0,7&gt;
-respectively and re-render to see how the back edge of the shape is altered
-(see file <code>prismdm3.pov</code>).</p>
-<p>
-To put this more generally, if we want a smooth closure on a cubic spline,
-we make the first control point equal to the third from last point, and the
-last control point equal to the third point. On a quadratic spline, the trick
-is similar, but since only the first point is a control point, make that
-equal to the second from last point.</p>
-=====Multiple Sub-Shapes=====
-<p>Just as with the polygon object (see section
-&quot;<!--<linkto "Polygon Object">Polygon Object</linkto>--->[[Documentation:Tutorial Section 3.1#Polygon Object|Polygon Object]]&quot;)
-the prism is very flexible, and allows us to make one prism out of several
-sub-prisms. To do this, all we need to do is keep listing points after we
-have already closed the first shape. The second shape can be simply an add on
-going off in another direction from the first, but one of the more
-interesting features is that if any even number of sub-shapes overlap, that
-region where they overlap behaves as though it has been cut away from both
-sub-shapes. Let's look at another example. Once again, same basic code as
-before for camera, light and so forth, but we substitute this complex prism
-(see file <code>prismdm4.pov</code>).</p>
-<pre>
-  prism {
-    linear_sweep
-    cubic_spline
-,  // sweep the following shape from here ...
-,  // ... up through here
-, // the number of points making up the shape ...
-    &lt;3,-5&gt;, &lt;3,5&gt;, &lt;-5,0&gt;, &lt;3, -5&gt;, &lt;3,5&gt;, &lt;-5,0&gt;,//sub-shape #1
-    &lt;2,-4&gt;, &lt;2,4&gt;, &lt;-4,0&gt;, &lt;2,-4&gt;, &lt;2,4&gt;, &lt;-4,0&gt;, //sub-shape #2
-    &lt;1,-3&gt;, &lt;1,3&gt;, &lt;-3,0&gt;, &lt;1, -3&gt;, &lt;1,3&gt;, &lt;-3,0&gt; //sub-shape #3
-    pigment { Green }
-  }
-</pre>
-<p>[[Image:TutImgSubshape.png|Using sub-shapes to create a more complex shape.]]</p>
-<p>For readability purposes, we have started a new line every time we moved
-on to a new sub-shape, but the ray-tracer of course tells where each shape
-ends based on whether the shape has been closed (as described earlier). We
-render this new prism, and look what we have got. It is the same
-familiar shape, but it now looks like a smaller version of the shape has been
-carved out of the center, then the carved piece was sanded down even smaller
-and set back in the hole.</p>
-<p>
-Simply, the outer rim is where only sub-shape one exists, then the carved
-out part is where sub-shapes one and two overlap. In the extreme center, the
-object reappears because sub-shapes one, two, and three overlap, returning us
-to an odd number of overlapping pieces. Using this technique we could make
-any number of extremely complex prism shapes!</p>
-=====Conic Sweeps And The Tapering Effect=====
-<!--<indexentry "Tapering Conic Sweeps">--->
-<p>In our original prism, the keyword <code>linear_sweep</code> is actually
-optional. This is the default sweep assumed for a prism if no type of sweep
-is specified. But there is another, extremely useful kind of sweep: the conic
-sweep. The basic idea is like the original prism, except that while we are
-sweeping the shape from the first height through the second height, we are
-constantly expanding it from a single point until, at the second height, the
-shape has expanded to the original points we made it from. To give a small
-idea of what such effects are good for, we replace our existing prism with
-this (see file <code>prismdm4.pov</code>):</p>
-<pre>
-  prism {
-    conic_sweep
-    linear_spline
-, // height 1
-, // height 2
-, // the number of points making up the shape...
-    &lt;4,4&gt;,&lt;-4,4&gt;,&lt;-4,-4&gt;,&lt;4,-4&gt;,&lt;4,4&gt;
-    rotate &lt;180, 0, 0&gt;
-    translate &lt;0, 1, 0&gt;
-    scale &lt;1, 4, 1&gt;
-    pigment { gradient y scale .2 }
-  }
-</pre>
-<p>[[Image:TutImgPyrsweep.png|Creating a pyramid using conic sweeping.]]</p>
-<p>The gradient pigment was selected to give some definition to our object
-without having to fix the lights and the camera angle right at this moment,
-but when we render it, what have we created? A horizontally striped
-pyramid! By now we can recognize the linear spline connecting the four points
-of a square, and the familiar final point which is there to close the
-spline.</p>
-<p>
-Notice all the transformations in the object declaration. That is going
-to take a little explanation. The rotate and translate are easy. Normally, a
-conic sweep starts full sized at the top, and tapers to a point at y=0, but
-of course that would be upside down if we are making a pyramid. So we flip
-the shape around the x-axis to put it right side up, then since we actually
-orbited around the point, we translate back up to put it in the same position
-it was in when we started.</p>
-<p>
-The scale is to put the proportions right for this example. The base is
-eight units by eight units, but the height (from y=1 to y=0) is only one
-unit, so we have stretched it out a little. At this point, we are
-probably thinking, &quot;why not just sweep up from y=0 to y=4 and avoid this
-whole scaling thing?&quot;</p>
-<p>
-That is a very important gotcha! with conic sweeps. To see what is wrong
-with that, let's try and put it into practice (see file <code>
-prismdm5.pov</code>). We must make sure to remove the scale statement, and
-then replace the line which reads</p>
-<pre>
-, // height 2
-</pre>
-<p>with</p>
-<pre>
-, // height 2
-</pre>
-<p>This sets the second height at y=4, so let's re-render and see if the
-effect is the same.</p>
-<p>[[Image:TutImgImprswep.png|Choosing a second height larger than one for the conic sweep.]]</p>
-<p>Whoa! Our height is correct, but our pyramid's base is now huge! What
-went wrong here? Simple. The base, as we described it with the points we used
-actually occurs at y=1 no matter what we set the second height for. But if we
-do set the second height higher than one, once the sweep passes y=1, it keeps
-expanding outward along the same lines as it followed to our original base,
-making the actual base bigger and bigger as it goes.</p>
-<p>
-To avoid losing control of a conic sweep prism, it is usually best to let
-the second height stay at y=1, and use a scale statement to adjust the height
-from its unit size. This way we can always be sure the base's corners
-remain where we think they are.</p>
-<p>
-That leads to one more interesting thing about conic sweeps. What if we for
-some reason do not want them to taper all the way to a point? What if
-instead of a complete pyramid, we want more of a ziggurat step? Easily done.
-After putting the second height back to one, and replacing our scale
-statement, we change the line which reads</p>
-<pre>
-, // height 1
-</pre>
-<p>to</p>
-<pre>
-.251, // height 1
-</pre>
-<p>[[Image:TutImgSweepinc.png|Increasing the first height for the conic sweep.]]</p>
-<p>When we re-render, we see that the sweep stops short of going all the way
-to its point, giving us a pyramid without a cap. Exactly how much of the cap
-is cut off depends on how close the first height is to the second height.</p>
-====Sphere Sweep Object====
-<!--<indexentry "sphere_sweep, tutorial">--->
-<p>A Sphere Sweep Object is the space a sphere occupies during its movement along a spline.
-<br>So we need to specify the kind of spline we want and a list of control points to define
-that spline. To help POV-Ray we tell how many control points will be used. In addition, we also
-define the radius the moving sphere should have when passing through each of these control
-points.</p>
-<p>The syntax of the sphere_sweep object is:</p>
-<pre>
-  sphere_sweep {
-    linear_spline | b_spline | cubic_spline
-    NUM_OF_SPHERES,
-    CENTER, RADIUS,
-    CENTER, RADIUS,
-    ...
-    CENTER, RADIUS
-    [tolerance DEPTH_TOLERANCE]
-    [OBJECT_MODIFIERS]
-  }
-</pre>
-<p>An example for a linear Sphere Sweep would be:</p>
-<pre>
-  sphere_sweep {
-    linear_spline
-,
-    &lt;-5, -5, 0&gt;, 1
-    &lt;-5,  5, 0&gt;, 1
-    &lt; 5, -5, 0&gt;, 1
-    &lt; 5,  5, 0&gt;, 1
-  }
-</pre>
-<p>This object is described by four spheres. You can use as many spheres as you like to
-describe the object, but you will need at least two spheres for a linear Sphere Sweep, and
-four spheres for one approximated with a cubic_spline or b_spline.</p>
-<p>The example above would result in an object shaped like the letter &quot;N&quot;. The
-sphere sweep goes through <em>all</em> points which are connected with straight
-cones.</p>
-<p>Changing the kind of interpolation to a cubic_spline produces a quite different,
-slightly bent, object. It then starts at the second sphere and ends at the last but one. Since
-the first and last points are used to control the spline, you need two more points to get a
-shape that can be compared to the linear sweep. Let's add them:</p>
-<pre>
-  sphere_sweep {
-    cubic_spline
-,
-    &lt;-4, -5, 0&gt;, 1
-    &lt;-5, -5, 0&gt;, 1
-    &lt;-5,  5, 0&gt;, 0.5
-    &lt; 5, -5, 0&gt;, 0.5
-    &lt; 5,  5, 0&gt;, 1
-    &lt; 4,  5, 0&gt;, 1
-    tolerance 0.1
- }
-</pre>
-<p>So the cubic sweep creates a smooth sphere sweep actually going through
-all points (except the first and last one). In this example the radius of the second and third
-spheres have been changed. We also added the &quot;tolerance&quot; keyword, because
-dark spots appeared on the surface with the default value (0.000001).</p>
-<p>When using a b_spline, the resulting object is somewhat similar to the cubic
-sweep, but does not actually go through the control points. It lies somewhere between them.</p>
-====Bicubic Patch Object====
-<!--<indexentry "bicubic_patch, tutorial">--->
-<p>
-Bicubic patches are useful surface representations because they allow an easy definition
-of surfaces using only a few control points. The control points serve to determine the shape
-of the patch. Instead of defining the vertices of triangles, we simply give the coordinates
-of the control points. A single patch has 16 control points, one at each corner, and the rest
-positioned to divide the patch into smaller sections. POV-Ray does not ray trace the patches
-directly, they are approximated using triangles as described in the
-<!--<linkto "bezier">Scene Description Language</linkto>--->[[Documentation:Reference Section 4.1#Bicubic Patch|Scene Description Language]] section.
-</p>
-<p>
-Bicubic patches are almost always created by using a third party modeler, but for this tutorial
-we will manipulate them by hand. Modelers that support Bicubic patches and export to POV-Ray
-can be found in the [http://www.povray.org/links/ links collection on our server]<br>
-Let's set up a basic scene and start exploring the Bicubic patch.
-</p>
-<pre>
-#version 3.5;
-global_settings {assumed_gamma 1.0}
-background {rgb &lt;1,0.9,0.9&gt;}
-camera {location &lt;1.6,5,-6&gt; look_at &lt;1.5,0,1.5&gt; angle 40}
-light_source {&lt;500,500,-500&gt; rgb 1 }
-#declare B11=&lt;0,0,3&gt;; #declare B12=&lt;1,0,3&gt;; //
-#declare B13=&lt;2,0,3&gt;; #declare B14=&lt;3,0,3&gt;; // row 1
-#declare B21=&lt;0,0,2&gt;; #declare B22=&lt;1,0,2&gt;; //
-#declare B23=&lt;2,0,2&gt;; #declare B24=&lt;3,0,2&gt;; // row 2
-#declare B31=&lt;0,0,1&gt;; #declare B32=&lt;1,0,1&gt;; //
-#declare B33=&lt;2,0,1&gt;; #declare B34=&lt;3,0,1&gt;; // row 3
-#declare B41=&lt;0,0,0&gt;; #declare B42=&lt;1,0,0&gt;; //
-#declare B43=&lt;2,0,0&gt;; #declare B44=&lt;3,0,0&gt;; // row 4
-bicubic_patch {
-   type 1 flatness 0.001
-   u_steps 4 v_steps 4
-   uv_vectors
-   &lt;0,0&gt; &lt;1,0&gt; &lt;1,1&gt; &lt;0,1&gt;
-   B11, B12, B13, B14
-   B21, B22, B23, B24
-   B31, B32, B33, B34
-   B41, B42, B43, B44
-   uv_mapping
-   texture {
-      pigment {
-         checker
-         color rgbf &lt;1,1,1,0.5&gt;
-         color rgbf &lt;0,0,1,0.7&gt;
-         scale 1/3
-      }
-      finish {phong 0.6 phong_size 20}
-   }
-   no_shadow
-}
-</pre>
-<p>
-The points B11, B14, B41, B44 are the corner points of the patch.
-All other points are control points. The names of the declared points are as follows:
-B for the colour of the patch, the first digit gives the row number, the second digit
-the column number. If you render the above scene, you will get a blue &amp; white
-checkered square, not very exciting. First we will add some spheres to make the control
-points visible. As we do not want to type the code for 16 spheres, we will use
-an array and a while loop to construct the spheres.
-</p>
-<pre>
-#declare Points=array[16]{
-   B11, B12, B13, B14
-   B21, B22, B23, B24
-   B31, B32, B33, B34
-   B41, B42, B43, B44
-}
-#declare I=0;
-#while (I&lt;16)
-   sphere {
-      Points[I],0.1
-      no_shadow
-      pigment{
-         #if (I=0|I=3|I=12|I=15)
-            color rgb &lt;1,0,0&gt;
-         #else
-            color rgb &lt;0,1,1&gt;
-         #end
-      }
-   }
-   #declare I=I+1;
-#end
-</pre>
-<p>
-Rendering this scene will show the patch with its corner points in red and its control
-points in cyan. Now it is time to start exploring.
-<br>
-Change B41 to <code>&lt;-1,0,0&gt;</code> and render.<br>
-Change B41 to <code>&lt;-1,1,0&gt;</code> and render.<br>
-Change B41 to <code>&lt; 1,2,1&gt;</code> and render.<br>
-</p>
-<p>
-Let's do some exercise with the control points. Start with a flat patch again.<br>
-Change B42 to <code>&lt;1,2,0&gt;</code> and B43 to <code>&lt;2,-2,0&gt;</code> and render.<br>
-Change B42 and B43 back to their original positions and try B34 to <code>&lt;4,2,1&gt;</code>
-and B24 to <code>&lt;2,-2,2&gt;</code> and render. Move the points around some more, also
-try the control points in the middle.
-</p>
-<p>[[Image:TutImgBpatch01.png|Bicubic_patch with control points]]</p>
-<p>
-After all this we notice two things: </p>
-<ul type="disc">
-<li> The patch always goes through the corner points.</li>
-<li> In most situations the patch does not go through the control points. </li>
-</ul>
-<p>
-Now go back to our spline work shop and have a look at the bezier_spline again. Indeed,
-the points B11,B12,B13,B14, make up a bezier_spline. So do the points B11,B21,B31,B41
-and B41,B42,B43,B44 and B14,B24,B34,B44.
-</p>
-<p>
-So far we have only been looking at one single patch, but one of the strengths of the
-Bicubic patch lays in the fact that they can be connected smoothly, to form bigger shapes.
-The process of connecting is relatively simple as there are actually only two rules to
-follow. It can be done by using a well set up set of macros or by using a modeler. To give
-an idea what is needed we will do a simple example by hand.
-</p>
-<p>
-First put the patch in our scene back to its flat position. Then
-change<code> #declare B14 = &lt;3,0,3&gt;; #declare B24 = &lt;3,2,2&gt;; #declare B34 = &lt;3.5,1,1&gt;; #declare B44 = &lt;3,-1,0&gt;; #declare B41 = &lt;0,-1,0&gt;;</code> Move the camera a bit back
-<code>camera { location &lt;3.1,7,-8&gt; look_at &lt;3,-2,1.5&gt; angle 40 }</code> and delete
-all the code for the spheres. We will now try and stitch a patch to the right side of the
-current one. Off course the points on the left side (column 1) of the new patch have to be
-in the same position as the points on the right side (column 4) of the blue one.<br>
-Render the scene, including our new patch:
-</p>
-<pre>
-#declare R11=B14; #declare R12=&lt;4,0,3&gt;;     //
-#declare R13=&lt;5,0,3&gt;; #declare R14=&lt;6,0,3&gt;; // row 1
-#declare R21=B24; #declare R22=&lt;4,0,2&gt;;     //
-#declare R23=&lt;5,0,2&gt;; #declare R24=&lt;6,0,2&gt;; // row 2
-#declare R31=B34; #declare R32=&lt;4,0,1&gt;;     //
-#declare R33=&lt;5,0,1&gt;; #declare R34=&lt;6,0,1&gt;; // row 3
-#declare R41=B44; #declare R42=&lt;4,0,0&gt;;     //
-#declare R43=&lt;5,0,0&gt;; #declare R44=&lt;6,0,0&gt;; // row 4
-bicubic_patch {
-   type 1 flatness 0.001
-   u_steps 4 v_steps 4
-   uv_vectors
-   &lt;0,0&gt; &lt;1,0&gt; &lt;1,1&gt; &lt;0,1&gt;
-   R11, R12, R13, R14
-   R21, R22, R23, R24
-   R31, R32, R33, R34
-   R41, R42, R43, R44
-   uv_mapping
-   texture {
-      pigment {
-         checker
-         color rgbf &lt;1,1,1,0.5&gt;
-         color rgbf &lt;1,0,0,0.7&gt;
-         scale 1/3
-      }
-      finish {phong 0.6 phong_size 20}
-   }
-   no_shadow
-}
-</pre>
-<p>
-This is a rather disappointing result. The patches are connected, but not exactly smooth.
-In connecting patches the same principles apply as for connecting two 2D bezier splines
-as we see in the <!--<linkto "Understanding The Concept of Splines">spline workshop</linkto>--->[[Documentation:Tutorial Section 3#Understanding The Concept of Splines|spline workshop]].
-Control point, connection point and the next control point should be on one line to give
-a smooth result. Also it is preferred, not required, that the distances from both control
-points to the connection point are the same. For the Bicubic patch we have to do the same,
-for all connection points involved in the joint. So, in our case, the following points
-should be on one line:</p>
-<ul type="disc">
-<li> B13, B14=R11, R12</li>
-<li> B23, B24=R21, R22</li>
-<li> B33, B34=R31, R32</li>
-<li> B43, B44=R41, R42</li>
-</ul>
-<p>
-To achieve this we do:
-</p>
-<pre>
-#declare R12=B14+(B14-B13);
-#declare R22=B24+(B24-B23);
-#declare R32=B34+(B34-B33);
-#declare R42=B44+(B44-B43);
-</pre>
-<p>[[Image:TutImgBpatch02.png|patches, (un)smoothly connected]] </p>
-<p>
-This renders a smooth surface. Adding a third patch in front is relative simple now:</p>
-<pre>
-#declare G11=B41;      #declare G12=B42;                //
-#declare G13=B43;      #declare G14=B44;                // row 1
-#declare G21=B41+(B41-B31); #declare G22=B42+(B42-B32); //
-#declare G23=B43+(B43-B33); #declare G24=B44+(B44-B34); // row 2
-#declare G31=&lt;0,0,-2&gt;; #declare G32=&lt;1,0,-2&gt;;           //
-#declare G33=&lt;2,0,-2&gt;; #declare G34=&lt;3,2,-2&gt;;           // row 3
-#declare G41=&lt;0,0,-3&gt;; #declare G42=&lt;1,0,-3&gt;;           //
-#declare G43=&lt;2,0,-3&gt;; #declare G44=&lt;3,0,-3&gt;            // row 4
-bicubic_patch {
-   type 1 flatness 0.001
-   u_steps 4 v_steps 4
-   uv_vectors
-   &lt;0,0&gt; &lt;1,0&gt; &lt;1,1&gt; &lt;0,1&gt;
-   G11, G12, G13, G14
-   G21, G22, G23, G24
-   G31, G32, G33, G34
-   G41, G42, G43, G44
-   uv_mapping
-   texture {
-      pigment {
-         checker
-         color rgbf &lt;1,1,1,0.5&gt;
-         color rgbf &lt;0,1,0,0.7&gt;
-         scale 1/3
-      }
-      finish {phong 0.6 phong_size 20}
-   }
-   no_shadow
-}
-</pre>
-<p>
-Finally, let's put a few spheres back in the scene and add some cylinders to visualize what
-is going on. See what happens if you move for example B44, B43, B33 or B34.
-</p>
-<pre>
-#declare Points=array[8]{B33,B34,R32,B43,B44,R42,G23,G24}
-#declare I=0;
-#while (I&lt;8)
-   sphere {
-      Points[I],0.1
-      no_shadow
-      pigment{
-         #if (I=4)
-            color rgb &lt;1,0,0&gt;
-         #else
-            color rgb &lt;0,1,1&gt;
-         #end
-      }
-   }
-   #declare I=I+1;
-#end
-union {
-   cylinder {B33,B34,0.04} cylinder {B34,R32,0.04}
-   cylinder {B43,B44,0.04} cylinder {B44,R42,0.04}
-   cylinder {G23,G24,0.04}
-   cylinder {B33,B43,0.04} cylinder {B43,G23,0.04}
-   cylinder {B34,B44,0.04} cylinder {B44,G24,0.04}
-   cylinder {R32,R42,0.04}
-   no_shadow
-   pigment {color rgb &lt;1,1,0&gt;}
-}
-</pre>
-<p>
-The hard part in using the Bicubic patch is not in connecting several patches. The
-difficulty is keeping control over the shape you want to build. As patches are added,
-in order to keep the result smooth, control over the position of many points gets restrained.
-</p>
-<p> [[Image:TutImgBpatch03.png|3 patches, some control points]] </p>
-====Text Object====
-<!--<indexentry "text, tutorial">--->
-<p>The <code>text</code> object is a primitive that can use TrueType fonts
-and TrueType Collections to create text objects. These
-objects can be used in CSG, transformed and textured just like any other POV
-primitive.</p>
-<p>
-For this tutorial, we will make two uses of the text object. First,
-let's just make some block letters sitting on a checkered plane. Any TTF
-font should do, but for this tutorial, we will use the <code>
-timrom.ttf</code> or <code>cyrvetic.ttf</code> which come bundled with
-POV-Ray.</p>
-<p>
-We create a file called <code>textdemo.pov</code> and edit it as
-follows:</p>
-<pre>
-  #include &quot;colors.inc&quot;
-  camera {
-    location &lt;0, 1, -10&gt;
-    look_at 0
-    angle 35
-  }
-  light_source { &lt;500,500,-1000&gt; White }
-  plane {
-    y,0
-    pigment { checker Green White }
-  }
-</pre>
-<p>Now let's add the text object. We will use the font <code>
-timrom.ttf</code> and we will create the string &quot;POV-RAY 3.0&quot;. For
-now, we will just make the letters red. The syntax is very simple. The first
-string in quotes is the font name, the second one is the string to be
-rendered. The two floats are the thickness and offset values. The thickness
-float determines how thick the block letters will be. Values of .5 to 2 are
-usually best for this. The offset value will add to the kerning distance of
-the letters. We will leave this a 0 for now.</p>
-<pre>
-  text {
-    ttf &quot;timrom.ttf&quot; &quot;POV-RAY 3.0&quot; 1, 0
-    pigment { Red }
-  }
-</pre>
-<p>Rendering this we notice that the letters are
-off to the right of the screen. This is because they are placed so that the
-lower left front corner of the first letter is at the origin. To center the
-string we need to translate it -x some distance. But how far? In the docs we
-see that the letters are all 0.5 to 0.75 units high. If we assume that each
-one takes about 0.5 units of space on the x-axis, this means that the string
-is about 6 units long (12 characters and spaces). Let's translate the
-string 3 units along the negative x-axis.</p>
-<pre>
-  text {
-    ttf &quot;timrom.ttf&quot; &quot;POV-RAY 3.0&quot; 1, 0
-    pigment { Red }
-    translate -3*x
-  }
-</pre>
-<p>That is better. Now let's play around with some of the parameters
-of the text object. First, let's raise the thickness float to something
-outlandish... say 25!</p>
-<pre>
-  text {
-    ttf &quot;timrom.ttf&quot; &quot;POV-RAY 3.0&quot; 25, 0
-    pigment { Red }
-    translate -2.25*x
-  }
-</pre>
-<p>Actually, that is kind of cool. Now let's return the thickness
-value to 1 and try a different offset value. Change the offset float from 0
-to 0.1 and render it again.</p>
-<p>
-Wait a minute?! The letters go wandering off up at an angle! That is not
-what the docs describe! It almost looks as if the offset value applies in
-both the x- and y-axis instead of just the x axis like we intended. Could it
-be that a vector is called for here instead of a float? Let's try it. We
-replace <code>0.1</code> with <code> 0.1*x</code> and render it again.</p>
-<p>
-That works! The letters are still in a straight line along the x-axis, just
-a little further apart. Let's verify this and try to offset just in the
-y-axis. We replace <code> 0.1*x</code> with <code> 0.1*y</code>. Again, this
-works as expected with the letters going up to the right at an angle with no
-additional distance added along the x-axis. Now let's try the z-axis. We
-replace <code> 0.1*y</code> with <code> 0.1*z</code>. Rendering this yields a
-disappointment. No offset occurs! The offset value can only be applied in the
-x- and y-directions.</p>
-<p>
-Let's finish our scene by giving a fancier texture to the block letters,
-using that cool large thickness value, and adding a slight y-offset. For fun,
-we will throw in a sky sphere, dandy up our plane a bit, and use a little
-more interesting camera viewpoint (we render the following scene at 640x480
-<code> +A0.2</code>):</p>
-<pre>
-  #include &quot;colors.inc&quot;
-  camera {
-    location &lt;-5,.15,-2&gt;
-    look_at &lt;.3,.2,1&gt;
-    angle 35
-  }
-  light_source { &lt;500,500,-1000&gt; White }
-  plane {
-    y,0
-    texture {
-      pigment { SeaGreen }
-      finish { reflection .35 specular 1 }
-      normal { ripples .35 turbulence .5 scale .25 }
-    }
-  }
-  text {
-    ttf &quot;timrom.ttf&quot; &quot;POV-RAY 3.0&quot; 25, 0.1*y
-    pigment { BrightGold }
-    finish { reflection .25 specular 1 }
-    translate -3*x
-  }
-  #include &quot;skies.inc&quot;
-  sky_sphere { S_Cloud5 }
-</pre>
-<p>Let's try using text in a CSG object. We will attempt to create an
-inlay in a stone block using a text object. We create a new file called
-<code>textcsg.pov</code> and edit it as follows:</p>
-<pre>
-  #include &quot;colors.inc&quot;
-  #include &quot;stones.inc&quot;
-  background { color rgb 1 }
-  camera {
-    location &lt;-3, 5, -15&gt;
-    look_at 0
-    angle 25
-  }
-  light_source { &lt;500,500,-1000&gt; White }
-</pre>
-<p>Now let's create the block. We want it to be about eight units across
-because our text string &quot;POV-RAY 3.0&quot; is about six units long. We
-also want it about four units high and about one unit deep. But we need to
-avoid a potential coincident surface with the text object so we will make the
-first z-coordinate 0.1 instead of 0. Finally, we will give this block a nice
-stone texture.</p>
-<pre>
-  box {
-    &lt;-3.5, -1, 0.1&gt;, &lt;3.5, 1, 1&gt;
-    texture { T_Stone10 }
-  }
-</pre>
-<p>Next, we want to make the text object. We can use the same object we used
-in the first tutorial except we will use slightly different thickness and
-offset values.</p>
-<pre>
-  text {
-    ttf &quot;timrom.ttf&quot; &quot;POV-RAY 3.0&quot; 0.15, 0
-    pigment { BrightGold }
-    finish { reflection .25 specular 1 }
-    translate -3*x
-  }
-</pre>
-<p>We remember that the text object is placed by default so that its front
-surface lies directly on the x-y-plane. If the front of the box begins at
-z=0.1 and thickness is set at 0.15, the depth of the inlay will be 0.05
-units. We place a difference block around the two objects.</p>
-<pre>
-  difference {
-    box {
-      &lt;-3.5, -1, 0.1&gt;, &lt;3.5, 1, 1&gt;
-      texture { T_Stone10 }
-    }
-    text {
-      ttf &quot;timrom.ttf&quot; &quot;POV-RAY 3.0&quot; 0.15, 0
-      pigment { BrightGold }
-      finish { reflection .25 specular 1 }
-      translate -3*x
-    }
-  }
-</pre>
-<p>[[Image:TutImgTxtstone.png|Text carved from stone.]]</p>
-<p>When we render this at a low resolution we can see the inlay clearly
+* picked up suggested changes -- [[User:Jholsenback|jholsenback]]
-and that it is indeed a bright gold color. We can render at a higher resolution and see the results more clearly, but be forewarned... this can take quite some time at higher resolutions.</p>
-<!--<wikinav>--->
-<br>
-<table width=100% border=0 cellspacing=0 cellpadding=5>
-<tr><td width=50% bgcolor=#EEEEEF>
-[[Documentation:Tutorial Section 2.2#Using the POVINI Environment Variable|Using the POVINI Environment Variable]]</td>
-<td width=50% bgcolor=#EEEEEF align=right>
-[[Documentation:Tutorial Section 3.1#Polygon Based Shapes|Polygon Based Shapes]]</td></tr>
-</table>
-<!--</wikinav>--->
-<!--<wikitalk>--->
-<br>
-<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 3|talk]] page.
-</td></tr>
-</table>
-<!--</wikitalk>--->