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

From POV-Wiki
Jump to navigation Jump to search
m (→‎Lathe Object: Suggested rewording)
m (closed tags)
 
(3 intermediate revisions by 2 users not shown)
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====
+
* Jim, Thanks for making the earlier update. I noticed another place in the prism part of the tutorial where we should mention the bezier spline.
−
<!--<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
 
−
    6,
 
−
    &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>
+
* Where we today have:
  
−
<p>We render this, and what we see is a fairly simply type of lathe, which
+
=====Teaching An Old Spline New Tricks=====
−
looks like a child's top. Let's take a look at how this code produced
+
<p>If we followed the section on splines covered under the lathe tutorial
−
the effect.</p>
+
(see the section <!--<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]]), we know that
−
<p>
+
there are two additional kinds of splines besides linear: the quadratic and
−
First, a set of six points is declared which the raytracer connects with
+
the cubic spline. Sure enough, we can use these with prisms to make a more
−
lines. We note that there are only two components in the vectors which
+
free form, smoothly curving type of prism.</p>
−
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
 
−
3D 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
 
−
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. </p>
 
−
<p>
 
−
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
 
−
&lt;0,0&gt; to &lt;2,2&gt;, then to dip back down to &lt;4,0&gt;. 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.</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
 
−
    5,
 
−
    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>
+
* I think it should read:
  
−
<p>Now, we take a deep breath. We know that all looks a bit weird, but with
+
=====Teaching An Old Spline New Tricks=====
−
some simple explanations, we can easily see what all this does.</p>
+
<p>If we followed the section on splines covered under the lathe tutorial
−
<p>
+
(see the section <!--<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]]), we know that
−
First, we are using the orthographic camera. If we have not read up on
+
there are three additional kinds of splines besides linear: the quadratic,
−
that yet, a quick summary is: it renders the scene <em>flat</em>, eliminating
+
the cubic and the bezier spline. Sure enough, we can use these with prisms to make a more
−
perspective distortion so that in a side view, the objects look like they
+
free form, smoothly curving type of prism.</p>
−
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>
+
* And one more which now reads:
−
 
 
−
<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
 
−
    4,
 
−
    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
 
−
    8,
 
−
    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 {
 
−
    8,
 
−
    &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====
 
====Prism Object====
−
<!--<indexentry "prism, tutorial">--->
 
 
<p>The prism is essentially a polygon or closed curve which is swept along a
 
<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
 
linear path. We can imagine the shape so swept leaving a trail in space, and
Line 444: Line 34:
 
simplest form of prism. We enter and render the following POV code (see file
 
simplest form of prism. We enter and render the following POV code (see file
 
<code>prismdm1.pov</code>).</p>
 
<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
 
−
    0, // sweep the following shape from here ...
 
−
    1, // ... up through here
 
−
    7, // 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>
+
* that I think should read:
  
−
<p>This produces a hexagonal polygon, which is then swept from y=0 through
+
====Prism Object====
−
y=1. In other words, we now have an extruded hexagon. One point to note is
+
<p>The prism is essentially a polygon or closed curve which is swept along a
−
that although this is a six sided figure, we have used a total of seven
+
linear path. We can imagine the shape so swept leaving a trail in space, and
−
points. That is because the polygon is supposed to be a closed shape, which
+
the surface of that trail is the surface of our prism. The curve or polygon
−
we do here by making the final point the same as the first. Technically, with
+
making up a prism's face can be a composite of any number of sub-shapes,
−
linear polygons, if we did not do this, POV-Ray would automatically join
+
can use any kind of four different splines, and can either keep a constant
−
the two ends with a line to force it to close, although a warning would be
+
width as it is swept, or slowly tapering off to a fine point on one end. But
−
issued. However, this only works with linear splines, so we must not get
+
before this gets too confusing, let's start one step at a time with the
−
too casual about those warning messages!</p>
+
simplest form of prism. We enter and render the following POV code (see file
−
=====Teaching An Old Spline New Tricks=====
+
<code>prismdm1.pov</code>).</p>
−
<!--<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
 
−
    0, // sweep the following shape from here ...
 
−
    1, // ... up through here
 
−
    6, // 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
 
−
    0,  // sweep the following shape from here ...
 
−
    1,  // ... up through here
 
−
    18, // 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
 
−
    0, // height 1
 
−
    1, // height 2
 
−
    5, // 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>
 
−
  1, // height 2
 
−
</pre>
 
−
 
 
−
<p>with</p>
 
−
<pre>
 
−
  4, // 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>
 
−
  0, // height 1
 
−
</pre>
 
−
 
 
−
<p>to</p>
 
−
<pre>
 
−
  0.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
 
−
    4,
 
−
    &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
 
−
    6,
 
−
    &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
 
−
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>--->
 

Latest revision as of 16:05, 24 May 2016

  • Jim, Thanks for making the earlier update. I noticed another place in the prism part of the tutorial where we should mention the bezier spline.
  • Where we today have:
Teaching An Old Spline New Tricks

If we followed the section on splines covered under the lathe tutorial (see the section Understanding The Concept of Splines), 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.

  • I think it should read:
Teaching An Old Spline New Tricks

If we followed the section on splines covered under the lathe tutorial (see the section Understanding The Concept of Splines), we know that there are three additional kinds of splines besides linear: the quadratic, the cubic and the bezier spline. Sure enough, we can use these with prisms to make a more free form, smoothly curving type of prism.


  • And one more which now reads:

Prism Object

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

  • that I think should read:

Prism Object

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 four 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 prismdm1.pov).

Retrieved from "https://wiki.povray.org/content?title=Documentation_Talk:Tutorial_Section_3&oldid=8521"