played a little with settings for headstyle - causes strange numbers - check!!

[cluster_expansion_thesis.git] / little_helpers / tikz / sketch-0.2.161 / Doc / sketch.texi

\input texinfo   @c -*-texinfo-*-\r
@c %**start of header\r
@setfilename sketch.info\r
@include version.texi\r
@settitle Sketch\r
\r
@c an index for sketch commands\r
@defcodeindex sx\r
@defcodeindex op\r
@syncodeindex op sx\r
@c %**end of header\r
\r
@copying\r
Copyright @copyright{} 2005, 2006, 2007, 2008 Eugene K. Ressler.\r
\r
This manual is for @code{sketch}, version @value{VERSION},\r
@value{UPDATED}, a program that converts descriptions of simple\r
three-dimensional scenes into static drawings. This version generates\r
@code{PSTricks} or @code{PGF/TikZ} code suitable for use with the\r
@TeX{} document processing system.\r
\r
@code{Sketch} is free software; you can redistribute it and/or modify\r
it under the terms of the GNU General Public License as published by\r
the Free Software Foundation; either version 3, or (at your option)\r
any later version.\r
\r
Sketch is distributed in the hope that it will be useful,\r
but WITHOUT ANY WARRANTY; without even the implied warranty of\r
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\r
GNU General Public License for more details.\r
\r
You should have received a copy of the GNU General Public License\r
along with @code{sketch}; see the file COPYING.txt.  If not, see\r
@verb{|http://www.gnu.org/copyleft|}.\r
\r
@end copying\r
\r
@dircategory TeX\r
@direntry\r
* Sketch: (sketch).             Simple 3D sketching for TeX\r
@end direntry\r
 \r
@titlepage\r
@title Sketch\r
@subtitle Simple 3D sketching\r
@subtitle Version @value{VERSION}, @value{UPDATED}\r
@author Gene Ressler\r
@page\r
@vskip 0pt plus 1fill\r
@insertcopying\r
@end titlepage\r
\r
@c TOC\r
@contents\r
\r
@ifnottex\r
@node Top, About sketch, (dir), (dir)\r
@top Sketch\r
\r
@insertcopying\r
@end ifnottex\r
\r
@menu\r
* About sketch::                Why sketch exists and what it does.\r
* Introduction by example::     Most features shown as working code.\r
* Input language::              Syntax and semantics of @code{sketch} commands. \r
* Building a drawing::          How to use @code{sketch} productively.\r
* Command line::                Options and their usage.\r
* Installing sketch::           Building and installing from sources.\r
* Index of syntax::             \r
* Index::                       \r
\r
@detailmenu\r
 --- The Detailed Node Listing ---\r
\r
About sketch\r
\r
* Reporting bugs::              Let use know what's wrong!\r
* Contributions::               How you can help@dots{}.\r
\r
Introduction by example\r
\r
* Hello world::                 Simplest possible @code{sketch} program.\r
* Drawing options::             Controlling object appearance.\r
* Drawing a solid::             Drawing an object with 3d appearance.\r
* Special objects::             Laying @TeX{} over, in, or under drawings.\r
* Object transforms::           Rotate, translate, scale, and others.\r
* Repeated objects::            Making transformed copies.\r
* Swept objects::               Sweeping objects in space to make new shapes.\r
\r
Swept objects\r
\r
* Point sweeps::                Swept points make lines and polygons.\r
* Polyline sweeps::             Swept lines make surfaces.\r
* Nested sweeps::               Swept sweeps are useful!\r
* Polygon sweeps::              Swept polygons make solids...\r
* Polyline sweeps with closure::  and so do closed polyline sweeps.\r
* Affine arithmetic::           Sketch useful math expression.\r
* More to learn::               Check out the Mobius strip!\r
\r
Input language\r
\r
* Language basics::             Case, space, comments, include files.\r
* Drawables::                   Things that can be drawn.\r
* Definitions::                 Giving things names.\r
* Global environment::          Affect the entire drawing.\r
\r
Basics \r
\r
* Identifiers::                 Names for things.\r
* Key and reserved words::      Names you shouldn't use.\r
* Literals::                    Constants and constructors.\r
* Arithmetic::                  Rules for expressions.\r
* Options::                     Modifying object appearance.\r
\r
Literals\r
\r
* Scalar literals::             Just the numbers.\r
* Point and vector literals::   3d quantities.\r
* Transform literals::          Matrix form.\r
\r
Arithmetic expressions\r
\r
* Two-operand (binary) forms::  A op B\r
* Unary forms::                 op A (and others)\r
\r
Options\r
\r
* PSTricks options::            Options inherited from @code{PSTricks}.\r
* TikZ/PGF options::            Options inherited from @code{TikZ/PGF}.\r
* Dots in TikZ/PGF::            Sketch uses @code{TikZ/PGF} circles for dots.\r
* TikZ/PGF user-defined styles::  Support for @code{TikZ/PGF} named, user-defined styles.\r
* Transparency::                See-through polygons.\r
* Internal options::            Options used by @code{sketch}.\r
\r
Point lists\r
\r
* Drawables::                   Things that are drawn.\r
* Definitions::                 Things with names.\r
\r
Drawables\r
\r
* Dots::                        Draw dots.\r
* Lines::                       Draw polylines.\r
* Curves::                      Draw curves.\r
* Polygons::                    Draw polygons.\r
* Specials::                    Embed raw @LaTeX{} and @code{PSTricks}.\r
* Sweeps::                      Draw sweeps of dots and polylines.\r
* Blocks::                      Group other drawables.\r
* Repeats::                     Draw transformed copies of objects.\r
* Puts::                        Draw one object transformed.\r
\r
Sweeps\r
\r
* Swept points::                Swept points make lines or polygons.\r
* Swept lines::                 Swept lines make open or closed surfaces.\r
* Swept polygons::              Swept polygons make closed surfaces.\r
* Swept blocks::                Swept block @equiv{} block of sweeps.\r
* Sweep face splitting::        Fixing warped faces with triangles.\r
\r
Definitions\r
\r
* Forms of definitions::        Different defs for different purposes.\r
* Forms of references::         How references denote types.\r
\r
Global environment\r
\r
* Global options::              Attributes of the entire drawing.\r
* Camera::                      A final camera transformation of the scene.\r
* Picture box::                 Setting the bounding box and 2d clipping.\r
* Frame::                       Adding a box around the drawing.\r
* Language::                    Setting the output language.\r
\r
Building a drawing\r
\r
* Overview::                    Building a substantial drawing.\r
* A technical drawing::         An example with fine placement.\r
* A hierarchical model::        An example with sweeps and puts.\r
* Caveats::                     Where trouble can occur.\r
\r
Caveats\r
\r
* Limits on error detection::   What sketch doesn't do.\r
* Clipping::                    No clipping at present.\r
* Hidden surface removal::      Imperfections to fix.\r
\r
Hidden surface removal and polygon splitting\r
\r
* Statistics::                  Performance numbers on depth sort.\r
* Bugs and anomalies::          Imperfections in this implementation.\r
\r
@end detailmenu\r
@end menu\r
\r
@node About sketch, Introduction by example, Top, Top\r
@comment  node-name,  next,  previous,  up\r
@chapter About sketch\r
\r
@menu\r
* Reporting bugs::              Let use know what's wrong!\r
* Contributions::               How you can help@dots{}.\r
@end menu\r
\r
@code{Sketch} is a small, simple system for producing line drawings of\r
two- or three-dimensional objects and scenes.  It began as a way to\r
make illustrations for a textbook after we could find no suitable\r
tool for this purpose.  Existing scene processors emphasized GUIs\r
and/or photo-realism, both un-useful to us.  We wanted to produce\r
finely wrought, mathematically-based illustrations with no extraneous\r
detail.\r
\r
@code{Sketch} accepts a tiny scene description language and generates\r
@code{PSTricks} or @code{TikZ/PGF} code for @LaTeX{}.  The\r
@code{sketch} language is similar to @code{PSTricks}, making it easy\r
to learn for current @code{PSTricks} users.  See\r
@cindex PSTricks\r
@verb{|www.pstricks.de|} for information on @code{PSTricks}.\r
@code{TikZ/PGF} are also very similar except for details of syntax.\r
See\r
@cindex TikZ/PGF\r
@verb{|http://sourceforge.net/projects/pgf|}.  One can easily lay raw\r
@code{PSTricks} or @code{TikZ/PGF} output over, in, or under\r
@code{sketch} drawings, providing the full power of @LaTeX{} text and\r
mathematics formatting in a three-dimensional setting.\r
\r
@node Reporting bugs, Contributions, About sketch, About sketch\r
@comment  node-name,  next,  previous,  up\r
@section Reporting bugs and recommending improvements.\r
Report bugs and make suggestions at\r
our Google Group @verb{|http://groups.google.com/group/sketch-users|}.\r
A second method that will probably produce a slower\r
response is email to @verb{|sketch@frontiernet.net|}.\r
We will try to respond, but can't promise.  In any event, don't be\r
offended if a reply is not forthcoming.  We're just busy and will get\r
to your suggestion eventually.\r
\r
For bugs, attach a @code{sketch} input file that causes the bad\r
behavior.  Embed comments that explain what to look for in\r
the behavior of @code{sketch} or its output.\r
\r
A recommendation for improvement from one unknown person counts as one\r
vote. We use overall vote tallies to decide what to do next as\r
resources permit.  We reserve the right to a assign any number of votes\r
to suggestions from people who have been helpful and supportive in the\r
past.\r
\r
@node Contributions,  , Reporting bugs, About sketch\r
@comment  node-name,  next,  previous,  up\r
@section Contributions\r
If you intend to implement an enhancement of your own, that's\r
terrific!  Consider collaborating with us first to see if we're\r
already working on your idea or if we can use your work in the\r
official release.\r
\r
@center @image{ex000}\r
@anchor{Solid coil example}\r
\r
@node Introduction by example, Input language, About sketch, Top\r
@comment  node-name,  next,  previous,  up\r
@chapter Introduction by example\r
The @code{sketch} input language will seem familiar to users of the\r
@code{PSTricks} package for @LaTeX{}.  The following program draws a\r
triangular polygon pierced by a line.\r
@verbatim\r
  polygon(0,0,1)(1,0,0)(0,1,0)\r
  line(-1,-1,-1)(2,2,2)\r
@end verbatim\r
@noindent\r
The coordinate system \r
@cindex coordinate system, right-handed\r
@cindex right-hand coordinate system\r
is a standard right-handed Cartesian one.\r
\r
@center @image{ex010}\r
\r
@menu\r
* Hello world::                 Simplest possible @code{sketch} program.\r
* Drawing options::             Controlling object appearance.\r
* Drawing a solid::             Drawing an object with 3d appearance.\r
* Special objects::             Laying @TeX{} over, in, or under drawings.\r
* Object transforms::           Rotate, translate, scale, and others.\r
* Repeated objects::            Making transformed copies.\r
* Swept objects::               Sweeping objects in space to make new shapes.\r
@end menu\r
\r
@node Hello world, Drawing options, Introduction by example, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Hello world\r
The @code{sketch} program above is nearly the simplest one possible,\r
the equivalent of a ``hello world''\r
@cindex hello world\r
@cindex program, hello world\r
program you might find at the start of a programming language text.\r
If it is saved in the file @file{simple.sk}, then the command\r
@cindex command line, @code{sketch}\r
@cindex running @code{sketch}\r
@verbatim\r
  sketch simple.sk -o simple.tex\r
@end verbatim\r
@noindent\r
creates a file @file{simple.tex} containing @code{PSTricks} commands to\r
draw these objects on paper.  The contents of @file{simple.tex}\r
look like this.\r
@verbatim\r
  \begin{pspicture}(-1,-1)(2,2)\r
  \pstVerb{1 setlinejoin}\r
  \psline(-1,-1)(.333,.333)\r
  \pspolygon[fillstyle=solid,fillcolor=white](0,0)(1,0)(0,1)\r
  \psline(.333,.333)(2,2)\r
  \end{pspicture}\r
@end verbatim\r
@noindent\r
The hidden surface algorithm \r
@cindex hidden surface algorithm\r
of @code{sketch} has split \r
@cindex splitting, line and surface\r
the line into\r
two pieces and ordered the three resulting objects so that the correct\r
portion of the line is hidden.\r
\r
If you've noticed that the projection we are using seems equivalent to\r
erasing the @math{z}-coordinate of the three-dimensional input points,\r
pat yourself on the back.  You are correct.  This is called a\r
@dfn{parallel projection}.\r
@cindex parallel projection\r
@cindex projection, parallel\r
The @math{z}-coordinate axis is pointing straight out of the paper at\r
us, while the @math{x}- and @math{y}-axes point to the right and up as\r
usual.\r
\r
The resulting picture file can be included in a @LaTeX{} document with\r
@verb{|\input{simple}|}.  Alternately, adding the command line option\r
@option{-T}@footnote{Or for European users of A4 size paper,\r
@option{-Te}.} \r
@cindex command line option\r
@cindex option, command line\r
causes the @code{pspicture} to be wrapped in a short\r
but complete document, ready to run though @LaTeX{}.\r
@cindex document template\r
@cindex template, document\r
In a finished, typeset document, the picture looks like this.  (The\r
axes have been added in light gray.)\r
\r
@center @image{ex020}\r
\r
@noindent\r
It is important to know that only the ``outside'' \r
@cindex outside of a polygon\r
@cindex polygon, outside of\r
of a polygon is\r
normally drawn.  The @dfn{outside} is where the vertices given in the\r
@code{polygon} \r
@sxindex polygon\r
command appear in @emph{counter-clockwise} \r
@cindex counter-clockwise polygon vertex order\r
@cindex polygon vertex order\r
@cindex order, polygon vertex\r
order.  Thus, if the command above had been\r
@verbatim\r
  polygon(0,1,0)(1,0,0)(0,0,1)\r
@end verbatim\r
@noindent\r
the polygon would not appear in the picture at all.  It would have\r
been @dfn{culled}\r
@cindex culling\r
from the scene.  This culling behavior may seem\r
strange, but stay tuned.\r
\r
@node Drawing options, Drawing a solid, Hello world, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Options\r
Many @code{PSTricks} and @code{TikZ/PGF} options \r
@cindex option\r
work just fine in @code{sketch}. If generating @code{PSTricks}, the code\r
@sxindex line\r
@verbatim\r
  polygon[fillcolor=lightgray,linewidth=3pt](0,0,1)(1,0,0)(0,1,0)\r
  line[linestyle=dotted](-1,-1,-1)(2,2,2)\r
@end verbatim\r
@noindent\r
produces\r
\r
@center @image{ex030}\r
\r
To produce @code{TikZ/PGF}, the corresponding code is \r
@verbatim\r
  polygon[fill=lightgray,line width=3pt](0,0,1)(1,0,0)(0,1,0)\r
  line[style=dotted](-1,-1,-1)(2,2,2)\r
  global { language tikz }\r
@end verbatim\r
@noindent\r
The final @code{global} \r
@cindex options, global\r
@cindex global options\r
instructs @code{sketch} to produce @code{TikZ/PGF} code as output\r
rather than the default, @code{PSTricks}.  Note that @code{polygon}\r
fill color and @code{line} style options both conform to @code{TikZ}\r
syntax rules.  The resulting @code{TikZ/PGF} output is\r
@verbatim\r
  \begin{tikzpicture}[join=round]\r
  \draw[dotted](-1,-1)--(.333,.333);\r
  \filldraw[fill=lightgray,line width=3pt](0,0)--(1,0)--(0,1)--cycle;\r
  \draw[dotted](.333,.333)--(2,2);\r
  \end{tikzpicture}\r
@end verbatim\r
@noindent\r
The remaining examples of this manual are in PSTricks style.\r
\r
@node Drawing a solid, Special objects, Drawing options, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Drawing a solid\r
Let's try something more exciting.  @code{Sketch} has no notion of a\r
solid, \r
@cindex solid\r
but polygonal @dfn{faces} \r
@cindex faces\r
can be used to represent the\r
boundary of a solid.  To the previous example, let's add three more\r
triangular polygons to make the faces of an irregular tetrahedron.\r
@cindex tetrahedron\r
@sxindex def\r
@sxindex polygon\r
@verbatim\r
  % vertices of the tetrahedron\r
  def p1 (0,0,1) def p2 (1,0,0)\r
  def p3 (0,1,0) def p4 (-.3,-.5,-.8)\r
\r
  % faces of the tetrahedron.\r
  polygon(p1)(p2)(p3) % original front polygon\r
  polygon(p1)(p4)(p2) % bottom\r
  polygon(p1)(p3)(p4) % left\r
  polygon(p3)(p2)(p4) % rear\r
\r
  % line to pierce the tetrahedron\r
  line[linecolor=red](-1,-1,-1)(2,2,2)\r
@end verbatim\r
@noindent\r
This example uses @dfn{definitions}, \r
@cindex definition\r
which begin with \r
@code{def}.\r
@sxindex def\r
These @dfn{define} or give names to points, \r
@cindex definition, point\r
@cindex point definition\r
which are then available\r
as @dfn{references} \r
@cindex reference, point\r
by enclosing the names in parentheses,\r
e.g.@ @verb{|(foo)|}.\r
@sxindex (foo)@r{, point reference}\r
The parentheses denote that the names refer to points; they are\r
required.  There can be no\r
@cindex white space\r
white space between them and the name.\r
\r
As you can see, comments \r
@cindex comments\r
start with @verb{|%|} as in @TeX{} and extend\r
to the end of the line (though @verb{|#|} will work as well).  White\r
space, \r
@cindex white space\r
including spaces, tabs and blank lines, has no effect in the @code{sketch}\r
language.\r
\r
@center @image{ex040}\r
\r
@noindent\r
If we look inside the @TeX{} file produced by @code{sketch}, there\r
will be only three polygons.  The fourth has been \r
@cindex culling\r
culled because it is\r
a ``back face'' \r
@cindex back face\r
of the tetrahedron, invisible to our view.  It is\r
unnecessary, and so it is removed.\r
\r
In some drawings, polygons act as zero-thickness solid surfaces with\r
both sides visible rather than as the faces of solid objects, where\r
back faces can be culled.  For zero-thickness solids, culling \r
@cindex culling\r
is a\r
problem.  One solution is to use a pair of @code{sketch} polygons for\r
each zero-thickness face, identical except with opposite vertex\r
orders.  This is unwieldy and expensive.  A better way is to\r
set the @code{sketch} internal option @code{cull} to @code{false} in\r
the usual @code{PSTricks} manner.\r
@opindex cull\r
@verbatim\r
  polygon[cull=false](p1)(p2)(p3)\r
@end verbatim\r
@noindent\r
The following shows the same helix\r
@cindex helix\r
shape drawn first with\r
@verb{|cull=true|} (the default) and then @verb{|cull=false|}.\r
\r
@center @image{ex045} @anchor{Helix with cull set false then true} \r
\r
@noindent\r
We'll soon see how to produce these helixes with a few lines \r
of @code{sketch} language code.\r
\r
It may be tempting to turn culling off gratuitously so that vertex order\r
can be ignored.  This is not a good idea because output file size and\r
@TeX{} and Postscript processing time both depend on the number of\r
output polygons.  Culling usually improves performance by a factor of\r
two.  On the other hand, globally setting @code{cull=false} is \r
reasonable while debugging.  See @ref{Global options} and \r
@ref{Limits on error detection}.\r
\r
@node Special objects, Object transforms, Drawing a solid, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Special objects\r
We can add labels \r
@cindex labels\r
to a drawing by using @verb{|special|} \r
@sxindex special\r
@cindex special object\r
objects, which provide a way to embed raw @LaTeX{} and @code{PSTricks}\r
code.  Adding this to the tetrahedron does the trick.\r
@verbatim\r
  special |\footnotesize\r
           \uput{2pt}[ur]#1{$P1$}\r
           \uput[r]#2{$P2$}\r
           \uput[u]#3{$P3$}\r
           \uput[d]#4{$P4$}|\r
    (p1)(p2)(p3)(p4)\r
@end verbatim\r
@noindent\r
Here is the result.\r
\r
@center @image{ex042}\r
\r
There are several details to note here.  First, the quoting convention\r
@cindex quoting, special\r
for the raw code is similar to the @LaTeX{} @verb{|\verb|} command.  The\r
first non-white space character following @verb{|special|} is\r
understood to be the quote character, \r
in this case @samp{|}.  The raw\r
text continues until this character recurs.\r
\r
Second, the argument references \r
@cindex argument, special\r
@verb{|#1|}, @verb{|#2|}, @verb{|#3|},\r
and @verb{|#4|} refer to points in the list that follow.  This is\r
similar to @TeX{} macro syntax.  The transformed and two-dimensional\r
projections of these three-dimensional points are substituted \r
@cindex substitution, special\r
@cindex special argument substitution\r
in the final output.  An argument reference of the form @verb{|#1-2|}\r
is replaced with the angle in degrees of the two-dimensional vector\r
that connects the projections of the two respective argument points,\r
here @verb{|#1|} and @verb{|#2|}.  The substituted angle is enclosed\r
in curly braces @code{@{ @}}\r
\r
By default, @code{special} objects are printed last, overlaying all\r
other objects in the scene.  If you specify the internal option\r
@cindex internal option\r
@cindex option, internal\r
@code{lay=in}, the hidden surface algorithm \r
@opindex lay\r
@cindex hidden surface algorithm\r
considers the entire special object to be the first point\r
(@verb{|#1|}) in the argument list.  If that point is behind (of\r
smaller @math{z}-component than) any drawable, then the entire special\r
object is drawn before that drawable, so the drawable obscures parts of\r
the special object that overlaps it.  In our example, @verb{|p1|} is\r
the front-most point in the scene (has the largest\r
@math{z}-component), so adding @code{lay=in} has no effect.  \r
\r
With option @code{lay=under}, a special is drawn @emph{before}, hence\r
appears @emph{under} any of the objects handled by the hidden surface\r
algorithm.  This is how the light gray axes were added to the ``hello\r
world'' example @ref{Hello world}.\r
\r
@verb{|Special|} objects are powerful, with many possible uses.\r
\r
@node Object transforms, Repeated objects, Special objects, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Transforms\r
@cindex transform\r
Now let's add a second copy of the pierced tetrahedron.  We'll rotate\r
the copy 90 degrees about the @math{x}-axis with the origin as\r
@dfn{center of rotation}\r
@cindex center of rotation\r
@cindex rotation, center of\r
so we can see the back,\r
then translate it to the right---in the positive\r
@math{x}-direction---so it doesn't collide with the original. To help\r
us see what's going on, make the back side gray.\r
@sxindex def\r
@sxindex put\r
@sxindex line\r
@sxindex polygon\r
@opindex linecolor\r
@opindex fillcolor\r
@sxindex rotate\r
@sxindex translate\r
@sxindex then\r
@verbatim\r
  def pierced_tetrahedron {\r
    def p1 (0,0,1) def p2 (1,0,0)\r
    def p3 (0,1,0) def p4 (-.3,-.5,-.8)\r
    polygon(p1)(p2)(p3)                      % original\r
    polygon(p1)(p4)(p2)                      % bottom\r
    polygon(p1)(p3)(p4)                      % left\r
    polygon[fillcolor=lightgray](p3)(p2)(p4) % rear\r
    line[linecolor=red](-1,-1,-1)(2,2,2)\r
  }\r
  {pierced_tetrahedron}  % tetrahedron in original position\r
  put { rotate(90, (0,0,0), [1,0,0]) % copy in new position\r
        then translate([2.5,0,0]) } {pierced_tetrahedron}\r
@end verbatim\r
@noindent\r
Here the entire code of the previous example has been wrapped in a\r
definition by forming a @dfn{block} \r
@cindex block\r
@sxindex @{ @}@r{, block drawable}\r
with braces (a single item would not need them).  The point\r
definitions nested inside the braces are @dfn{lexically scoped}.\r
@cindex lexical scope\r
@cindex scope, identifier\r
Their meaning extends only to the end of the block.  The outer\r
@verb{|def|} is called a @dfn{drawable}\r
@cindex drawable\r
definition \r
@cindex definition, drawable\r
@cindex drawable definition\r
because it describes something that can be drawn.\r
\r
A drawable definition by itself causes nothing to happen until its\r
name is referenced.  Drawable references must be enclosed in curly\r
braces, e.g.@ @verb{|{foo}|}, with no intervening\r
@cindex white space\r
white space.  In the code\r
above, the first reference \r
@cindex reference, drawable\r
@verb{|{pierced_tetrahedron}|} \r
@sxindex @{foo@}@r{, drawable reference}\r
is a plain\r
one. Its effect is merely to duplicate the earlier drawing.  Almost\r
any series of @code{sketch} commands @verb{|stuff|} may be replaced\r
with @verb{|def foo { stuff } {foo}|} without changing its meaning.\r
\r
The @verb{|put|} command supplies a second reference, this time with\r
a @dfn{transform} applied first.  The @verb{|rotate|}\r
@sxindex rotate\r
@cindex rotation\r
transform turns the tetrahedron 90 degrees about the origin.  The\r
axis of rotation \r
@cindex axis, rotation\r
is the vector @math{[1,0,0]}.  By the @dfn{right\r
hand rule}, \r
@cindex right hand rule\r
this causes the top of the tetrahedron to rotate toward\r
the viewer and the bottom away.  The rule receives its name from the\r
following definition:\r
@quotation\r
@anchor{Right hand rule}\r
@strong{Right hand rule.}  If the right hand is wrapped around any\r
axis with the thumb pointing in the axis direction, then the fingers\r
curl in the direction of positive rotation about that axis.\r
@end quotation\r
The @verb{|translate|} \r
@sxindex translate\r
@cindex translation transform\r
@cindex transform, translation\r
transform moves the pyramid laterally to\r
the right by adding the vector \r
@cindex vector\r
@math{[2.5,0,0]} to each vertex\r
coordinate.  The result is shown here.\r
\r
@center @image{ex050}\r
\r
@node  Repeated objects, Swept objects, Object transforms, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Repeated objects\r
To draw seven instances of the tetrahedron, each differing from the\r
last by the same transform, replace the last two commands of the\r
previous example with\r
@sxindex repeat\r
@sxindex rotate\r
@sxindex translate\r
@verbatim\r
  repeat { 7, rotate(15, (0,0,0), [1,0,0]) % copy in new position\r
              then translate([2,0,0]) } {pierced_tetrahedron}\r
@end verbatim\r
@noindent\r
And the result@enddots{}\r
\r
@center @image{ex060}\r
\r
@node  Swept objects,  , Repeated objects, Introduction by example\r
@comment  node-name,  next,  previous,  up\r
@section Swept objects\r
@cindex swept object\r
@cindex sweep\r
Many familiar shapes can be generated by sweeping simpler ones through\r
space and considering the resulting path, surface, or volume.\r
@code{Sketch} implements this idea in the @verb{|sweep|} command.\r
@sxindex sweep\r
@sxindex rotate\r
@verbatim\r
  def n_segs 8\r
  sweep { n_segs, rotate(180 / n_segs, (0,0,0), [0,0,1]) } (1,0,0)\r
@end verbatim\r
@noindent\r
This code sweeps the point @math{(1,0,0)} \r
@cindex point sweep\r
@cindex swept point\r
eight times by rotating it\r
@math{180/8 = 22.5} degrees each time and connecting the resulting\r
points with line segments.  The @verb{|def|} used here is a\r
@dfn{scalar} definition.\r
@cindex definition, scalar\r
@cindex scalar definition\r
References to\r
@cindex reference, scalar\r
scalars have no enclosing brackets at all.\r
\r
@menu\r
* Point sweeps::                Swept points make lines and polygons.\r
* Polyline sweeps::             Swept lines make surfaces.\r
* Nested sweeps::               Swept sweeps are useful!\r
* Polygon sweeps::              Swept polygons make solids...\r
* Polyline sweeps with closure::  and so do closed polyline sweeps.\r
* Affine arithmetic::           Sketch useful math expression.\r
* More to learn::               Check out the Mobius strip!\r
@end menu\r
\r
@node Point sweeps, Polyline sweeps, Swept objects, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection Point sweeps\r
Sweeping a point makes a one-dimensional path, which is a polyline.\r
Since we have swept with a rotation, the result is a circular arc.\r
Here is what it looks like.\r
\r
@center @image{ex070}\r
\r
This is the first example we have seen of @code{sketch} arithmetic.\r
The expression @verb{|180 / n_segs|} causes the eight rotations to add\r
to 180.  If you're paying attention, you'll have already noted that\r
there are @emph{nine} points, producing eight line segments.\r
\r
You can cause the swept point to generate a single polygon rather than\r
a polyline by using the @dfn{closure tag} @verb{|<>|} \r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
after the number\r
of swept objects. Code and result follow\r
@sxindex def\r
@sxindex rotate\r
@sxindex sweep\r
@verbatim\r
  def n_segs 8\r
  sweep { n_segs<>, rotate(180 / n_segs, (0,0,0), [0,0,1]) } (1,0,0)\r
@end verbatim\r
@center @image{ex080}\r
\r
@node Polyline sweeps, Nested sweeps, Point sweeps, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection Polyline sweeps\r
Sweeping a polyline produces a \r
@cindex line sweep\r
@cindex swept line\r
@cindex surface\r
surface composed of many faces.  \r
@cindex faces\r
The unbroken helix in the\r
example @ref{Helix with cull set false then true} is produced by this\r
code (plus a surrounding @verb{|put|} rotation to make an interesting\r
view; this has been omitted).\r
@sxindex def\r
@sxindex sweep\r
@sxindex rotate\r
@sxindex translate\r
@opindex cull\r
@opindex linewidth\r
@verbatim\r
  def K [0,0,1]\r
  sweep[cull=false] {\r
    60, \r
    rotate(10, (0,0,0), [K]) then translate(1/6 * [K]) \r
  } line[linewidth=2pt](-1,0)(1,0)\r
@end verbatim\r
@noindent\r
Again, 60 segments of the helix \r
@cindex helix\r
are produced by connecting 61\r
instances of the swept line.  Options \r
@cindex options, sweep\r
applied to the sweep, here\r
@verb{|cull=false|}, are treated as options for the generated polygon\r
or polyline.  Options of the swept line itself, here\r
@verb{|linewidth=2pt|}, are ignored, though with a warning. This\r
@verb{|def|} is a @dfn{vector} definition, \r
@cindex definition, vector\r
@cindex vector definition\r
which must be referenced\r
with square brackets, e.g.@ @verb{|[foo]|}.\r
@cindex reference, vector\r
@sxindex [foo]@r{, vector reference}\r
\r
@node Nested sweeps, Polygon sweeps, Polyline sweeps, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection Nested sweeps\r
When the center point of rotation is omitted, \r
@cindex center of rotation\r
@cindex rotation, center of\r
the origin is assumed.\r
When a point has only two coordinates, they are taken as\r
@math{x}@tie{}and @math{y},@tie{}with @math{z=0} assumed.  A toroid \r
@cindex toroid\r
is therefore obtained with this code.\r
@sxindex def\r
@sxindex sweep\r
@sxindex rotate\r
@verbatim\r
  def n_toroid_segs 20   def n_circle_segs 16\r
  def r_minor 1          def r_major 1.5\r
  sweep { n_toroid_segs, rotate(360 / n_toroid_segs, [0,1,0]) }\r
    sweep { n_circle_segs, rotate(360 / n_circle_segs, (r_major,0,0)) } \r
      (r_major + r_minor, 0)\r
@end verbatim\r
@indent\r
For intuition, the idea of the code is to sketch a circle to the right\r
of the origin in the @math{xy}-plane, then rotate that circle ``out of\r
the plane'' about the @math{y}-axis to make the final figure.  This\r
produces the following.  (A view rotation and some axes have been\r
added.)\r
\r
@center @image{ex090}\r
\r
This example also shows that the swept object may itself be another\r
@code{sweep}.\r
@sxindex sweep\r
@cindex nesting, swept object\r
In fact, it may be @emph{any} @code{sketch} expression that results in\r
a list of one or more points or, alternately, a list of one or more\r
polylines and polygons.  The latter kind of list can be created with a\r
@verb{|{ }|}-enclosed block, perhaps following a \r
@sxindex put\r
@verb{|put|} or\r
@sxindex repeat\r
@verb{|repeat|}.\r
@sxindex @{ @}@r{, block drawable}\r
\r
@node Polygon sweeps, Polyline sweeps with closure, Nested sweeps, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection Polygon sweeps\r
Sweeping a polygon \r
@cindex polygon sweep\r
@cindex swept polygon\r
creates a closed surface with polygons at the ends,\r
which are just copies of the original, appropriately\r
positioned.  @xref{Solid coil example}. \r
@cindex options, swept object\r
Options on the swept polygon,\r
if they exist, are applied to the ends.  Otherwise the sweep options\r
@cindex options, sweep\r
are used throughout.\r
\r
@node Polyline sweeps with closure, Affine arithmetic, Polygon sweeps, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection Polyline sweeps with closure\r
A polyline sweep with a closure tag \r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
creates another kind of closed\r
surface.  First, the polyline segments are connected by faces, just as\r
without the closure tag.  Then, each set of end points is joined to\r
make a polygon, one for each end.  A code for several views of a\r
cylindrical prism follows.\r
@sxindex def\r
@sxindex repeat\r
@sxindex rotate\r
@sxindex then\r
@sxindex translate\r
@sxindex sweep\r
@sxindex line\r
@opindex fillcolor\r
@verbatim\r
  def n_cyl_segs 20  def n_views 5  def I [1,0,0]\r
  def endopts [fillcolor=lightgray]\r
  repeat { n_views, rotate(180/n_views, [I]) then translate([I] * 2.1) } \r
    sweep[endopts]{ n_cyl_segs<>, rotate(360/n_cyl_segs, [0,1,0]) } \r
      line[fillcolor=white](1,-1)(1,1)\r
@end verbatim\r
@noindent\r
It produces this drawing.\r
\r
@center @image{ex110}\r
\r
@noindent\r
The options of the swept line, if any, are applied to the faces\r
produced by sweeping the line, but not the end polygons.  Otherwise,\r
the sweep options are applied throughout.\r
@cindex options, swept object\r
The @verb{|def|} in this example is an @dfn{option} definition.\r
@cindex definition, options\r
@cindex options definition\r
References to options must be enclosed in square brackets, e.g.@tie{}\r
@verb{|[foo]|}.\r
@cindex reference, options\r
@sxindex [foo]@r{, options reference}\r
You can concatenate several sets of options with a single\r
reference, e.g.@tie{}\r
@verb{|[color, size, style]|}\r
would cause the option definitions for @code{color}, @code{size},\r
and @code{style} to appear in sequence in the output \r
created by the @code{sketch} command containing the reference.\r
Happily, the syntax of @code{sketch} is such that\r
options references can never be confused with vector references.  While\r
not apparent in this example, options references are useful when\r
defining many objects with a similar appearance.\r
\r
@node Affine arithmetic, More to learn, Polyline sweeps with closure, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection Affine arithmetic\r
The arithmetic @verb{|[I] * 2.1|} above hints at a larger truth.\r
@code{Sketch} operators work on scalars, vectors, points, and\r
transforms according to the general rules of @dfn{affine algebra}.\r
@cindex affine arithmetic\r
This can be helpful for setting up diagrams with computed geometry.\r
For example, if you have triangle vertices @verb{|(p1)|} through\r
@verb{|(p3)|} and need to draw a unit normal vector pointing out of\r
the center of the triangle, this code does the trick.\r
@sxindex def\r
@sxindex polygon\r
@sxindex line\r
@opindex arrows\r
@verbatim\r
  def p1 (1,0,0)  def p2 (0,0.5,0)  def p3 (-0.5,-1,2)\r
  def O (0,0,0)\r
  def N unit( ((p3) - (p2)) * ((p1) - (p2)) )\r
  def n1 ((p1)-(O) + (p2)-(O) + (p3)-(O)) / 3 + (O)\r
  def n2 (n1)+[N]\r
  polygon(p1)(p2)(p3)\r
  line[arrows=*->](n1)(n2)\r
@end verbatim\r
@noindent\r
The first line computes the cross product of two edge vectors of the\r
triangle and scales it to unit length.  The second computes the\r
average of the vertices.  Note that subtraction and addition of the\r
origin effectively convert vectors to points and @emph{vice versa}.\r
The line command draws the normal at the correct spot.\r
\r
@center @image{ex100}\r
\r
Two caveats regarding this example remain.  First, the only way to use\r
@code{PSTricks}-style arrows is with @verb{|arrows=|}.  \r
@opindex arrows\r
The alternative syntax for @code{PSTricks} arrows is not allowed in\r
@verb{|sketch|}. Second, you might like to eliminate the third\r
@verb{|def|} and write instead the following.\r
@verbatim\r
  line[arrows=*->](n1) (n1)+[N]\r
@end verbatim\r
@noindent\r
This is not allowed.  The point lists in drawables may consist only of\r
explicit points or point references.  You may, however, use arithmetic\r
to calculate point components.  The following works, though it's\r
a little cumbersome.\r
@verbatim\r
  line[arrows=*->](n1)((n1)'x+(N)'x, (n1)'y+(N)'y, (n1)'z+(N)'z)\r
@end verbatim\r
@noindent\r
Obviously, the @dfn{tick operator} \r
@cindex tick operator (@code{'})\r
@sxindex 'x@r{,} 'y@r{, and }'z\r
@samp{'x} extracts components of points and\r
vectors. \r
\r
@node More to learn,  , Affine arithmetic, Swept objects\r
@comment  node-name,  next,  previous,  up\r
@subsection More to learn\r
This is not the end of the story on sweeps!  We invite the reader into\r
the main body of this documentation @ref{Sweeps} to learn more.\r
\r
@center @image{ex120}\r
\r
@noindent\r
Who knows where you'll finish?\r
\r
@node Input language, Building a drawing, Introduction by example, Top\r
@comment  node-name,  next,  previous,  up\r
@chapter Input language\r
This chapter describes the @code{sketch} input language in detail.\r
\r
@menu\r
* Language basics::             Case, space, comments, include files.\r
* Drawables::                   Things that can be drawn.\r
* Definitions::                 Giving things names.\r
* Global environment::          Affect the entire drawing.\r
@end menu\r
\r
@node Language basics, Drawables, Input language, Input language\r
@comment  node-name,  next,  previous,  up\r
@section Basics \r
@code{Sketch} input is plain ASCII text, usually stored in an input\r
file.  \r
@cindex input file\r
@cindex file, input\r
It describes a @dfn{scene},\r
so the sketch language is a @dfn{scene description\r
language}.\r
@cindex scene description language\r
@cindex language, scene description\r
@code{Sketch} input is also @dfn{declarative}.\r
@cindex declarative language\r
@cindex language, declarative\r
It merely\r
declares what the scene ought to look like when drawing is complete\r
and says very little about how @code{sketch} should do its work.\r
@code{Sketch} commands are not executed sequentially as in the usual\r
programming language.  They merely contribute to that declaration.\r
\r
A few syntactic details are important.  Case is significant in the\r
@code{sketch} language.  With a few exceptions, white space is not.\r
This includes line breaks.\r
@cindex white space\r
Comments begin with @code{%} or @code{#} and extend to the end of the\r
line.  You can disable a chunk of syntactically correct @code{sketch}\r
code by enclosing it in a @code{def}.\r
@cindex comments\r
There is a simple ``include file'' mechanism. \r
@cindex include file\r
@cindex file, include\r
The command\r
@sxindex input\r
@verbatim\r
  input{otherfile.sk}\r
@end verbatim\r
@noindent\r
causes the contents of @file{otherfile.sk} to be inserted as though\r
they were part of the current file.\r
\r
@menu\r
* Identifiers::                 Names for things.\r
* Key and reserved words::      Names you shouldn't use.\r
* Literals::                    Constants and constructors.\r
* Arithmetic::                  Rules for expressions.\r
* Options::                     Modifying object appearance.\r
@end menu\r
\r
@node Identifiers, Key and reserved words, Language basics, Language basics\r
@comment  node-name,  next,  previous,  up\r
@subsection Identifiers\r
Identifiers in @code{sketch} are references to earlier-defined\r
options, scalars, points, vectors, transforms, drawables, and tags.\r
@cindex identifiers\r
Definitions are explained in @ref{Definitions}.\r
\r
An identifier consists of a leading letter followed by letters,\r
numbers and underscores.  The last character may @emph{not} be an\r
underscore.  Keywords cannot be used as identifiers, and reserved\r
words ought to be avoided. @xref{Key and reserved words}.\r
\r
@node Key and reserved words, Literals, Identifiers, Language basics\r
@comment  node-name,  next,  previous,  up\r
@subsection Key and reserved words\r
@cindex keywords\r
The keywords of @code{sketch} are @code{picturebox} @code{curve}\r
@code{def} @code{dots} @code{frame} @code{global} @code{input}\r
@code{line} @code{polygon} @code{put} @code{repeat} @code{set}\r
@code{sweep} and @code{then}.  The @code{sketch} parser will note a\r
syntax error if any of these are used in place of a proper identifier.\r
\r
In addition, there are reserved words \r
@cindex reserved words\r
that can currently be defined by the user, but with the risk that\r
future versions of @code{sketch} will reject those definitions.  The\r
reserved words are @code{atan2} @code{cos} @code{inverse}\r
@code{perspective} @code{project} @code{rotate} @code{scale}\r
@code{sin} @code{special} @code{sqrt} @code{translate} @code{unit} and\r
@code{view}.\r
\r
@node Literals, Arithmetic, Key and reserved words, Language basics\r
@comment  node-name,  next,  previous,  up\r
@subsection Literals\r
Literals in @code{sketch} include scalars, points, vectors, and\r
transforms.  Literals, along with defined object references,\r
are used in arithmetic expressions.  @xref{Arithmetic}.\r
\r
@menu\r
* Scalar literals::             Just the numbers.\r
* Point and vector literals::   3d quantities.\r
* Transform literals::          Matrix form.\r
@end menu\r
\r
@node Scalar literals, Point and vector literals, Literals, Literals\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Scalar literals\r
@cindex scalar literal\r
@cindex literal, scalar\r
Scalar literals are positive floating point numbers with syntax\r
according to C conventions.  The following are some examples.\r
@example\r
0 1004 .001 8.3143 3. 1.60E-19 6.02e+23 \r
@end example\r
@noindent\r
Scalar literals may not contain embedded spaces.\r
\r
@node Point and vector literals, Transform literals, Scalar literals, Literals\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Point and vector literals\r
@cindex point literal\r
@cindex literal, point\r
@cindex vector literal\r
@cindex literal, vector\r
Points and vector literals have these forms respectively.\r
@example\r
(@i{X},@i{Y},@i{Z})  [@i{X},@i{Y},@i{Z}]\r
@end example\r
@noindent\r
Each of the components is itself a scalar expression.  The\r
@math{z}-components are optional and default to zero.\r
\r
@node Transform literals,  , Point and vector literals, Literals\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Transform literals\r
@cindex transform literal\r
@cindex literal, transform\r
Most transform literals are formed by @dfn{constructors}.\r
@cindex constructor\r
These are summarized in the following table.\r
@multitable {@code{[[@math{a_{11}},@math{a_{12}},@math{a_{13}},@math{a_{14}}],}}{point,vector,vector}{Long column meant to wrap but does it?  Maybe.}\r
@headitem Constructor @tab Param types @tab Description\r
@item @code{rotate(A,P,X)} \r
 @sxindex rotate\r
 @cindex rotation transform\r
 @cindex transform, rotation\r
 @tab scalar,point,vector \r
 @tab Rotate @code{A} degrees about point @code{P} with axis @code{X}\r
   according to the right hand rule. @xref{Right hand rule}.\r
   @code{P} and @code{X} are both optional and default to the origin and\r
   the @math{z}-axis respectively.\r
@item @code{translate(X)} \r
 @sxindex translate\r
 @cindex translation transform\r
 @cindex transform, translation\r
 @tab vector \r
 @tab Translate by @code{X}.\r
@item @code{scale(S)} \r
 @sxindex scale\r
 @cindex scale transform\r
 @cindex transform, scale\r
 @tab scalar\r
 @tab Scale uniformly by factor @code{S}.\r
@item @code{scale(V)} \r
 @sxindex scale\r
 @cindex scale transform\r
 @cindex transform, scale\r
 @tab vector\r
 @tab Scale along each axis by components of @code{V}.\r
@item @code{project()} \r
 @sxindex project\r
 @cindex parallel projection\r
 @cindex projection, parallel\r
 @tab ---\r
 @tab Same as @code{scale([1,1,0])}.\r
@item @code{project(S)} \r
 @sxindex project\r
 @cindex perspective projection\r
 @cindex projection, perspective\r
 @tab scalar\r
 @tab Perspective projection with view center at origin and projection\r
 plane @math{z=-@code{S}}.\r
@item @code{perspective(S)} \r
 @sxindex perspective\r
 @cindex perspective projection\r
 @cindex projection, perspective\r
 @tab scalar\r
 @tab Perspective @emph{transform} identical to @code{project(S)}\r
 except that the @math{z}-coordinate of the transformed result is\r
 @dfn{pseudodepth}, usable by the hidden surface algorithm. \r
 @cindex hidden surface algorithm\r
@item @code{view(E,D,U)} \r
 @sxindex view\r
 @cindex view transform\r
 @cindex transform, view\r
 @tab point,vector,vector\r
 @tab View transform similar to that of @code{OpenGL}'s.  The\r
@emph{eye point} @code{E} is translated to the origin while a rotation\r
is also applied that makes the @emph{view direction vector} @code{D}\r
and the @emph{view ``up'' vector} @code{U} point in the negative\r
@math{z}- and the @math{y}-directions respectively.  If @code{U} is\r
omitted, it defaults to @math{[0,1,0]}. When @code{U} is omitted,\r
@code{D} may be also; it defaults to @code{(0,0,0)-(E)}, a vector\r
pointing from the eye toward the origin.\r
@item @code{view(E,L,U)} \r
 @sxindex view\r
 @cindex view transform\r
 @cindex transform, view\r
 @tab point,point,vector\r
 @tab An alternate form of @code{view(E,D,U)} above where \r
 the view direction parameter @code{D} is replaced with a\r
``look at'' point @code{L}, i.e., a point where the viewer is focusing\r
her attention.  This form of view is equivalent to\r
@code{view(E, (L)-(E), U)}, where @code{(L)-(E)} is a direction\r
vector. @code{U} is optional and defaults to @math{[0,1,0]}.\r
@item\r
@code{[[@math{a_{11}},@math{a_{12}},@math{a_{13}},@math{a_{14}}]}@*\r
@code{@w{ }[@math{a_{21}},@math{a_{22}},@math{a_{23}},@math{a_{24}}]}@*\r
@code{@w{ }[@math{a_{31}},@math{a_{32}},@math{a_{33}},@math{a_{34}}]}@*\r
@code{@w{ }[@math{a_{41}},@math{a_{42}},@math{a_{43}},@math{a_{44}}]]}@*\r
  @sxindex [[ ][ ][ ][ ]]@r{, transform literal}\r
  @cindex direct transform\r
  @cindex transform, direct\r
  @tab 16 scalars \r
  @tab Direct transform matrix definition. Each\r
  of the @math{a_{ij}} is a scalar expression. See text for details.\r
@end multitable\r
@noindent\r
The @code{project} \r
@sxindex project\r
constructor is not generally useful because it\r
defeats hidden surface removal by collapsing the scene onto a single\r
plane.  It is a special purpose transform for drawing pictures of\r
scenes where three-dimensional objects are being projected onto\r
planes.  See, for example, @ref{Overview}.\r
\r
The direct transform constructor \r
@sxindex [[ ][ ][ ][ ]]@r{, transform literal}\r
@cindex direct transform\r
@cindex transform, direct\r
allows direct entry of a 4x4 transformation matrix. Most 3d graphics\r
systems, including @code{sketch}, use 4-dimensional homogeneous\r
coordinates internally. These are transformed by multiplication with\r
4x4 matrices.  The built-in constructors (@code{rotate}, @code{scale},\r
etc.) are all translated internally to such 4x4 matrices. For more\r
information on homogeneous coordinate transformations, see any good\r
computer graphics textbook. The direct transform feature of\r
@code{sketch} allows you to enter a matrix of your own choice. There\r
are not many cases where this is useful, but if you do need it, you\r
need it badly!\r
\r
@node Arithmetic, Options, Literals, Language basics\r
@subsection Arithmetic expressions\r
Arithmetic expressions over @code{sketch} literals and\r
defined identifiers are summarized in the following tables.\r
\r
@menu\r
* Two-operand (binary) forms::  A op B\r
* Unary forms::                 op A (and others)\r
@end menu\r
\r
@node Two-operand (binary) forms, Unary forms, Arithmetic, Arithmetic\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Two-operand (binary) forms and precedence\r
Most two-operand binary \r
@cindex binary form\r
@cindex two-operand form\r
forms have meanings dependent on the types of\r
their arguments.  An exhaustive summary of the possibilities is given\r
in the following table.\r
@multitable {transform}{@code{then}}{transform}{transform}{a long description that really ought to wrap but does it I do not know}\r
@headitem Left @tab Op @tab Right @tab Result @tab Description\r
@item scalar @tab @code{+} @tab scalar \r
@sxindex +@r{, plus operator}\r
@tab scalar @tab Scalar sum.\r
@item vector @tab @code{+} @tab vector\r
@tab  vector @tab Vector sum.\r
@item point  @tab @code{+} @tab vector\r
@tab  point  @tab Point-vector affine sum.\r
@item vector @tab @code{+} @tab point\r
@tab  "         @tab " \r
@item scalar    @tab @code{-} @tab scalar\r
@sxindex -@r{, minus operator}\r
@tab  scalar    @tab Scalar difference.\r
@item vector    @tab @code{-} @tab vector\r
@tab  vector    @tab Vector difference.\r
@item point     @tab @code{-} @tab point\r
@tab  vector    @tab Point-point affine difference.\r
@item point     @tab @code{-} @tab vector\r
@tab  point     @tab Point-vector affine difference.\r
@item scalar    @tab @code{*} or \r
                     @code{.} @tab scalar\r
@sxindex *@r{, multiplication operator}\r
@sxindex .@r{, dot operator}\r
@tab  scalar    @tab Scalar product.\r
@item scalar    @tab @code{*} or \r
                     @code{.} @tab vector\r
@tab  vector    @tab Scalar-vector product.\r
@item vector    @tab @code{*} or \r
                     @code{.} @tab scalar\r
@tab  "         @tab " \r
@item vector    @tab @code{*} @tab vector\r
@tab  vector    @tab Vector cross-product.\r
@item vector    @tab @code{.} @tab vector\r
@tab  scalar    @tab Vector dot product.\r
@item scalar    @tab @code{^} @tab scalar\r
@sxindex ^@r{, exponentiation operator}\r
@tab  scalar    @tab Raise scalar to scalar power.\r
@item transform @tab @code{^} @tab integer\r
@tab  transform @tab Raise transform to integer power.\r
@cindex transform\r
@item transform @tab @code{*} or \r
                     @code{.} @tab point\r
@tab  point     @tab Affine point transform (right-to-left).\r
@item transform @tab @code{*} or \r
                     @code{.} @tab vector\r
@tab  vector    @tab Affine vector transform (right-to-left).\r
@item transform @tab @code{*} or \r
                     @code{.} @tab transform\r
@tab  transform @tab Transform composition (right-to-left).\r
@item point     @tab @code{then} @tab transform\r
@sxindex then\r
@tab  point     @tab Affine point transform (left-to-right).\r
@item vector    @tab @code{then} @tab transform\r
@tab  vector    @tab Affine vector transform (left-to-right).\r
@item transform @tab @code{then} @tab transform\r
@tab  transform @tab Transform composition (left-to-right).\r
@item scalar    @tab @code{/} @tab scalar\r
@sxindex /@r{, division operator}\r
@tab  scalar    @tab Scalar division.\r
@item vector    @tab @code{/} @tab scalar\r
@tab  vector    @tab Vector component-wise division by scalar.\r
@item point     @tab @code{'} @tab @code{x}, @code{y}, or @code{z}\r
@cindex tick operator (@code{'})\r
@sxindex 'x@r{,} 'y@r{, and }'z\r
@tab  scalar    @tab Point component extraction.\r
@item vector    @tab @code{'} @tab @code{x}, @code{y}, or @code{z}\r
@tab  scalar    @tab Vector component extraction.\r
@end multitable\r
@sp 1\r
@noindent\r
Operator precedence \r
@cindex precedence, operator\r
@cindex operator precedence\r
is shown in this table.\r
@multitable {@code{then}} {highest (most tightly binding)}\r
@headitem Op        @tab Precedence\r
@item @code{'}      @tab highest (most tightly binding)\r
@item @code{^}      @tab \r
@item @code{-}      @tab (unary negation)\r
@item @code{*}\r
      @code{.}\r
      @code{/}      @tab \r
@item @code{+}\r
      @code{-}      @tab\r
@item @code{then}   @tab lowest (least tightly binding)\r
@end multitable\r
@sp 1\r
@noindent\r
All operations are left-associative \r
@cindex operator associativity\r
@cindex associativity, operator\r
except for @samp{^}.\r
Parentheses @samp{( )} \r
@cindex parentheses\r
@sxindex ( )@r{, grouping}\r
are used for grouping to override precedence in the usual way.\r
\r
As you can see, the dot operator @samp{.} \r
@sxindex .@r{, dot operator}\r
is usually a synonym for run-of-the-mill multiplication, @samp{*}.\r
The meanings differ only for vector operands.  The @code{then}\r
operator\r
@sxindex then\r
merely reverses the operand\r
order with respect to normal multiplication @samp{*}.  The intent\r
here is to make compositions read more naturally. The code\r
@example\r
(1,2,3) then scale(2) then rotate(30) then translate([1,3,0]) \r
@end example\r
@noindent\r
expresses a series of successive modifications to the point,\r
whereas the equivalent form\r
@sxindex *@r{, multiplication operator}\r
@example\r
translate([1,3,0]) * rotate(30) * scale(2) * (1,2,3)\r
@end example\r
@noindent\r
will be intuitive only to mathematicians (and perhaps Arabic\r
language readers). \r
\r
@node Unary forms,  , Two-operand (binary) forms, Arithmetic\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Unary forms\r
Unary or one-operand forms\r
@cindex unary form\r
@cindex one-operand form\r
are summarized in the following table, where @code{X}\r
stands for the operand.\r
@multitable{@code{inverse(X)}}{transform}{transform}{Long description meant to wrap eventually.}\r
@headitem Op         @tab Operand \r
 @tab Result @tab Description\r
@item @code{-X}      @tab scalar\r
@sxindex -@r{, unary minus operator}\r
 @tab scalar @tab Unary scalar negation.\r
@item @code{-X}      @tab vector\r
 @tab vector @tab Unary vector negation.\r
@item @code{|X|}     @tab vector\r
 @sxindex |@math{X}|@r{, magnitude operator}\r
 @tab scalar @tab Vector length.\r
@item @code{unit(X)} @tab vector\r
 @sxindex unit\r
 @tab vector @tab Unit vector with same direction.\r
@item @code{sqrt(X)} @tab scalar\r
 @sxindex sqrt\r
 @tab scalar @tab Scalar square root.\r
@item @code{sin(X)} @tab scalar\r
 @sxindex sin\r
 @tab scalar @tab Trigonometric sine (@code{X} in degrees).\r
@item @code{cos(X)} @tab scalar\r
 @sxindex cos\r
 @tab scalar @tab Trigonometric cosine (@code{X} in degrees).\r
@item @code{atan2(X,Y)} @tab scalar\r
 @sxindex atan2\r
 @tab scalar @tab Polar angle in degrees of vector @math{[X,Y]}.\r
@item @code{inverse(X)} @tab transform\r
 @sxindex inverse\r
 @tab transform @tab Inverse transform.\r
@end multitable\r
@sp 1\r
@noindent\r
Errors are reported when @code{|X|}, @code{unit}, @code{sqrt},\r
@code{atan2}, and @code{inverse} fail due to bad parameters.\r
\r
@node Options,  , Arithmetic, Language basics\r
@comment  node-name,  next,  previous,  up\r
@subsection Options\r
@cindex options\r
@strong{Syntax:}\r
@example\r
[@var{key1}=@var{val1},@var{key2}=@var{val2},@dots{}]\r
@end example\r
@noindent\r
Options are used to specify details of the appearance of drawables.\r
As shown above, they are given as comma-separated key-value\r
pairs. \r
\r
@menu\r
* PSTricks options::            Options inherited from @code{PSTricks}.\r
* TikZ/PGF options::            Options inherited from @code{TikZ/PGF}.\r
* Dots in TikZ/PGF::            Sketch uses @code{TikZ/PGF} circles for dots.\r
* TikZ/PGF user-defined styles::  Support for @code{TikZ/PGF} named, user-defined styles.\r
* Transparency::                See-through polygons.\r
* Internal options::            Options used by @code{sketch}.\r
@end menu\r
\r
@node PSTricks options, TikZ/PGF options, Options, Options\r
@comment  node-name,  next,  previous,  up\r
@subsubsection @code{PSTricks} options\r
When @code{language pstricks} is selected (the default), permissible\r
key-value pairs include all those for similar @code{PSTricks} objects.\r
For example, a polygon might have the options\r
@verbatim\r
  [linewidth=1pt,linecolor=blue,fillcolor=cyan]\r
@end verbatim\r
@noindent\r
@code{Sketch} merely passes these on to @code{PSTricks} without\r
checking or modification.  Option lists are always optional.  A\r
missing options list is equivalent to an empty one @samp{[]}.\r
\r
When a @code{polygon} has options for both its face and its edges, and\r
the polygon is split by the hidden surface algorithm, @code{sketch}\r
must copy the edge options to @code{psline}s for the edge segments and\r
the face options to @code{pspolygon}s.  Options known to @code{sketch}\r
for purposes of this splitting operation include @code{arrows},\r
@code{dash}, @code{dotsep}, @code{fillcolor}, @code{fillstyle},\r
@code{linecolor}, @code{linestyle}, @code{linewidth}, @code{opacity}, \r
@code{showpoints}, @code{strokeopacity}, and @code{transpalpha}.\r
\r
@node TikZ/PGF options, Dots in TikZ/PGF, PSTricks options, Options\r
@comment  node-name,  next,  previous,  up\r
@subsubsection @code{TikZ/PGF} options\r
@code{TikZ/PGF} options are handled much as for @code{PSTricks}.\r
Though @code{TikZ/PGF} often allows colors and styles to be given\r
without corresponding keys, for example,\r
@verbatim\r
  \draw[red,ultra thick](0,0)--(1,1);\r
@end verbatim\r
@noindent\r
this is not permitted in @code{sketch}.  To draw a red, ultra-thick\r
line in @code{sketch}, the form is\r
@verbatim\r
  line[draw=red,style=ultra thick](0,0)(1,1)\r
@end verbatim\r
\r
Just as for @code{PSTricks}, when a @code{polygon} has options for\r
both its face and its edges, and the polygon is split by the hidden\r
surface algorithm, @code{sketch} must copy the edge options to\r
@code{psline}s for the edge segments and the face options to\r
@code{pspolygon}s.  @code{TikZ/PGF} options known to @code{sketch} for\r
purposes of this splitting operation include @code{arrows},\r
@code{cap}, @code{color}, @code{dash pattern}, @code{dash phase},\r
@code{double distance}, @code{draw}, @code{draw opacity}, @code{fill},\r
@code{fill opacity}, @code{join}, @code{line width}, @code{miter\r
limit}, @code{pattern}, @code{pattern color}, and @code{style}.\r
\r
The @code{style} option can contain both face and edge information, so\r
@code{sketch} must check the style value.  Values known to\r
@code{sketch} include @code{dashed}, @code{densely dashed},\r
@code{densely dotted}, @code{dotted}, @code{double}, @code{loosely\r
dashed}, @code{loosely dotted}, @code{nearly opaque}, @code{nearly\r
transparent}, @code{semithick}, @code{semitransparent}, @code{solid},\r
@code{thick}, @code{thin}, @code{transparent}, \r
@code{ultra nearly transparent}, @code{ultra thick}, @code{ultra thin}, \r
@code{very nearly transparent}, @code{very thick}, and @code{very thin}.\r
\r
@node  Dots in TikZ/PGF, TikZ/PGF user-defined styles, TikZ/PGF options, Options\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Dots in @code{TikZ/PGF}\r
@code{TikZ/PGF} does not have a @code{dots} command as does PSTricks.\r
Instead, @code{Sketch} emits dots as @code{filldraw} circles.  The\r
diameter may be set using the option @code{dotsize} borrowed from\r
PSTricks.  The @code{dotsize} option will be removed from the option\r
list in the output @code{filldraw} command.  Other options work in the\r
expected way.  For example, @code{fill} sets fill color and\r
@code{color} sets line color of the circles.\r
\r
@node  TikZ/PGF user-defined styles, Transparency, Dots in TikZ/PGF, Options\r
@comment  node-name,  next,  previous,  up\r
@subsubsection @code{TikZ/PGF} user-defined styles\r
@code{TikZ/PGF} allows named styles defined by the user, for\r
example\r
@verbatim\r
  \tikzstyle{mypolygonstyle} = [fill=blue!20,fill opacity=0.8]  \r
  \tikzstyle{mylinestyle} = [red!20,dashed]\r
@end verbatim\r
@noindent\r
Since @code{sketch} has no information on the contents of such styles,\r
it omits them entirely from lines, polygons, and their edges during\r
option splitting.  For example,\r
@verbatim\r
  polygon[style=mypolygonstyle,style=thick](0,0,1)(1,0,0)(0,1,0)\r
  line[style=mylinestyle](-1,-1,-1)(2,2,2)\r
@end verbatim\r
@noindent\r
produces the @code{TikZ} output\r
@verbatim\r
  \draw(-1,-1)--(.333,.333);\r
  \filldraw[thick,fill=white](0,0)--(1,0)--(0,1)--cycle;\r
  \draw(.333,.333)--(2,2);\r
@end verbatim\r
@noindent\r
Note that the user-defined styles are not present.  Sketch also issues\r
warnings:\r
@verbatim\r
  warning, unknown polygon option style=mypolygonstyle will be ignored\r
  warning, unknown line option style=mylinestyle will be ignored\r
@end verbatim\r
\r
The remedy is to state explicitly whether a user-defined style should\r
be attched to polygons or lines in the @code{TikZ} output using\r
@emph{pseudo-options} @code{fill style} and @code{line style},\r
@cindex pseudo-options\r
@sxindex fill style\r
@sxindex line style\r
@verbatim\r
  polygon[fill style=mypolygonstyle,style=thick](0,0,1)(1,0,0)(0,1,0)\r
  line[line style=mylinestyle](-1,-1,-1)(2,2,2)\r
@end verbatim\r
@noindent\r
Now, the output is\r
@verbatim\r
  \draw[mylinestyle](-1,-1)--(.333,.333);\r
  \filldraw[mypolygonstyle,thick](0,0)--(1,0)--(0,1)--cycle;\r
  \draw[mylinestyle](.333,.333)--(2,2);\r
@end verbatim\r
\r
A useful technique is to include user-defined style definitions in\r
@code{sketch} code as @code{special}s with option @code{[lay=under]}\r
to ensure that the styles are emitted first in the output, before\r
any uses of the style names.\r
@footnote{This clever trick is due to Kjell Magne Fauske.}  For\r
example,\r
@verbatim\r
  special|\tikzstyle{mypolygonstyle} = [fill=blue!20,fill opacity=0.8]|[lay=under]\r
  special|\tikzstyle{mylinestyle} = [red!20,dashed]|[lay=under]\r
@end verbatim\r
@noindent\r
The author is responsible for using the key, @code{line style}\r
or @code{fill style}, that matches the content of the style\r
definition.\r
\r
@node  Transparency, Internal options, TikZ/PGF user-defined styles, Options\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Transparency\r
@cindex transparency\r
Both @code{PSTricks} and @code{TikZ/PGF} support polygon options that\r
have the effect of making the polygon appear transparent.  For\r
@code{PSTricks}, keyword @code{transpalpha} was used during initial\r
development of transparency features, and @code{opacity} was adopted \r
later. @code{Sketch} honors both. @code{TikZ/PGF} uses @code{opacity} only.\r
@opindex transpalpha\r
@opindex opacity\r
@opindex fill opacity\r
When transparent polygons are in the foreground, objects behind them\r
(drawn earlier) are visible with color subdued and tinted.  The hidden\r
surface algorithm of @code{sketch} works well with such transparent\r
polygons.\r
\r
Note that @verb{|cull=false|}\r
@opindex cull\r
must be used for rear-facing polygons to be visible when positioned\r
behind other transparent surfaces.\r
\r
@node Internal options,  , Transparency, Options\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Internal options\r
There are also @emph{internal} options\r
@cindex options, internal\r
@cindex internal options\r
used only by @code{sketch} and not\r
passed on to @code{PSTricks}.  These are summarized in the following\r
table.\r
@sxindex cull\r
@sxindex lay\r
@sxindex split\r
@multitable {@code{split}}{@code{over}, @code{in}, @code{under}}{A column that ought to wrap.  Will it wrap?  I do not know.}\r
@headitem Key @tab Possible values @tab Description\r
@item @code{cull}\r
@tab  @code{true}, @code{false}\r
@tab  Turn culling of backfaces on and off respectively for this object.\r
The default value is @code{true}.\r
@item @code{lay}\r
@tab  @code{over}, @code{in}, @code{under}\r
@tab  Force this object to be @code{under} or\r
@code{over} all other objects in the depth sort\r
@cindex depth sort\r
order created by the hidden surface algorithm.  The default value\r
@code{over} guarantees that output due to the @code{special} will be\r
visible.\r
@item @code{split}\r
@tab  @code{true}, @code{false}\r
@tab  Turn splitting of sweep-generated body polygons \r
@cindex body polygon\r
@cindex polygon, body\r
on and off respectively. @xref{Sweeps}.  The default value @code{true}\r
causes ``warped'' polygons to be split into triangles, which avoids\r
mistakes by the hidden surface algorithm.\r
@end multitable\r
\r
@subsection Point lists\r
@sxindex point list\r
@strong{Syntax:}\r
@example\r
(@var{x1},@var{y1},@var{z1})(@var{x2},@var{y2},@var{z2})@dots{}\r
@end example\r
@noindent\r
A sequence of one or more points makes a point list, a feature\r
common to all drawables.  Each of the point components is a scalar\r
arithmetic expression.  Any point may have the @math{z}-component\r
omitted; it will default to @math{z=0}.\r
\r
@menu\r
* Drawables::                   Things that are drawn.\r
* Definitions::                 Things with names.\r
@end menu\r
\r
@node Drawables, Definitions, Language basics, Input language\r
@comment  node-name,  next,  previous,  up\r
@section Drawables\r
@cindex drawable\r
Drawables are simply @code{sketch} objects that might appear in the\r
drawing.  They include dots, polylines, curves, polygons, and more\r
complex objects that are built up from simpler ones in various ways.\r
Finally, @dfn{special} objects are those composed of @LaTeX{} or\r
@code{PSTricks} code, perhaps including coordinates and angles\r
computed by @code{sketch}.\r
\r
@menu\r
* Dots::                        Draw dots.\r
* Lines::                       Draw polylines.\r
* Curves::                      Draw curves.\r
* Polygons::                    Draw polygons.\r
* Specials::                    Embed raw @LaTeX{} and @code{PSTricks}.\r
* Sweeps::                      Draw sweeps of dots and polylines.\r
* Blocks::                      Group other drawables.\r
* Repeats::                     Draw transformed copies of objects.\r
* Puts::                        Draw one object transformed.\r
@end menu\r
\r
@node Dots, Lines, Drawables, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Dots\r
@sxindex dots\r
@strong{Syntax:}\r
@example\r
dots[@var{options}] @var{point_list}\r
@end example\r
@noindent\r
This command is the three-dimensional equivalent of the\r
@code{PSTricks} command @code{\psdots}.\r
\r
@node Lines, Curves, Dots, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Lines\r
@sxindex line\r
@strong{Syntax:}\r
@example\r
line[@var{options}] @var{point_list}\r
@end example\r
@noindent\r
This command is the three-dimensional equivalent of the \r
@code{PSTricks} command @code{\psline}.\r
\r
@node Curves, Polygons, Lines, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Curves\r
@sxindex curve\r
@strong{Syntax:}\r
@example\r
curve[@var{options}] @var{point_list}\r
@end example\r
@noindent\r
This command is the three-dimensional equivalent of the \r
@code{PSTricks} command @code{\pscurve}. @b{It is not\r
implemented in the current version of @code{sketch}}.\r
\r
@node Polygons, Specials, Curves, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Polygons\r
@sxindex polygon\r
@strong{Syntax:}\r
@example\r
polygon[@var{options}] @var{point_list}\r
@end example\r
@noindent\r
@noindent\r
This command is the three-dimensional equivalent of the\r
@code{PSTricks} command @code{\pspolygon}.  The @code{sketch} hidden\r
surface algorithm assumes that polygons are convex and planar.  \r
@cindex polygon, planar\r
@cindex planarity of polygons\r
In practice, drawings may well turn out correctly even if these\r
assumptions are violated.\r
\r
@node Specials, Sweeps, Polygons, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Specials\r
@sxindex special\r
@strong{Syntax:}\r
@example\r
special $@var{raw_text}$[lay=@var{lay_value}] @var{point_list}\r
@end example\r
@noindent\r
Here @code{$} \r
@cindex quoting, special\r
can be any character and is used to delimit the start\r
and end of @var{raw_text}.  The command embeds @var{raw_text} in the\r
@code{sketch} output after performing substitutions as follows.\r
@cindex special argument substitution\r
@cindex argument, special\r
@itemize\r
@item \r
@code{#@var{i}} where @var{i} is a positive integer is replaced by \r
the @var{i}'th point in @var{point_list}.\r
@item\r
@code{#@{@var{i}@}} is also replaced as above.\r
@item\r
@code{#@var{i}-@var{j}} where @var{i} and @var{j} are positive\r
integers is replaced by a string @code{@{@var{angle}@}} where\r
@var{angle} is the polar angle of a vector from the @var{i}'th point\r
in @var{point_list} to the @var{j}'th.\r
@item\r
@code{#@{@var{i}-@var{j}@}} is also replaced as above.\r
@item \r
@code{##} is replaced with @code{#}.\r
@end itemize\r
@noindent\r
The forms with braces @samp{@{ @}} are useful when the argument is\r
immediately followed by a digit that is part of the @TeX{} code.\r
\r
The only useful option of @code{special} is @code{lay}.\r
@sxindex lay\r
@xref{Internal options}.\r
\r
@node Sweeps, Blocks, Specials, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Sweeps\r
@sxindex sweep\r
@strong{Syntax:}\r
@example\r
sweep @{ @var{n}, @var{T_1}, @var{T_2}, @dots{}, @var{T_@math{r}} @}[@var{options}] @var{swept_object}\r
sweep @{ @var{n}<>, @var{T_1}, @var{T_2}, @dots{}, @var{T_@math{r}} @}[@var{options}] @var{swept_object}\r
@end example\r
@noindent\r
The sweep connects @var{n} (or perhaps @math{@var{n}+1}) copies of\r
@var{swept_object} \r
@cindex swept object\r
in order to create a new object of higher\r
dimension.  The @var{T_@math{i}} (for @math{i} between @math{1} and\r
@math{r}) are transforms.  \r
@cindex transform\r
The @math{k}'th copy of @var{swept_object} is produced by applying the\r
following transform to the original.\r
@example\r
@math{@var{T_1}^k} then @math{@var{T_2}^k} then @dots{} then @math{@var{T_r}^k}\r
@end example\r
@noindent\r
Here @math{@var{T}^k} means ``transform @var{T} applied @math{k}\r
times.''  The original object is the zero'th copy, with @math{k=0} and\r
effectively no transform applied (@math{T^0=I}, the identity\r
transform).\r
\r
The method of connecting the copies depends on the type of\r
@var{swept_object} and on whether the closure tag\r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
@samp{<>} is present\r
or not.\r
\r
An example of a sweep where @math{r=2} is the Mobius figure at\r
@ref{More to learn}.\r
\r
@menu\r
* Swept points::                Swept points make lines or polygons.\r
* Swept lines::                 Swept lines make open or closed surfaces.\r
* Swept polygons::              Swept polygons make closed surfaces.\r
* Swept blocks::                Swept block @equiv{} block of sweeps.\r
* Sweep face splitting::        Fixing warped faces with triangles.\r
@end menu\r
\r
@node Swept points, Swept lines, Sweeps, Sweeps\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Swept points\r
@cindex swept point\r
@cindex point sweep\r
If @var{swept_object} is a point list and there is no closure tag,\r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
then @code{sweep} connects @math{@var{n}+1} successive copies of each\r
point (including the original) with straight line segments to form a\r
polyline.  If there are @math{m} points in the original point list,\r
@cindex point list\r
then @math{m} polylines with @var{n} segments each are formed by the\r
sweep.  In this manner, @code{sweep} forms a set of one-dimensional\r
objects (polylines) from zero-dimensional ones (points).\r
\r
When there @emph{is} a closure tag, \r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
@code{sweep} connects @var{n}\r
successive copies of each point (including the original) with straight\r
line segments and finally connects the last copy back to the original\r
to form a polygon with @var{n} sides.  If there are @math{m} points in\r
the original point list, then @math{m} polygons with @var{n} sides\r
each are formed by the sweep.  In this manner, @code{sweep} forms a\r
set of two-dimensional objects (polygons) from zero-dimensional ones\r
(points).\r
\r
Options \r
@cindex options, sweep\r
of the @code{sweep} are copied directly to the resulting\r
polyline(s).\r
\r
@node Swept lines, Swept polygons, Swept points, Sweeps\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Swept lines\r
@cindex swept line\r
@cindex line sweep\r
If @var{swept_object} is a polyline and there is no closure tag, \r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
then\r
@code{sweep} connects @math{@var{n}+1} successive copies of the\r
polyline (including the original) with four-sided polygons, each pair\r
of copies giving rise to a ``polygon strip.''  If there are @math{m}\r
points in the original polyline, then @math{(m-1)@var{n}} polygons are\r
formed by the sweep.  We call these @dfn{body polygons}.\r
@cindex body polygon\r
@cindex polygon, body\r
In this manner, @code{sweep} forms a\r
two-dimensional surface from from a one-dimensional polyline.\r
\r
The order of vertices \r
@cindex polygon vertex order\r
@cindex order, polygon vertex\r
produced by @code{sweep} is important.  If a\r
polygon's vertices do not appear in counter-clockwise order in the\r
final image, the polygon will be culled \r
@cindex culling\r
(unless @code{cull=false} is\r
set).  If the points in the @math{k}'th copy of the polyline are\r
@math{P_1}, @math{P_2}, @dots{}, @math{P_m}, and the points in the\r
next copy, the @math{(k+1)}st, are @math{P_1'}, @math{P_2'}, @dots{},\r
@math{P_m'}, then the vertex order of the generated polygons is\r
@display\r
Body polygon 1: @math{P_2} @math{P_1} @math{P_1'} @math{P_2'} \r
Body polygon 2: @math{P_3} @math{P_2} @math{P_2'} @math{P_3'} \r
@dots{}\r
Body polygon @math{m-1}: @math{P_m} @math{P_{m-1}} @math{P_{m-1}'} @math{P_m'} \r
@end display\r
\r
Options of unclosed line sweeps \r
@cindex options, sweep\r
are copied to each output polygon.\r
Options of the swept line are ignored.\r
@cindex options, swept object\r
\r
When there @emph{is} a closure tag, \r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
then @code{sweep} connects @var{n}\r
successive copies of the polyline (including the original) with\r
four-sided body polygons just as the case with no closure tag.  It then\r
connects the last copy back to the original to form a ribbon-shaped\r
surface that closes on itself with two holes remaining.\r
\r
Finally, the sweep adds two more polygons to seal the holes and form a\r
closed surface that, depending on the sweep transforms, may\r
represent the boundary of a solid.  In this manner, @code{sweep} forms\r
the boundary of a three-dimensional object from a one-dimensional\r
polyline.  We call these hole-filling polygons @dfn{ends}.\r
@cindex end polygon\r
@cindex polygon, end\r
\r
The order of vertices of end polygons \r
@cindex polygon vertex order\r
@cindex order, polygon vertex\r
is important for correct culling\r
as described above.  If @math{P_1^1}, @math{P_1^2}, @dots{},\r
@math{P_1^n} are the @var{n} copies of the first polyline point and\r
@math{P_m^1}, @math{P_m^2}, @dots{} ,@math{P_m^n} are the @var{n}\r
copies of the last polyline point, then the end polygon vertex order\r
is\r
@display\r
End polygon 1: @math{P_1^n}, @math{P_1^{n-1}}, @dots{} ,@math{P_1^1}\r
End polygon 2: @math{P_m^1}, @math{P_m^2}, @dots{} ,@math{P_m^n}\r
@end display\r
\r
If there are no options on the swept line, \r
@cindex options, swept object\r
then the @samp{sweep}\r
options \r
@cindex options, sweep\r
are copied to each output polygon.  If the swept line does\r
have options, these are copied to corresponding body polygons; the\r
sweep options are copied to the end polygons.  In this manner, body\r
and ends may be drawn with different characteristics such as\r
@code{fillcolor}.\r
\r
@node Swept polygons, Swept blocks, Swept lines, Sweeps\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Swept polygons\r
@cindex polygon sweep\r
If @var{swept_object} is a polygon, the @code{sweep} connects\r
@math{@var{n}+1} successive copies of the closed polyline border of\r
the polygon to form body polygons exactly as though the border were a\r
swept polyline as described in @ref{Swept lines}.\r
@cindex body polygon\r
@cindex polygon, body\r
If there are @math{m} points in the\r
original polygon, then @math{m@var{n}} body polygons are formed by\r
this sweep.  The body polygons form an @dfn{extrusion} of the boundary of the\r
original polygon with two holes at the open ends.  \r
\r
Finally, the sweep adds two copies of the original polygon to cover\r
the holes.  We call these hole-filling polygons @dfn{ends}.\r
@cindex end polygon\r
@cindex polygon, end\r
In this manner, @code{sweep} forms the boundary of a three-dimensional\r
object from a two-dimensional polygon.\r
\r
The order of vertices \r
@cindex polygon vertex order\r
@cindex order, polygon vertex\r
of end polygons is important for correct culling as described above.\r
An exact copy of the original polygon with vertex order intact forms\r
the first end polygon.  The other end polygon results from\r
transforming and the reversing the order of vertices in the original.\r
The transform places the original polygon at the uncovered hole;\r
it is\r
@example\r
@math{@var{T_1}^n} then @math{@var{T_2}^n} then @dots{} then @math{@var{T_r}^n}.\r
@end example\r
@noindent\r
If there are no options on the swept polygon, then the @samp{sweep}\r
options are copied to each output polygon.  If the swept polygon does\r
have options, these are copied to the ends; the sweep options are\r
copied to the body polygons.  In this manner, body and ends may be\r
drawn with different characteristics such as @code{fillcolor}.\r
\r
@node Swept blocks, Sweep face splitting, Swept polygons, Sweeps\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Swept blocks\r
@cindex swept bock\r
@cindex block sweep\r
The swept object @var{swept_object} may also be any collection of\r
polylines and polygons.  This may be a block \r
@cindex block\r
@sxindex @{ @}@r{, block drawable}\r
composed of @code{line} \r
@sxindex line\r
and/or @code{polygon} \r
@sxindex polygon\r
commands in braces\r
@samp{@{ @}}, or it may be the result of a @code{repeat}, another\r
@code{sweep}, etc.  The sweep acts independently on each object in the\r
block exactly as if it were a single swept object described above in\r
@ref{Swept lines} and @ref{Swept polygons}.\r
\r
@node Sweep face splitting,  , Swept blocks, Sweeps\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Sweep face splitting\r
Before sending each four-sided body polygon of a @code{sweep}\r
to the output, @code{sketch} tests to see if it is roughly planar.\r
@cindex polygon, planar\r
@cindex planarity of polygons\r
Since planarity is necessary for proper functioning of the hidden\r
surface algorithm, ``warped'' polygons are automatically split into\r
two triangles.  \r
\r
Hole-filling polygons produced by closure-tagged \r
@sxindex <>@r{, closure tag}\r
@cindex closure tag, @code{<>}\r
line sweeps are not\r
split.  Nor are original polygons in polygon sweeps.  It is the user's\r
responsibility to ensure these are planar.\r
\r
@node Blocks, Repeats, Sweeps, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Blocks\r
@cindex block\r
@sxindex @{ @}@r{, block drawable}\r
Any sequence of drawables may be grouped in a @dfn{block} merely by\r
enclosing them in braces @samp{@{ @}}.  A block is itself drawable.  A\r
key use of blocks is to extend the effect of a single @code{def},\r
@ref{Definitions}, @code{put} @ref{Puts}, @code{sweep} @ref{Sweeps},\r
or @code{repeat} @ref{Repeats} to include several objects rather than\r
one.\r
\r
Definitions (@xref{Definitions}.) inside a block have @dfn{lexical\r
scope} \r
@cindex lexical scope\r
@cindex scope, identifier\r
extending from the place of definition to the end of the block.\r
\r
@node Repeats, Puts, Blocks, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Repeats\r
@sxindex repeat\r
@cindex repeated object\r
@strong{Syntax:}\r
@example\r
repeat @{ @var{n}, @var{T_1}, @var{T_2}, @dots{}, @var{T_r} @} @var{repeated_object}\r
@end example\r
@noindent\r
The repeat makes @var{n} transformed copies of @var{repeated_object}\r
(including the original).  The @var{T_@math{i}} are transforms.\r
@cindex transform\r
The @math{k}'th copy of the @var{repeated_object} (for\r
@math{k=0,1,...,n-1}) is produced in the\r
same manner as for @code{sweep}s described in @ref{Sweeps}.  This is\r
repeated here (no pun intended) for convenience.  To make the\r
@math{k}'th copy, the following transform is applied to the\r
original object.\r
@example\r
@math{@var{T_1}^k} then @math{@var{T_2}^k} then @dots{} then @math{@var{T_r}^k}\r
@end example\r
@noindent\r
Here @math{@var{T}^k} means ``transform @var{T} applied @math{k}\r
times.'' \r
\r
@node Puts,  , Repeats, Drawables\r
@comment  node-name,  next,  previous,  up\r
@subsection Puts\r
@sxindex put\r
@strong{Syntax:}\r
@example\r
put @{ @var{T} @} @var{put_object}\r
@end example\r
@noindent\r
Put merely applies transform @var{T} to the drawable @var{put_object}.\r
\r
@node Definitions, Global environment, Drawables, Input language\r
@comment  node-name,  next,  previous,  up\r
@section Definitions\r
@cindex definition\r
Definitions give names to @code{sketch} objects.  Definitions alone\r
are benign.  A @code{sketch} input file consisting entirely of\r
definitions will generate no drawing.  Only when definitions are\r
@dfn{referenced} do they potentially lead to ink on the drawing.\r
\r
The intent of definitions is to make @code{sketch} code more concise\r
and readable.  There is no input file employing definitions\r
that could not be re-written without them.\r
\r
Definable objects include any result of an affine arithmetic\r
expression (scalar, point, vector, or transform), any drawable\r
object (dots, line, curve, polygon, block, sweep, put, repeat, or\r
special), and option strings.  In addition, @dfn{tag definitions},\r
@cindex definition, tag\r
@cindex tag definition\r
which have no associated object at all, allow the meaning of other\r
definitions to be selected from a set of alternatives. Since tags may\r
be defined (and undefined) in the command line of @code{sketch}, they\r
can be an aid in the script-driven preparation of documents.\r
\r
@menu\r
* Forms of definitions::        Different defs for different purposes.\r
* Forms of references::         How references denote types.\r
@end menu\r
\r
@node Forms of definitions, Forms of references, Definitions, Definitions\r
@comment  node-name,  next,  previous,  up\r
@subsection Forms of definitions\r
Definitions have three possible forms, @dfn{simple}, \r
@cindex simple definition\r
@cindex definition, simple\r
@dfn{with alternatives}, \r
@cindex definition with alternatives\r
@cindex alternatives, definition\r
and @dfn{tag} \r
@cindex tag definition\r
@cindex definition, tag\r
as shown here in order.\r
\r
@noindent\r
@strong{Syntax:}\r
@example\r
def @var{id} @var{object}  % simple def\r
def @var{id} <@var{tag_1}> @var{object_1}  % def with alternatives\r
       <@var{tag_2}> @var{object_2}\r
       @dots{}\r
       <> @var{default_object}\r
def @var{id} <>  % tag def\r
@end example\r
@noindent\r
The simple definition merely associates @var{object} with the\r
identifier @var{id}.  \r
\r
The definition with alternatives associates\r
@var{object_i} with @var{id}, where @var{tag_i} is the\r
first defined tag in the list of alternative tag references.\r
@cindex tag reference\r
@cindex reference, tag\r
@sxindex <foo>@r{, tag reference}\r
If no tag in the list is defined, then @var{default_object} is\r
associated with identifier @var{id}.\r
\r
The final form defines @var{id} as a tag.  Another way to define a tag\r
is with the @option{-D} command line option. @xref{Command line}.\r
\r
@node Forms of references,  , Forms of definitions, Definitions\r
@subsection Forms of references\r
References to defined names are enclosed in bracketing delimiters.\r
The delimiter characters imply the type of the associated value as\r
shown in the table below.  A type error is raised if the type of a\r
reference does not match the type of the defined value.  The intent of\r
this mechanism is, again, to make @code{sketch} input files more\r
readable.\r
@multitable {transform}{@code{[@var{id}]} or @code{[@var{id1}, ..., @var{idN}]}}\r
@headitem Type  @tab Reference\r
@item scalar    @tab @code{@var{id}}\r
@cindex scalar reference\r
@cindex reference, scalar\r
@item point     @tab @code{(@var{id})}\r
@cindex point reference\r
@cindex reference, point\r
@sxindex (foo)@r{, point reference}\r
@item vector    @tab @code{[@var{id}]}\r
@cindex vector reference\r
@cindex reference, vector\r
@sxindex [foo]@r{, vector reference}\r
@item transform @tab @code{[[@var{id}]]}\r
@cindex transform reference\r
@cindex reference, transform\r
@sxindex [[foo]]@r{, transform reference}\r
@item drawable  @tab @code{@{@var{id}@}}\r
@cindex drawable reference\r
@cindex reference, drawable\r
@sxindex @{foo@}@r{, drawable reference}\r
@item options   @tab @code{[@var{id}]} or @code{[@var{id1},...,@var{idN}]}\r
@cindex options reference\r
@cindex reference, options\r
@sxindex [foo]@r{, options reference}\r
@cindex options multiple reference\r
@cindex reference, multiple options\r
@sxindex [foo,...,bar]@r{, multiple options reference}\r
@item tag       @tab @code{<@var{id}>}\r
@cindex tag reference\r
@cindex reference, tag\r
@sxindex <foo>@r{, tag reference}\r
@end multitable\r
@sp 1\r
@noindent\r
Note that square brackets @samp{[ ]} are used both for vector and for\r
options references.  Details of @code{sketch} syntax make it\r
impossible for these two reference types to be confused.  The\r
special multiple reference @code{[@var{id1},@var{id2},...,@var{idN}]}\r
acts as if the respective lists of options were concatenated.\r
\r
@node Global environment,  , Definitions, Input language\r
@comment  node-name,  next,  previous,  up\r
@section Global environment\r
An optional global environment block provides a few ways to affect the\r
entire scene.  The block must appear as the last text in the\r
@code{sketch} input file.  It may include definitions, but note\r
that previous definitions at the top level (not nested inside\r
blocks) are also available.\r
\r
@noindent\r
@strong{Syntax:}\r
@sxindex global\r
@example\r
global @{ @var{environment_settings} @}\r
@end example\r
@noindent\r
The contents of @var{environment_settings} are discussed in the\r
sections that follow.\r
\r
@menu\r
* Global options::              Attributes of the entire drawing.\r
* Camera::                      A final camera transformation of the scene.\r
* Picture box::                 Setting the bounding box and 2d clipping.\r
* Frame::                       Adding a box around the drawing.\r
* Language::                    Setting the output language.\r
@end menu\r
\r
@node Global options, Camera, Global environment, Global environment\r
@comment  node-name,  next,  previous,  up\r
@subsection Global options\r
@cindex options, global\r
@cindex global options\r
@sxindex set\r
@strong{Syntax:}\r
@example\r
set [ @var{options} ]\r
@end example\r
@noindent\r
The contents of @var{options}, except for @code{sketch} internal\r
options, are copied as-is to a @verb{|\psset|} that appears before\r
anything else in the output file.  This is a good place to set\r
@code{unit}, a default @code{linewidth}, etc.\r
\r
Internal options \r
@cindex options, internal\r
@cindex internal options\r
work on all objects where they make sense.\r
This includes \r
@sxindex cull\r
@sxindex split\r
@sxindex lay\r
@code{cull} and @code{split} (but not @code{lay}).\r
@xref{Internal options}. \r
\r
@node Camera, Picture box, Global options, Global environment\r
@comment  node-name,  next,  previous,  up\r
@subsection Camera\r
@cindex camera\r
@strong{Syntax:}\r
@sxindex camera\r
@example\r
camera @var{transform_expression}\r
@end example\r
The @var{transform_expression} is applied after all other\r
transformations of the scene.  This is currently only useful for\r
transforming the bounding box.  @xref{Picture box}.  It will play a\r
role in any future implementation of clipping.\r
\r
@node Picture box, Frame, Camera, Global environment\r
@comment  node-name,  next,  previous,  up\r
@subsection Picture box\r
@cindex picture box\r
@strong{Syntax:}\r
@sxindex picturebox\r
@example\r
picturebox[@var{baseline}]\r
picturebox[@var{baseline}] (@var{p1})(@var{p2})\r
@end example\r
@noindent\r
The first form of @code{picturebox} causes a scalar @var{baseline}\r
fraction to be emitted in the @code{pspicture}\r
@cindex @code{pspicture}\r
@cindex baseline fraction\r
environment of the output.  See\r
@code{PSTricks} documentation for @code{pspicture}.\r
\r
In the second form, the @var{baseline} fraction is optional, and the\r
two points that follow define the diagonal of a three-dimensional\r
bounding box\r
@cindex bounding box\r
for the completed scene.  The parallel projection \r
@cindex parallel projection\r
@cindex projection, parallel\r
of the bounding box\r
determines the corners of the drawing's @code{pspicture*} environment,\r
which is used in place of @code{pspicture}.  This causes PostScript to\r
clip\r
@cindex clipping\r
the final drawing to the bounding box in 2d.  If there is a\r
@code{camera} specified, the camera tranformation is applied to the\r
bounding box, and the @code{pspicture} is set just large\r
enough to include the transformed box.\r
\r
When no bounding box is given, @code{sketch} computes one\r
automatically.\r
\r
@node Frame, Language, Picture box, Global environment\r
@comment  node-name,  next,  previous,  up\r
@subsection Frame\r
@cindex frame box\r
@strong{Syntax:}\r
@sxindex frame\r
@example\r
frame [@var{options}]\r
@end example\r
@noindent\r
Causes a @verb{|\psframebox|} \r
@cindex @code{psframebox}\r
to surround the @code{pspicture}\r
environment in the output.  If @var{options} are present, they are\r
copied as-is.  Normally one would want to set \r
@opindex linewidth\r
@code{linewidth},\r
@opindex linestyle\r
@code{linestyle}, \r
@opindex linecolor\r
@code{linecolor}, etc. \r
If omitted, then \r
@opindex framesep\r
@code{framesep=0pt} is\r
added so that the frame tightly hugs the @code{pspicture}.\r
\r
@node Language,  , Frame, Global environment\r
@comment  node-name,  next,  previous,  up\r
@subsection Language\r
@cindex language, output\r
@cindex output language\r
@sxindex language\r
@example\r
language tikz\r
language tikz, context\r
language pstricks\r
language pstricks, latex\r
@end example\r
@noindent\r
Sets the output language generated by @code{sketch}.  \r
@sxindex pstricks\r
@sxindex tikz\r
The set of options understood by sketch also changes.  For example,\r
the @code{PSTricks} option @code{linewidth} will not be properly\r
handled if @code{language} is set to @code{tikz}.  Similarly, the\r
@code{TikZ} option @code{line style} (note the space) will not be\r
properly handled if @code{language} is set to @code{pstricks}.  If no\r
language is specified, the default @code{pstricks} is used.\r
\r
An optional comma followed by \r
@code{latex} \r
@sxindex latex\r
or \r
@code{context} \r
@sxindex context\r
specifies the macro package that the output should assume.  This\r
affects the @code{picture} environment commands emitted and the\r
document template used with the @option{-T} option. @xref{Command\r
line}.  Note that at the time this manual was generated,\r
@code{PSTricks} was not supported by @LaTeX{} or by @code{ConTeXt}.\r
\r
@node Building a drawing, Command line, Input language, Top\r
@comment  node-name,  next,  previous,  up\r
@chapter Building a drawing\r
Successful drawings with @code{sketch} and with any scene description\r
language\r
@cindex scene description language\r
require that the user develop an accurate mental picture of her code\r
and its meaning.  This image is best built in small pieces.\r
Therefore, @code{sketch} inputs are best created in small increments\r
with frequent pauses to compile and view the results.  Careful\r
comments in the input often help as a scene grows in complexity.\r
\r
@menu\r
* Overview::                    Building a substantial drawing.\r
* A technical drawing::         An example with fine placement.\r
* A hierarchical model::        An example with sweeps and puts.\r
* Caveats::                     Where trouble can occur.\r
@end menu\r
\r
@node Overview, A technical drawing, Building a drawing, Building a drawing\r
@comment  node-name,  next,  previous,  up\r
@section Overview\r
As an overview, let's develop a diagram that shows how a perspective\r
projection transform\r
@cindex perspective projection\r
@cindex transform\r
@cindex projection, perspective\r
works.  We'll start with the traditional reference object\r
used in computer graphics textbooks, a house-shaped prism.  Begin\r
by defining the points of the house.  Rather than defining the faces\r
of the house as polygons and transforming those, we are going to\r
transform the points themselves with @code{sketch} arithmetic so that\r
we have names for the transformed points later.\r
@sxindex def\r
@verbatim\r
  % right side (outside to right)\r
  def R1 (1,1,1) def R2 (1,-1,1) def R3 (1,-1,-1) def R4 (1,1,-1)\r
  def R5 (1,1.5,0)\r
\r
  % left side (outside to right--backward)\r
  def W  [2,0,0]\r
  def L1 (R1)-[W] def L2 (R2)-[W] def L3 (R3)-[W] def L4 (R4)-[W]\r
  def L5 (R5)-[W]\r
@end verbatim\r
@noindent\r
To add a door to the house, we use a polygon slightly in\r
front of the foremost face of the house.\r
@verbatim\r
  % door\r
  def e .01\r
  def D1 (0,-1,1+e) def D2 (.5,-1,1+e) def D3 (.5,0,1+e) def D4 (0,0,1+e)\r
@end verbatim\r
@noindent\r
Now let's create a new set of points that are a to-be-determined\r
transform of the originals.\r
@verbatim\r
  def hp scale(1) % house positioner\r
  def pR1 [[hp]]*(R1) def pR2 [[hp]]*(R2) def pR3 [[hp]]*(R3)\r
  def pR4 [[hp]]*(R4) def pR5 [[hp]]*(R5)\r
  def pL1 [[hp]]*(L1) def pL2 [[hp]]*(L2) def pL3 [[hp]]*(L3)\r
  def pL4 [[hp]]*(L4) def pL5 [[hp]]*(L5)\r
  def pD1 [[hp]]*(D1) def pD2 [[hp]]*(D2) def pD3 [[hp]]*(D3)\r
  def pD4 [[hp]]*(D4) \r
@end verbatim\r
@noindent\r
Note the use of a @dfn{transform definition} \r
@cindex transform definition\r
@cindex definition, transform\r
@sxindex [[foo]]@r{, transform reference}\r
and\r
@dfn{transform references}.\r
@cindex transform reference\r
@cindex reference, transform\r
@sxindex [[foo]]@r{, transform reference}\r
Now define the seven polygonal faces of the house and the door using\r
the transformed points as vertices.  Be careful with vertex order!\r
@cindex polygon vertex order\r
@cindex order, polygon vertex\r
@opindex fillcolor\r
@sxindex def\r
@sxindex polygon\r
@sxindex @{ @}@r{, block drawable}\r
@verbatim\r
  def rgt polygon (pR1)(pR2)(pR3)(pR4)(pR5)\r
  def lft polygon (pL5)(pL4)(pL3)(pL2)(pL1)\r
  def frt polygon (pR2)(pR1)(pL1)(pL2)\r
  def bck polygon (pR4)(pR3)(pL3)(pL4)\r
  def tfr polygon (pR1)(pR5)(pL5)(pL1)\r
  def tbk polygon (pR5)(pR4)(pL4)(pL5)\r
  def bot polygon (pR2)(pL2)(pL3)(pR3)\r
  def door polygon[fillcolor=brown] (pD1)(pD2)(pD3)(pD4)\r
  def house { {rgt}{lft}{frt}{bck}{tfr}{tbk}{bot}{door} }\r
@end verbatim\r
Time for a sanity check.  Add the line\r
@sxindex @{foo@}@r{, drawable reference}\r
@cindex reference, drawable\r
@verbatim\r
  {house}\r
@end verbatim\r
@noindent\r
and this is what we get.\r
\r
@center @image{ex130}\r
\r
@noindent\r
This is correct, but does not reveal very much.  Common errors are\r
misplaced vertices and polygons missing entirely due to incorrect\r
vertex order.  \r
@cindex polygon vertex order\r
@cindex order, polygon vertex\r
To rule these out, let's inspect all sides of the\r
house. This is not hard. Merely replace the reference\r
@verb{|{house}|} with a @code{repeat}. @xref{Repeats}.\r
@sxindex @{foo@}@r{, drawable reference}\r
@cindex reference, drawable\r
@sxindex repeat\r
@sxindex rotate\r
@sxindex translate\r
@verbatim\r
  repeat { 13, rotate(30, [1,2,3]), translate([3,0,0]) } {house}\r
@end verbatim\r
@center @image{ex140}\r
\r
@noindent\r
Again things look correct.  Note that the hidden surface algorithm\r
handles intersecting polygons correctly where some copies of the house\r
overlap. \r
\r
Let's lay out the geometry of perspective projection of the house onto\r
a plane with rays passing through the origin.  Begin by positioning the\r
house twelve units back on the negative @math{z}-axis and adding a set\r
of coordinate axes.  To move the house we need only change the ``house\r
positioning'' transform defined earlier.\r
@sxindex def\r
@sxindex rotate\r
@sxindex translate\r
@opindex arrows\r
@opindex linewidth\r
@opindex linecolor\r
@opindex linestyle\r
@sxindex special\r
@sxindex line\r
@verbatim\r
  def hp rotate(-40, [0,1,0]) then translate([0,0,-12])\r
  def axes {\r
    def sz 1\r
    line [arrows=<->] (sz,0,0)(O)(0,sz,0)\r
    line [arrows=->]  (O)(0,0,sz)\r
    line [linewidth=.2pt,linecolor=blue,linestyle=dashed] (O)(0,0,-10)\r
    special |\uput[r]#1{$x$}\uput[u]#2{$y$}\uput[l]#3{$z$}|\r
      (sz,0,0)(0,sz,0)(0,0,sz)\r
  }\r
@end verbatim\r
\r
Time for another test.  Let's build a real view transform,\r
creating a @dfn{virtual camera}\r
@cindex virtual camera\r
to look at the scene we are constructing.  Replace the @code{repeat}\r
with\r
@verbatim\r
  def eye (10,4,10)\r
  def look_at (0,0,-5)\r
  put { view((eye), (look_at)) } { {house}{axes} }\r
@end verbatim\r
The @dfn{view transform} repositions the scene so that the point\r
@code{eye} is at the origin and the direction from @code{eye} to\r
@code{look_at} is the negative @math{z}-axis.  This requires a\r
rotation and a translation that are all packed into the constructor\r
@code{view}.\r
\r
@center @image{ex150}\r
\r
@noindent\r
This is starting to look good!  Add the projection plane half way\r
between the origin and the house at @math{z=-5}.  We'll try\r
the angle argument feature of @code{special} to position a label.\r
@verbatim\r
  def p 5 % projection distance (plane at z=-p)\r
  def projection_plane {\r
    def sz 1.5\r
    polygon (-sz,-sz,-p)(sz,-sz,-p)(sz,sz,-p)(-sz,sz,-p)\r
    special |\rput[b]#1-2#3{\footnotesize\sf projection plane}| \r
      (-sz,-sz,-p)(sz,-sz,-p)(0,-sz+.1,-p)\r
  }\r
@end verbatim\r
@noindent\r
Add @verb{|{projection_plane}|} to the list of objects in the\r
@code{put} above.\r
\r
@center @image{ex160}\r
\r
@indent\r
The way we constructed the points of the house now makes it easy to\r
draw rays of projection.  We'll cast one ray from every visible vertex\r
of the house and define options so the appearance of\r
all rays can be changed at the same time.\r
@verbatim\r
  def projection_rays {\r
    def rayopt [linewidth=.3pt,linecolor=lightgray]\r
    line [rayopt](O)(pR1) line [rayopt](O)(pR2) line[rayopt](O)(pR3)\r
    line [rayopt](O)(pR4) line [rayopt](O)(pR5)\r
    line [rayopt](O)(pL1) line [rayopt](O)(pL2) line[rayopt](O)(pL5)\r
    line [rayopt](O)(pD1) line [rayopt](O)(pD2) \r
    line [rayopt](O)(pD3) line [rayopt](O)(pD4) \r
  }\r
@end verbatim\r
@noindent\r
The result is shown here.  \r
\r
@center @image{ex170}\r
\r
@noindent\r
The rays pierce the projection plane at the corresponding points on\r
the perspective image we are trying to draw.  Albrecht D@"urer and his\r
Renaissance contemporaries had the same idea in the early 1500's.\r
\r
@center @image{duerer,,1.5in}\r
\r
All that's left is to find a way to connect the points of the house\r
on the projection plane.  We could pull out a good computer graphics\r
text, find the necessary matrix, and enter it ourselves as a\r
transform literal.  @xref{Transform literals}. That work is\r
already done, however.  We can use the @code{project(p)} constructor.\r
\r
There are still some details that require care.  Projection will\r
flatten whatever is transformed onto the plane @math{z=-p}.  Therefore\r
any part of the house could disappear behind the projection plane (the\r
hidden surface algorithm orders objects at the same depth\r
arbitrarily).  The door may also disappear behind the front of the\r
house.  To make sure everything remains visible, we'll place the house\r
a tiny bit in front of the projection plane and a second copy of the\r
door in front of the house.\r
@verbatim\r
  def projection {\r
    % e is a small number defined above\r
    put { project(p) then translate([0,0,1*e]) } {house}\r
    put { project(p) then translate([0,0,2*e]) } {door}\r
  }\r
@end verbatim\r
\r
@center @image{ex180}\r
\r
If you have studied and understand all this, you are well on the way\r
to success with @code{sketch}.  Not shown are the 20 or so iterations\r
that were required to find a reasonable viewing angle and house\r
position, etc.  Nonetheless, this drawing was completed in about an\r
hour.  While a GUI tool may have been a little faster, it is unlikely\r
that a new drawing, itself a perspective projection of the scene,\r
could be generated with two more minutes' work!  Just change the view\r
transform to\r
@verbatim\r
  put { view((eye), (look_at)) then perspective(9) } { ...\r
@end verbatim\r
@noindent \r
and produce this.\r
\r
@center @image{ex190}\r
\r
@node  A technical drawing, A hierarchical model, Overview, Building a drawing\r
@comment  node-name,  next,  previous,  up\r
@section A technical drawing\r
Let's look at a drawing that represents the kind of problem\r
@code{sketch} was meant to solve---a pair of textbook figures\r
regarding a polygonal approximation of a truncated cone.  Here are the\r
pictures we will produce.\r
\r
@center @image{ex250}@ @ @ @ @ @image{ex260}\r
\r
The cone shape is just a swept line with no closure tag and culling\r
turned off.  Begin by setting up some useful constants.\r
@sxindex def\r
@sxindex rotate\r
@verbatim\r
  def O (0,0,0) def I [1,0,0] def J [0,1,0] def K [0,0,1]\r
  def p0 (1,2) def p1 (1.5,0) def N 8\r
  def seg_rot rotate(360 / N, [J])\r
@end verbatim\r
@noindent\r
The points @code{p0} and @code{p1} are the end points of the line to\r
be swept.  The definition @code{seg_rot} is the sweep transformation.\r
With these, the cone itself is simple.\r
@sxindex sweep\r
@opindex cull\r
@sxindex line\r
@cindex swept line\r
@cindex line sweep\r
@verbatim\r
  sweep[cull=false] { N, [[seg_rot]] } line(p0)(p1)\r
@end verbatim\r
\r
The axes are next and include an interesing trick that shows the\r
hidden parts as dotted lines.  The secret is draw the axes\r
twice---solid lines with the normal\r
@cindex hidden surface algorithm\r
hidden surface algorithm in effect, and then dotted with the\r
option\r
@opindex lay\r
@code{lay=over} so that no polygons can hide them.\r
@sxindex def\r
@sxindex line\r
@opindex arrows\r
@opindex linewidth\r
@opindex lay\r
@opindex linestyle\r
@sxindex special\r
@verbatim\r
  def ax (dx,0,0) % tips of the axes\r
  def ay (0,dy,0)\r
  def az (0,0,dz)\r
  line[arrows=<->,linewidth=.4pt](ax)(O)(ay)\r
  line[arrows=->,linewidth=.4pt](O)(az)\r
  % repeat dotted as an overlay to hint at the hidden lines\r
  line[lay=over,linestyle=dotted,linewidth=.4pt](ax)(O)(ay)\r
  line[lay=over,linestyle=dotted,linewidth=.4pt](O)(az)\r
  special|\footnotesize\r
          \uput[d]#1{$x$}\uput[u]#2{$y$}\uput[l]#3{$z$}|\r
    (ax)(ay)(az)\r
@end verbatim\r
@noindent\r
The labels are applied with @code{PSTricks} special objects \r
@cindex special objects\r
as usual.\r
\r
For the height dimension mark, the power of affine \r
@cindex affine arithmetic\r
arithetic is very helpful.\r
@sxindex def\r
@sxindex unit\r
@sxindex scale\r
@sxindex line\r
@sxindex special\r
@verbatim\r
  def hdim_ref unit((p1) - (O)) then [[seg_rot]]^2\r
  def c0 (p0) then scale([J])\r
  def h00 (c0) + 1.1 * [hdim_ref]\r
  def h01 (c0) + 1.9 * [hdim_ref]\r
  def h02 (c0) + 1.8 * [hdim_ref]\r
  line(h00)(h01)\r
  def h10 (O) + 1.6 * [hdim_ref]\r
  def h11 (O) + 1.9 * [hdim_ref]\r
  def h12 (O) + 1.8 * [hdim_ref]\r
  line(h10)(h11)\r
  line[arrows=<->](h02)(h12)\r
  def hm2 ((h02) - (O) + (h12) - (O)) / 2 + (O)\r
  special|\footnotesize\rput*#1{$h$}|(hm2)\r
@end verbatim\r
The general idea employed here is to compute a unit ``reference\r
vector'' parallel to the @math{xz}-plane in the desired direction of\r
the dimension from the origin.  The transformation\r
@code{[[seg_rot]]^2} rotates two segments about the @math{y}-axis.\r
When applied to @code{(p1) - (O)}, the resulting vector points to the\r
right as shown.  In this manner, we can pick any vertex as the\r
location of the height dimension lines by varying the exponent of\r
@code{[[seg_rot]]}.  This is only one of many possible strategies.\r
\r
The computation of @code{hm2} is a useful idiom for finding the\r
@cindex centroid\r
centroid of a set of points.\r
\r
The two radius marks are done similarly, so we present the code\r
without comment.\r
@sxindex def\r
@sxindex line\r
@sxindex special\r
@sxindex scale\r
@opindex arrows\r
@verbatim\r
  % radius measurement marks\r
  def gap [0,.2,0]  % used to create small vertical gaps\r
\r
  % first r1\r
  def up1 [0,3.1,0] % tick rises above dimension a little\r
  def r1 ((p1) then [[seg_rot]]^-2) + [up1]\r
  def r1c (r1) then scale([J])\r
  def r1t (r1) + [gap]\r
  def r1b ((r1t) then scale([1,0,1])) + [gap]\r
  line[arrows=<->](r1c)(r1)  % dimension line\r
  line(r1b)(r1t)             % tick\r
  def r1m ((r1) - (O) + (r1c) - (O)) / 2 + (O) % label position\r
  special |\footnotesize\rput*#1{$r_1$}|(r1m)  % label\r
\r
  % same drill for r0, but must project down first\r
  def up0 [0,2.7,0]\r
  def r0 ((p0) then scale([1,0,1]) then [[seg_rot]]^-2) + [up0]\r
  def r0c (r0) then scale([J])\r
  def r0t (r0) + [gap]\r
  def r0b ((p0) then [[seg_rot]]^-2) + [gap]\r
  line[arrows=<->](r0c)(r0)\r
  line(r0b)(r0t)\r
  def r0m ((r0) - (O) + (r0c) - (O)) / 2 + (O)\r
  special |\footnotesize\rput*#1{$r_0$}|(r0m)\r
@end verbatim\r
\r
The second drawing uses the same techniques.  Only the method for\r
drawing the elliptical arc is new.  Here is the code.\r
@sxindex def\r
@sxindex special\r
@opindex lay\r
@verbatim\r
  def mid ((p00)-(O)+(p10)-(O)+(p11)-(O)+(p01)-(O))/4+(O)\r
  special|\rput#1{\pscustom{\r
    \scale{1 1.3}\r
    \psarc[arrowlength=.5]{->}{.25}{-60}{240}}}|\r
    [lay=over](mid)\r
@end verbatim\r
@noindent\r
We could have swept a point to make the arc with @code{sketch}, but\r
using a @code{PSTricks} custom graphic was simpler.  Again we computed\r
the \r
@cindex centroid\r
centroid of the quadrilateral by averaging points.  Note that scaling\r
in Postscript distorts the arrowhead, but in this case the distortion\r
actually looks better in the projection of the slanted face.  A\r
@code{sketch} arrowhead would not have been distorted.\r
\r
The complete code for this example, which draws either figure\r
depending on the definition of the tag @code{<labeled>}, is included\r
in the @code{sketch} distribution in the file @file{truncatedcone.sk}.\r
\r
@node A hierarchical model, Caveats, A technical drawing, Building a drawing\r
@comment  node-name,  next,  previous,  up\r
@section A hierarchical model\r
@cindex hierarchical model\r
While @code{sketch} was never meant to be a geometric modeling\r
language, it comes fairly close.  The following example puts all we\r
have seen to work in a very simple model of the human hand.  Start by\r
sweeping a line to make a truncated cone, which will be copied over\r
and over again to make the segments of fingers.\r
@sxindex def\r
@sxindex sweep\r
@sxindex rotate\r
@sxindex line\r
@verbatim\r
  def O (0,0,0) % origin\r
  def I [1,0,0] def J [0,1,0] def K [0,0,1] % canonical unit vectors\r
  def segment {\r
    def n_faces 8\r
    sweep { n_faces<>, rotate(360 / n_faces, [J]) } \r
      line(proximal_rad, 0)(distal_rad, distal_len)\r
  }\r
@end verbatim\r
@noindent\r
In hand anatomy, @emph{distal} is ``at the tip'' and @emph{proximal}\r
is ``in the area of the palm.''  We have omitted all the scalar\r
constants.  You can find them in @file{hand.sk}, which is provided\r
in the @code{sketch} distribution. \r
\r
We also need a prototypical sphere to use for the joints themselves.\r
@sxindex def\r
@sxindex sweep\r
@sxindex rotate\r
@verbatim\r
  def joint_sphere {\r
    def n_joint_faces 8\r
    sweep [fillcolor=red] { n_joint_faces, rotate(360 / n_joint_faces, [J]) }\r
      sweep { n_joint_faces, rotate(180 / n_joint_faces) } \r
        (0, -joint_rad)\r
  }\r
@end verbatim\r
\r
We'll now design the index finger (number@w{ }1 in our notational\r
convention; finger@w{ }0 is the thumb).  The distal rotation for the\r
finger applies only to the tip, so we define the following.\r
@sxindex def\r
@sxindex put\r
@sxindex translate\r
@sxindex rotate\r
@sxindex scale\r
@verbatim\r
  def distal_1 {\r
    put { translate(joint_gap * joint_rad * [J]) \r
          then rotate(distal_1_rot, [I]) \r
          then translate((distal_len + joint_gap * joint_rad) * [J]) }\r
      {segment}\r
    put { rotate(distal_1_rot / 2, [I])\r
          then translate((distal_len + joint_gap * joint_rad) * [J]) } \r
      {joint_sphere}\r
    put { scale( [J] + proximal_distal_ratio * ([I]+[K]) ) }\r
      {segment}\r
  }  \r
@end verbatim\r
@noindent\r
The identifiers here are for size and location constants. The\r
exception is @code{distal_rot_1}.  This rotation parameter models the\r
flexing of the finger tip.  The first @code{put} makes a copy of the\r
finger segment that is translated upward \r
@cindex translation transform\r
@cindex transform, translation\r
just far enough to make room\r
for the spherical joint.  Then it applies the distal rotation.\r
@cindex rotation transform\r
@cindex transform, rotation\r
Finally it translates the whole assembly upward again to make room for\r
the middle phlanges (the next bone toward the palm).  The second\r
@code{put} positions the sphere.  There is a rotation to place the\r
grid on the sphere surface at an nice angle, then a translation to the\r
base of the distal phlanges, which is also center of its rotation.\r
Finally, the last @code{put} positions the middle segment itself.\r
\r
The middle joint is the next one down, with rotation angle\r
@code{middle_rot_1}.  When this angle changes, we need all the objects\r
in @code{distal_1} to rotate as a unit.  \r
@cindex rotation transform\r
@cindex transform, rotation\r
This is the reasoning behind\r
the next definition.\r
@verbatim\r
  def finger_1 {\r
    put { translate(joint_gap * joint_rad * [J])\r
          then rotate(middle_1_rot, [I])\r
          then translate((middle_ratio * distal_len + \r
                          joint_gap * joint_rad) * [J]) }\r
      {distal_1}\r
    put { scale(proximal_distal_ratio)\r
          then rotate(middle_1_rot / 2, [I])\r
          then translate((middle_ratio * distal_len + \r
                          joint_gap * joint_rad) * [J]) } \r
      {joint_sphere}\r
    put { scale( middle_ratio * [J] + \r
                 proximal_distal_ratio^2 * ([I]+[K]) ) }\r
      {segment}\r
  }\r
@end verbatim\r
@noindent\r
This looks very similar to the previous definition, and it is.  The\r
important difference is that rather than positioning and rotating a\r
single segment, we position and rotate the entire ``assembly'' defined\r
as @code{distal_1}.  \r
@cindex rotation transform\r
@cindex transform, rotation\r
The rest is just arithmetic to compute sizes and\r
positions that look nice.  The last @code{put} places an appropriately\r
shaped segment that is the @emph{proximal phlanges}, the bone that\r
joins the palm of the hand.  This completes the finger itself.\r
\r
All the other fingers are described identically to this one.  We\r
account for the fact that real fingers are different sizes in the next\r
step, which is to build the entire hand.\r
\r
The @code{hand} definition that follows includes a section for each\r
finger.  We'll continue with finger@w{ }1 and omit all the others.\r
(Of note is that the thumb needs slightly special treatment---an extra\r
rotation to account for its opposing angle. This is clear in the full\r
source code.) Not surprisingly, the @code{hand} definition looks very\r
much like the previous two.  It should be no surprise that when the\r
rotation parameter @code{meta_1_rot} changes, the entire finger\r
rotates!\r
@cindex rotation transform\r
@cindex transform, rotation\r
There is an additional rotation that allows the fingers to spread\r
laterally.  We say these joints of the proximal phlanges have two\r
@emph{degrees of freedom}. The joints higher on the finger have only\r
one. Finally, each finger is scaled by a factor to lend it proportion.\r
@verbatim\r
  def hand {\r
    % finger 1 [all other fingers omitted]\r
    def scale_1 .85\r
    put { scale(scale_1) \r
          then translate((joint_gap * joint_rad) * [J])\r
          then rotate(meta_1_rot, [I])\r
          then rotate(-spread_rot, [K])\r
          then translate((proximal_1_loc) - (O)) } \r
      {finger_1}\r
    put { scale(scale_1 * proximal_distal_ratio^2)\r
          then rotate(meta_1_rot / 2, [I])\r
          then rotate(-spread_rot, [K])\r
          then translate((proximal_1_loc) - (O)) } \r
      {joint_sphere}\r
\r
    % palm\r
    sweep { 1, rotate(6, (0,15,0), [I]) }\r
      put { rotate(-3, (0,15,0), [I]) } {\r
        polygon(proximal_1_loc)(proximal_2_loc)\r
               (proximal_3_loc)(proximal_4_loc)\r
               (h5)(h6)(h6a)(h9)(h10)\r
        polygon(h6a)(h7)(h8)(h9)\r
   }  }\r
@end verbatim\r
@noindent\r
The last section of the definition creates the polytope for the palm\r
of the hand by @code{sweep}ing \r
@cindex swept polygon\r
@cindex polygon sweep\r
a 10-sided polygon through a very short\r
arc (9@w{ }degrees).  This provides a wedge-shaped profile when viewed\r
from the side. The thick end of the wedge is the wrist.  Because the\r
polygon is concave, it is split into into two convex shapes with nine\r
and four vertices.\r
\r
We can now have fun positioning the hand by adjusting the various\r
rotation angles.  The complete source includes definitions with\r
alternatives that include the following views and more.\r
\r
@center @image{ex210}@image{ex220}@image{ex230}@image{ex240}\r
\r
@node Caveats,  , A hierarchical model, Building a drawing\r
@comment  node-name,  next,  previous,  up\r
@section Caveats\r
@code{Sketch} is a fairly powerful tool for drawing, but, just as with\r
@TeX{}, the power to create beautiful results comes along with the\r
power to make mistakes.  The following are some points where care is\r
necessary and where the current version of @code{sketch} is limited or\r
has known bugs.\r
\r
@menu\r
* Limits on error detection::   What sketch doesn't do.\r
* Clipping::                    No clipping at present.\r
* Hidden surface removal::      Imperfections to fix.\r
@end menu\r
\r
@node Limits on error detection, Clipping, Caveats, Caveats\r
@comment  node-name,  next,  previous,  up\r
@subsection Limits on @code{sketch} error detection\r
\r
@code{Sketch} catches many kinds of errors, but not all. For example,\r
options that sketch does not recognize, even incorrect ones, are\r
quietly copied to @code{PSTricks} commands in the output.  It is also\r
unfortunately easy to produce @code{sketch} inputs that lead to no\r
picture at all (improper vertex ordering causes everything to be\r
culled), to pictures that are too big or too small for @code{PSTricks}\r
to draw (due to limits of @TeX{} math), and pictures that look nothing\r
like what was intended.  A picture with one of these problems can be\r
difficult to ``debug.''  We offer the following suggestions.\r
@itemize\r
@item \r
Follow the suggested incremental development method described in\r
@ref{Overview}. \r
@item\r
Always maintain one or two back-versions of a drawing so that it is\r
easy to fall back to a known-good increment.\r
@item\r
When using @code{perspective}, ensure all finally transformed objects\r
satisfy @math{z<0} and, in fact, do not come very close to the origin\r
at all.\r
@item\r
Temporarily use @code{cull=false} to see where vertex ordering\r
problems lie.\r
@item\r
Use temporary changes of color of one or more objects to ensure that\r
your understanding of the scene geometry is correct.\r
@item\r
If @code{PSTricks} complains about something, inspect the output\r
directly for clues.\r
@end itemize\r
\r
@node Clipping, Hidden surface removal, Limits on error detection, Caveats\r
@comment  node-name,  next,  previous,  up\r
@subsection Clipping\r
The current version of @code{sketch} has no clipping \r
@cindex clipping\r
operations.  The entire scene is always drawn.  This means that when a\r
perspective transform is employed, it is the user's responsibility to\r
make sure the entire scene remains in front of the viewer, the region\r
@math{z<0}.\r
\r
@node Hidden surface removal,  , Clipping, Caveats\r
@comment  node-name,  next,  previous,  up\r
@subsection Hidden surface removal and polygon splitting\r
@code{Sketch} uses the @dfn{depth sort algorithm} \r
@cindex depth sort\r
@cindex hidden surface algorithm\r
for hidden surface removal.  This is a very old technique due to\r
Newell.@footnote{Newell, M.E., R.G.@: Newell, and T.L.@: Sancha, A\r
solution to the hidden surface problem. @i{Proceedings of the ACM\r
annual conference - Volume 1}, page 443--450, ACM Press, 1972.}  It is\r
generally regarded as too slow for real time graphics, but it is\r
ideal for our purpose where speed is not very important.@footnote{We\r
have run @code{sketch} on the famous Stanford Bunny, which consists\r
of nearly @math{70,000} triangles.  Run time was about 6 seconds.\r
Most of this was spent writing the output file rather than in the\r
hidden surface algorithm.  @LaTeX{} took much longer to process the\r
resulting @code{PSTricks} code.  The obvious conclusion is that the\r
speed of the depth sort algorithm is not a worry.}\r
\r
The depth sort algorithm merely sorts objects on a key of increasing\r
@math{z}-coordinate, equivalent to decreasing depth.  Objects are then\r
drawn in the sorted sequence so that those at the rear of the scene\r
are overwritten by those closer to the viewer. Since this is also\r
how oil painters practice their art, depth sort is sometimes called\r
``the painter's algorithm.''\r
\r
In some cases it is impossible to strictly order polygons according to\r
depth.  Moreover, even if a correct depth ordering exists, the\r
computation needed to find it may be too complex and slow.  In these\r
cases, @code{sketch} splits \r
@cindex splitting, line and surface\r
one or more polygons into pieces.  The\r
expectation is that the new, smaller polygons will be simpler to\r
order.  @code{Sketch} uses a @acronym{BSP,binary space partition} \r
@cindex binary space partition\r
@cindex BSP, binary space partition\r
to handle the splitting operation.\r
\r
@menu\r
* Statistics::                  Performance numbers on depth sort.\r
* Bugs and anomalies::          Imperfections in this implementation.\r
@end menu\r
\r
@node Statistics, Bugs and anomalies, Hidden surface removal, Hidden surface removal\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Statistics\r
For the curious, @code{sketch} writes one line of depth sort\r
statistics.  Here is an example for a large collection of triangles.\r
@verbatim\r
  remark, node=34824 probe=581.9 swap=5 split=2 (in=4 out=6) ols=24851/0\r
@end verbatim\r
@noindent\r
It means that @math{34,824} objects were depth sorted after culling.\r
For each, an average of @math{581.9} others had to be checked to\r
ensure that the initial, approximate ordering was correct.  Among all\r
these checks, only @math{5} resulted in swaps to reorder the initial\r
sort.  In two cases, a correct ordering could not be determined, so\r
binary space partitions\r
@cindex binary space partition\r
were constructed for splitting.  A total of @math{4}\r
objects (triangles in this case) were inserted in the partitions, and\r
@math{6} polygons were produced.  Finally, @math{24,851} ``last\r
resort'' polygon overlap checks were performed after simpler, faster\r
checks failed to yield conclusive results.  The final @math{/0} is for\r
line-polygon overlap checks.  For comparison, the statistics for the\r
last figure in @ref{Overview} follow.\r
@verbatim\r
  remark, node=27 probe=14.6 swap=36 split=15 (in=30 out=45) ols=0/69\r
@end verbatim\r
@noindent\r
Note that there was proportionally much more swapping and splitting\r
activity in this highly connected scene.\r
\r
@node Bugs and anomalies,  , Statistics, Hidden surface removal\r
@comment  node-name,  next,  previous,  up\r
@subsubsection Bugs and anomalies\r
Polygon and line splitting can both cause anomalies in the output.  \r
@code{PSTricks} dash patterns, specified with @code{linestyle=dashed},\r
@opindex linestyle\r
can be disrupted by splitting.  This occurs when the depth sort\r
@cindex depth sort\r
gives up too early and splits a line where it is not really\r
necessary. \r
A workaround is to use gray or finely dotted\r
lines instead.  If your drawing is small, you can also edit the\r
@code{sketch} output by hand to merge the pieces of the offending\r
line.\r
\r
Another anomaly is tiny (or in degenerate cases not-so-tiny) notches\r
in the lines that border split polygons.  These derive from the way\r
each polygon is painted: first, all pixels within the boundary are\r
@dfn{filled} with color (perhaps white), then the same boundary is\r
@dfn{stroked} (a Postscript term) with a line.  The result is that\r
half the line lies inside the boundary and half outside, while the\r
Painter's algorithm assumes the polygon lies entirely within its\r
boundary.  The notches are due to one polygon fill operation\r
overwriting the already-drawn inside of the border of another\r
polygon.@footnote{I know how to fix this problem, but I don't like my\r
solution, and I'm interested in yours.}  One workaround is to make\r
border lines very thin.  In fact @code{linewidth=0pt} is guaranteed to\r
eliminate this problem, though this results in the thinnest line your\r
output device can draw, which is usually too thin.  You might get\r
lucky by merely reordering things in the input file, which is likely\r
to move the splits to different places.  The only sure-fire solution\r
is pretty terrible: custom fit @code{special} overlay lines (with\r
@code{\psline}) to cover the notches.\r
\r
Polygon splitting also breaks @code{PSTricks} hatch patterns.  The\r
only known workaround is to substitute a solid fill for the hatch.\r
\r
@node Command line, Installing sketch, Building a drawing, Top\r
@comment  node-name,  next,  previous,  up\r
@chapter Command line\r
@cindex command line, @code{sketch}\r
@strong{Synopsis:}\r
@example\r
sketch [-h][-V x.y][-v][-b][-d][t doctmp][-T[u|e][p[P|T][L|C]]][-o output.tex]\r
  [-D @var{tag} @dots{}] input1.sk [-U @var{tag} @dots{}] input2.sk @dots{}\r
@end example\r
\r
@noindent\r
@strong{Description}\r
Processes the @code{sketch} input files in order to produce\r
@code{PSTricks} output code suitable for inclusion in a @TeX{} or\r
@LaTeX{} document.\r
\r
@noindent\r
@strong{Options:}\r
@cindex options, command line\r
@cindex command line options\r
@table @code\r
@item -h\r
Print a short catalog of options.\r
@item -V\r
Set the @code{PSTricks} version assumed for output purposes to\r
@code{x.y}, for example 1.19.  Usually needed only if your\r
@code{PSTricks} is old compared to your @code{sketch}.  Use\r
@code{-v} to see what @code{sketch} assumes by default.\r
@item -v\r
Print version information to standard output, including the version\r
of @code{PSTricks} assumed for output (can be changed with @code{-V} above).\r
@item -b\r
Use a BSP \r
@cindex binary space partition\r
@cindex BSP, binary space partition\r
(@xref{Hidden surface removal}.) for\r
@emph{all} hidden surface removal rather than the default, which is\r
the depth sort algorithm with BSPs used only for cycle resolution.\r
This may produce correct output in certain degenerate cases where the\r
depth sort cannot, but it also leads to many gratuitous splits, hence\r
more anomalies @ref{Bugs and anomalies} and big output files.\r
@item -d\r
Run @code{sketch}'s parser in debugging mode.  This is primarily for\r
development.\r
@item -t\r
Use contents of file @file{doctmp} as a document template \r
@cindex document template\r
@cindex template, document\r
in which to enclose @code{PSTricks} output code.  The code is inserted\r
in place of the first instance of the escape string\r
@verb{|%%SKETCH_OUTPUT%%|}.  \r
@item -T\r
Causes @code{PSTricks} output to be enclosed in default US document\r
template text.  Option @option{-Tu} is a synonym.  Option @option{-Te}\r
causes the Euro standard document template to be used.  A @option{p}\r
appended to any of these options causes the respective default\r
@code{PSTricks} document template to be printed to standard output. An\r
appended @option{P} is a synonym.  An appended @option{T} causes the\r
the @code{TikZ/PGF} template to be printed.  An appended @option{L}\r
prints the @LaTeX{} version of the document template, a synonym for\r
the default.  A @option{C} prints the @code{ConTeXt} template.\r
@item -o\r
Use @file{output.tex} as the output file.  The default is standard output.\r
@item -D\r
Define a tag \r
@cindex tag definition\r
@cindex definition, tag\r
for purposes of selecting definition alternatives.\r
@xref{Definitions}.  The definition applies for all input files that\r
follow unless the tag is undefined with @option{-U}.\r
@item input@math{i}.sk\r
Input files, read in the sequence they are given.\r
@item -U\r
Un-define a tag for purposes of selecting definition alternatives.\r
@end table\r
\r
@node Installing sketch, Index of syntax, Command line, Top\r
@comment  node-name,  next,  previous,  up\r
@chapter Building and installing @code{sketch}\r
@code{Sketch} is so small that compiling by brute force is probably\r
best.  The following command ought to do the trick on any\r
systems where @code{gcc} is installed.  Make sure to first change\r
current directories to the place where you have unpacked the sources.\r
@example\r
gcc *.c -o sketch.exe -lm\r
@end example\r
@noindent\r
The @samp{.exe} at the end is necessary for Windows systems.  Drop it\r
if your system is some version of Unix.  Other C compilers ought\r
to work as just as well.  For example,\r
@example\r
cl *.c -o sketch.exe\r
@end example\r
@noindent\r
is the correct command for many versions of MS Visual C.  In the\r
latest versions, Microsoft has deprecated the @code{-o} option and, by\r
default, does not define the @code{__STDC__} macro.  This causes\r
problems with some versions of @code{flex}, @code{bison}, @code{lex},\r
and @code{yacc}, which are used to create the @code{sketch} scanner\r
and parser.  It's nearly always possible to find a set of options that\r
compiles with no errors or warnings, and this means @code{sketch} is\r
@emph{very} likely to work correctly.  For example, the Visual C++\r
2005 Express Edition compiler (available free of charge from the\r
Microsoft web site), @code{flex} version 2.5.4, and @code{bison}\r
version 2.1 build error-free with\r
@example\r
cl -DYY_NEVER_INTERACTIVE=1 -Za -Ox -Fesketch.exe *.c\r
@end example\r
\r
For purists, there is also a @code{makefile} compatible with GNU\r
@code{make} and @code{gcc}. The command\r
@example\r
make\r
@end example\r
@noindent\r
will build the executable, including the rebuilding of the scanner and\r
parser with @code{flex} and @code{bison} if you have changed\r
@file{sketch.l} or @code{sketch.y} respectively.  \r
\r
To build this document in all its myriad forms (assuming you have the\r
necessary conversion programs on your system), use\r
@example\r
make docs\r
@end example\r
@noindent\r
The possibilities are listed in this following table.\r
@multitable {@code{manual/index.html}}{texi2dvi,dvips}{@b{Pictures}}{wide column that needs to be as big as it needs to be,}\r
@headitem Format @tab Converter @tab Pictures @tab Description\r
@item manual.info \r
  @tab makeinfo       @tab @file{.txt} @tab @acronym{GNU} Info.\r
@item manual.dvi\r
  @tab texi2dvi       @tab @file{.eps} @tab @TeX{} typeset output.\r
@item manual.ps   \r
  @tab texi2dvi,dvips @tab @file{.eps} @tab Postscript.\r
@item manual.pdf\r
  @tab texi2dvi       @tab @file{.pdf} @tab Adobe PDF.\r
@item manual.html \r
  @tab makeinfo       @tab @file{.png} @tab A single web page.\r
@item manual/index.html\r
  @tab makeinfo       @tab @file{.png} @tab Linked web pages, one per node.\r
@end multitable\r
An additional open source program @code{epstool} is needed to refine the\r
Encapsulated Postscript bounding boxes of @code{sketch}-generated\r
figures.  \r
\r
@node Index of syntax, Index, Installing sketch, Top\r
@comment  node-name,  next,  previous,  up\r
@unnumbered Index of syntax\r
\r
@printindex sx\r
\r
@node Index,  , Index of syntax, Top\r
@comment  node-name,  next,  previous,  up\r
@unnumbered Index of concepts\r
\r
@printindex cp\r
\r
@bye\r