This is 3DLDF.info, produced by makeinfo version 4.5 from 3DLDF.texi.

This is the 3DLDF User and Reference Manual, edition 1.1.5 for 3DLDF
1.1.5.  This manual was last updated on 14 January 2004.  3DLDF is a
GNU package for three-dimensional drawing with MetaPost output.  The
author is Laurence D. Finston.

   Copyright (C) 2003, 2004 Laurence D. Finston.

     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.2 or any later version published by the Free Software
     Foundation; with no Invariant Sections, no Front-Cover Texts, and
     no Back-Cover Texts.  A copy of the license is included in the
     section entitled "GNU Free Documentation License".
   
INFO-DIR-SECTION GNU packages
START-INFO-DIR-ENTRY
* 3DLDF: (3DLDF).            3D drawing with MetaPost output.
END-INFO-DIR-ENTRY


File: 3DLDF.info,  Node: Icosahedron Net,  Prev: Icosahedron Constructors and Setting Functions,  Up: Icosahedron

Net
...

 - Static function: vector<Reg_Polygon*> get_net (const real
          TRIANGLE_DIAMETER, [bool DO_HALF = `false'])
     Returns the "net", i.e., the two-dimensional pattern of triangles
     that can be folded into a model of an icosahedron.  The net lies
     in the x-z plane.  The triangles have enclosing circles of diameter
     TRIANGLE_DIAMETER.  If the argument DO_HALF = `true', only the
     first half of the net is created.  This is used in the non-default
     constructor.  *Note Polyhedron Reference; Regular Platonic
     Polyhedra; Icosahedron; Constructors and Setting Functions:
     Icosahedron Constructors and Setting Functions.

          vector<Reg_Polygon*> vrp = Icosahedron::get_net(1.5);
          for (vector<Reg_Polygon*>::iterator iter = vrp.begin();
               iter != vrp.end(); ++iter)
             (**iter).draw();

     [Figure 197 not displayed.]


 - Static function: void draw_net (const real TRIANGLE_DIAMETER, [bool
          PORTRAIT = TRUE, [bool MAKE_TABS = `true']])
     Draws the net for an `Icosahedron' in the x-z plane.  The triangles
     have enclosing circles of diameter TRIANGLE_DIAMETER.  If the
     argument PORTRAIT is `true' (the default), the net will be
     arranged for printing in portrait format.  If it's `false', it
     will be arranged for printing in landscape format.  In portrait
     format, the center of the bottom right triangle is at the origin.
     In landscape format, the center of the bottom left triangle is at
     the origin.  The triangles are numbered.

     The argument MAKE_TABS currently has no effect.  When I get around
     to programming this, it will be used for specifying whether tabs
     for gluing and/or sewing a cardboard model should be drawn, too.

          Icosahedron::draw_net(2, false);

     [Figure 198 not displayed.]



File: 3DLDF.info,  Node: Semi-Regular Archimedean Polyhedra,  Prev: Regular Platonic Polyhedra,  Up: Polyhedron Reference

Semi-Regular Archimedean Polyhedra
==================================

   Once I've added `class Octahedron', the only Platonic polyhedron I
haven't programmed yet, I plan to start adding classes for the
semi-regular Archimedean polyhedra.

* Menu:

* Truncated Octahedron::


File: 3DLDF.info,  Node: Truncated Octahedron,  Prev: Semi-Regular Archimedean Polyhedra,  Up: Semi-Regular Archimedean Polyhedra

Truncated Octahedron
--------------------

   Class `Trunc_Octahedron' is defined in `polyhed.web'.  It is derived
from `Polyhedron' using public derivation.

   `Trunc_Octahedron' does not yet have a functioning constructor, so
it cannot be used as yet.

* Menu:

* Truncated Octahedron Data Members::
* Truncated Octahedron Constructors and Setting Functions::
* Truncated Octahedron Net::


File: 3DLDF.info,  Node: Truncated Octahedron Data Members,  Next: Truncated Octahedron Constructors and Setting Functions,  Prev: Truncated Octahedron,  Up: Truncated Octahedron

Data Members
............

 - Protected static `const' variable: real angle_hex_square
     The angle between the hexagonal and the square faces of the
     truncated octahedron, namely 125 degrees  16' .

 - Protected static `const' variable: real angle_hex_hex
     The angle between the hexagonal faces of the truncated octahedron,
     namely 109 degrees  28' .

 - Protected variable: real hexagon_radius
     The radius of the circle enclosing a hexagonal or square face of
     the `Trunc_Octahedron'.


File: 3DLDF.info,  Node: Truncated Octahedron Constructors and Setting Functions,  Next: Truncated Octahedron Net,  Prev: Truncated Octahedron Data Members,  Up: Truncated Octahedron

Constructors and Setting Functions
..................................

 - Default constructor: void Trunc_Octahedron (`void')
     Creates an empty `Trunc_Octahedron'.

 - Constructor: void Trunc_Octahedron (const Point& P, const real
          DIAMETER_OF_HEXAGON, [real ANGLE_X = 0, [real ANGLE_Y = 0,
          [real ANGLE_Z = 0]]])
     This function does not yet exist!  When it does, it will create a
     `Trunc_Octahedron' with its center at the origin, where the
     hexagonal and square faces have enclosing circles of diameter
     DIAMETER_OF_HEXAGON.  If any of ANGLE_X, ANGLE_Y, or ANGLE_Z is
     non-zero, the `Trunc_Octahedron' will be rotated by the amounts
     specified around the corresponding axes.  Finally, if P is not the
     origin, the `Trunc_Octahedron' will be shifted such that `center'
     comes to lie at P.


File: 3DLDF.info,  Node: Truncated Octahedron Net,  Prev: Truncated Octahedron Constructors and Setting Functions,  Up: Truncated Octahedron

Net
...

 - Static function: vector<Reg_Polygon*> get_net (const real
          HEXAGON_DIAMETER, [bool DO_HALF = `false'])
     This function does not yet exist!  When it does, it will return
     the "net", i.e., the two-dimensional pattern of hexagons and
     squares that can be folded into a model of a truncated octahedron.
     The net will lie in the x-z plane.  The hexagons and squares will
     have enclosing circles of diameter HEXAGON_DIAMETER.  If the
     argument DO_HALF is `true', only the first half of the net will be
     created.  This will be used in the non-default constructor.  *Note
     Polyhedron Reference; Regular Platonic Polyhedra; Truncated
     Octahedron Constructors and Setting Functions: Truncated
     Octahedron Constructors and Setting Functions.


File: 3DLDF.info,  Node: Utility Functions,  Next: Adding a File,  Prev: Polyhedron Reference,  Up: Top

Utility Functions
*****************

 - Function: double trunc (double d)
     Defined in `pspglb.web'.  For some reason, when I compile 3DLDF
     using GNU CC on a PC Pentium II XEON under Linux 2.4.4 i686, the
     standard library function `trunc()' is not available.  Therefore,
     I've had to write one.  This is a kludge!  Someday, I'll have to
     try to find a better solution to this problem.

 - Function: pair<real, real> solve_quadratic (real A, real B, real C)
     Defined in `pspglb.web'.  This function tries to find the
     solutions S_0 and S_1 to the quadratic equation ax^2 + bx + c
     according to the formulae S_0 == -b + sqrt(b^2 - 4ac) / 2a) and
     S_1 == -b - sqrt( b^2 - 4ac) / 2a.  Let `r' stand for the return
     value.  If S_0 cannot be found, `r.first' will be `INVALID_REAL',
     otherwise S_0.  If S_1 cannot be found, `r.second' will be
     `INVALID_REAL', otherwise S_1.

          (x + 4)(x + 2) = x^2 + 6x + 8 = 0

          real_pair r = solve_quadratic(1, 6, 8);
          => r.first == -2
          => r.second == -4

          real_pair r = solve_quadratic(1, -2, 4);
          => r.first == INVALID_REAL
          => r.second == INVALID_REAL


* Menu:

* Perspective Functions::


File: 3DLDF.info,  Node: Perspective Functions,  Prev: Utility Functions,  Up: Utility Functions

Perspective Functions
=====================

 - Function: void persp_0 (const real FRONT_CORNER_X, const real
          FRONT_CORNER_Z, const real SIDE_LFT, const real SIDE_RT,
          const real ANGLE_RT, const real F_2_CV, const real GL_2_CV,
          [const real HORIZON_LFT = 6, [real HORIZON_RT = 0, [real
          GL_LFT = 0, [real GL_RT = 0]]]])
     Defined in `utility.web'.  This function is used for the figure in
     *Note The Perspective Projection::, illustrating a perspective
     projection as it could be done by hand.  It draws a rectangle in
     the ground plane and the construction lines used for putting it
     into perspective.  It also labels the vanishing and measuring
     points.

     The arguments:
    `CONST REAL' FRONT_CORNER_X
          The x-coordinate of the front corner of the rectangle.

    `CONST REAL' FRONT_CORNER_Z
          The z-coordinate of the front corner of the rectangle.

    `CONST REAL' SIDE_LFT
          The length of the left side of the rectangle.

    `CONST REAL' SIDE_RT
          The length of the right side of the rectangle.

    `CONST REAL' ANGLE_RT
          The angle at which the right side of the rectangle recedes to
          the horizon.

    `CONST REAL' F_2_CV
          The distance from the focus to the center of vision.

    `CONST REAL' GL_2_CV
          The distance of the ground line to the center of vision.

    `CONST REAL' HORIZON_LFT
          Default: 6.  The length of the horizon line leftwards of the
          center of vision.

    `REAL' HORIZON_RT
          Default: 0.  The length of the horizon line rightwards of the
          center of vision.

    `REAL' GL_LFT
          Default: 0.  The length of the ground line leftwards of the
          line from the focus to the center of vision.

    `REAL' GL_RT
          Default: 0.  The length of the ground line rightwards of the
          line from the focus to the center of vision.

     Example:

          persp_0(3, 2, 10, 5, 47.5, 7, 5, 8.5, 9.5, 8.5, 9.5);

     [Figure 199 not displayed.]



File: 3DLDF.info,  Node: Adding a File,  Next: Future Plans,  Prev: Utility Functions,  Up: Top

Adding a File
*************

   Version 1.1.1 was the first version of 3DLDF since it became a GNU
package (the current version is 1.1.5).  In previous versions,
recompilation was controlled by an auxilliary program, which I wrote in
C++  using CWEB.  However, in the course of making 3DLDF conformant to
the GNU Coding Standards(1), this has been changed.  Recompilation is
now controlled by `make', as is customary.  The chapter "Compiling" in
previous editions of this manual, is therefore no longer needed.

   Nonetheless, using CWEB still has consequences for the way
recompilation must be handled, and it was fairly tricky getting `make'
to work for 3DLDF.  Users who only put code in `main.web' and/or change
code in existing files won't have to worry about this; for others, this
chapter explains how to add files to 3DLDF.

   Let's say you want to add a file `widgets.web' that defines a `class
Widget', and that the latter needs access to `class Rectangle', and is
in turn required by `class Ellipse'.  Code must be added to
`3DLDF-1.1.5/CWEB/Makefile' for ctangling `widgets.web', compiling
`widgets.cxx', and linking `widgets.o' with the other object files to
make the executable `3dldf'.

   The best way to do this is to change `3DLDF-1.1.5/CWEB/Makefile.am'
and use Automake to generate a new `Makefile.in'.  Then, `configure'
can be used to generate a new `Makefile'.  It would be possible to
modify `Makefile' by hand, but I don't recommend it.  The following
assumes that the user has access to Automake.  If he or she is using a
GNU/Linux system, this is probably true.(2)

   `widgets.web' must be added between `rectangs.web' and
`ellipses.web' in the following variable declaration in
`3DLDF-1.1.5/CWEB/Makefile.am':

     3dldf_SOME_CWEBS = pspglb.web io.web colors.web transfor.web \
                        shapes.web pictures.web points.web \
                        lines.web planes.web paths.web curves.web \
                        polygons.web rectangs.web ellipses.web \
                        circles.web patterns.web solids.web
                        solfaced.web cuboid.web polyhed.web \
                        utility.web parser.web examples.web

   Now, add `widgets.o' between `ellipses.o' and `rectangs.o' in the
following variable declaration:

     3dldf_OBS_REVERSED = main.o examples.o parser.o utility.o \
                          polyhed.o cuboid.o  solfaced.o solids.o \
                          patterns.o circles.o ellipses.o rectangs.o \
                          polygons.o curves.o paths.o \
                          planes.o lines.o points.o pictures.o shapes.o
                          transfor.o colors.o io.o pspglb.o

   `3dldf_OBS_REVERSED' is needed, because 3DLDF fails with a
"Segmentation fault", if the executable is linked using
`$(3dldf_OBJECTS)'.  This may cause problems, if `3dldf' isn't built
using the GNU C++  compiler (GCC).

   Now add a target for `widgets.o' between the targets for
`rectangs.o' and `ellipses.o', and add `widgets.tim' after
`rectangs.tim' in the list of prerequisites for `ellipses.o':

     rectangs.o: loader.tim pspglb.tim io.tim colors.tim transfor.tim \
              shapes.tim pictures.tim points.tim lines.tim planes.tim \
              paths.tim curves.tim polygons.tim rectangs.cxx
     
     ellipses.o: loader.tim pspglb.tim io.tim colors.tim transfor.tim \
              shapes.tim pictures.tim points.tim lines.tim planes.tim \
              paths.tim curves.tim polygons.tim rectangs.tim ellipses.cxx

   This is the result:
     rectangs.o: loader.tim pspglb.tim io.tim colors.tim transfor.tim \
              shapes.tim pictures.tim points.tim lines.tim planes.tim \
              paths.tim curves.tim polygons.tim rectangs.cxx
     
     widgets.o: loader.tim pspglb.tim io.tim colors.tim transfor.tim \
              shapes.tim pictures.tim points.tim lines.tim planes.tim \
              paths.tim curves.tim polygons.tim rectangs.tim \
              widgets.cxx
     
     ellipses.o: loader.tim pspglb.tim io.tim colors.tim transfor.tim \
              shapes.tim pictures.tim points.tim lines.tim planes.tim \
              paths.tim curves.tim polygons.tim rectangs.tim widgets.tim \
              ellipses.cxx

   In addition, `widgets.tim' must be added to the list of
prerequisites in all of the following targets up to and including
`examples.o'.

   ---------- Footnotes ----------

   (1) The GNU Coding Standards are available at
`http://www.gnu.org/prep/standards_toc.html'.

   (2) Automake is available for downloading from
`http://ftp.gnu.org/gnu/automake/'.  The Automake website is at
`http://www.gnu.org/software/automake/'.


File: 3DLDF.info,  Node: Future Plans,  Next: Changes,  Prev: Adding a File,  Up: Top

Future Plans
************

   3DLDF is a work-in-progress.  In fact, it can never be finished,
because the supply of interesting geometric constructions is
inexhaustible.  However, presently 3DLDF still has a number of major
gaps.

   If you're interesting in contributing to 3DLDF, with respect to one
of the topics below and in the following sections, or if you have ideas
of your own, see *Note Contributing to 3DLDF::.

   * Input routine.  The lack of one is the most significant defect in
     3DLDF, as mentioned in *Note No Input Routine::.

   * Port to other platforms.  *Note Ports::.

* Menu:

* Geometry::
* Curves and Surfaces::
* Shadows::
* Multi-Threading::


File: 3DLDF.info,  Node: Geometry,  Next: Curves and Surfaces,  Prev: Future Plans,  Up: Future Plans

Geometry
========

   3DLDF currently provides a set of basic plane and solid geometrical
figures.  However, some important ones are still missing.  There are
many useful geometrical data types and functions whose implementation
would require no more than elementary geometry.

   * Add constructors with a normal vector argument rather than angles
     of rotation about the main axes.

   * I have started defining `class Triangle', which can be used for
     calculating triangle solutions.

   * Add a class `Conic_Section' and derive `Ellipse' from it.  This
     will be the first case of "multiple inheritance"(1) in 3DLDF,
     since `Ellipse' is already derived from `Path'.  *Note Ellipse
     Reference::.  Add the classes `Parabola' and `Hyperbola'.

   * Add more functions for finding the intersections of objects of
     various types, starting with the plane figures.  In particular, I
     believe I've found an algebraic solution for the intersection of
     an `Ellipse' and a `Circle' in a plane, but I haven't had a chance
     to try implementing it yet.

     If this works, I think it will make it possible to find the
     intersection of two coplanar ellipses algebraically, because it
     will be possible to transform them both such that one of them
     becomes circular.

   * Class `Octahedron' will complete the set of regular Platonic
     polyhedra.

   * Add classes for the Kepler-Poinsot polyhedra, the semi-regular
     Archimedean polyhedra,  the dual solids, the stellated Archimedean
     polyhedra, and the regular compounds.(2)

   * Add class `Ellipsoid' and a derived class `Sphere'.

   * Improve the specification of `Solid' and `Solid_Faced'.  In
     particular, it would help to store the vertices of `Polyhedra' as
     individual `Points', rather than using `Reg_Polygons'.  I'd also
     like to find a better way of generating `Solids', without using
     rotations, if possible.


   ---------- Footnotes ----------

   (1) Stroustrup, `The C++  Programming Language', section 15.2
"Multiple Inheritance", pp. 390-92.

   (2) Cundy and Rollet, `Mathematical Models', Chapter 3, "Polyhedra",
pp. 76-160.


File: 3DLDF.info,  Node: Curves and Surfaces,  Next: Shadows,  Prev: Geometry,  Up: Future Plans

Curves and Surfaces
===================

   3D modelling software usually supports the creation and manipulation
of various kinds of "spline curves": "Be'zier curves", "B-splines", and
"non-uniform rational B-splines" or "NURBS".  These curves can be used
for generating surfaces.(1)

   `paths' in Metafont and MetaPost are Be'zier curves.  It would be
possible to implement three-dimensional Be'zier curves in 3DLDF, but
unfortunately they are not "projectively invariant":

   Let c_0 represent a Be'zier curve in three dimensions, P the control
points of c_0, and t a projection transformation.  Further, let Q
represent the points generated from applying t to P, and c_1 the curve
generated from Q.  Finally, let R represent the points generated from
applying t to all of the points on c_0, and  c_2 the curve through R:
c_1 \not\equiv c_2.

   NURBS, on the other hand, are projectively invariant,(2) so I will
probably concentrate on implementing them.  On the other hand, it would
be nice to be able to implement Metafont's way of specifying `paths'
using ``curl'', ``tension'', and ``dir'' in 3DLDF.  This may prove to
be difficult or impossible.  I do not yet know whether Metafont's
`path' creation algorithm can be generalized to three dimensions.(3)

   Curves and surfaces are advanced topics, so it may be a while before
I implement them in 3DLDF.

   ---------- Footnotes ----------

   (1) Huw Jones, Computer Graphics through Key Mathematics, and David
Salomon, Computer Graphics and Geometric Modeling, are my main sources
of information about spline curves.

   (2) Jones, Huw.  Computer Graphics through Key Mathematics, p. 282.

   (3) Knuth, Donald Ervin.  The METAFONTbook, p. 130, and Hobby, John
D.  Smooth, Easy to Compute Interpolating Splines.  Discrete and
Computational Geometery 1(2).


File: 3DLDF.info,  Node: Shadows,  Next: Multi-Threading,  Prev: Curves and Surfaces,  Up: Future Plans

Shadows, Reflections, and Rendering
===================================

   Shadows and reflections are closely related to transformations and
projections.  A shadow is the projection of the outline of an object
onto a surface or surfaces, and reflection in a plane is an affine
transformation.

   3D rendering software generally implements shadows, or more
generally, "shading", reflections, and certain other effects using
methods involving the calculation of individual pixel values.  Surface
hiding is also often implemented at the pixel level.  3DLDF does no
scan converting ((*note Accuracy::), and hence no calculation of pixel
values at all, so these methods cannot be used in 3DLDF at present.

   However, it is possible to define functions for generating shadows
and reflections within 3DLDF by other means.

   I have defined the function `Point::reflect()' for reflecting a
`Point' in a `Plane', and have begun definining versions for other
classes.

   However, in order for reflections to work, I must define functions
for breaking up objects into smaller units.  This is also necessary for
surface hiding to work properly.

   For MetaPost output, I will have to implement shadows, reflections,
and surface hiding in this way.  However, 3DLDF could be made to produce
output in other formats.  There are two possibilities:  implementing
rendering functionality within 3DLDF, or interfacing to existing
rendering software.  If I decide to do the latter, there are again two
possibilities:  having 3DLDF write output in a format that a renderer
can input, or linking to a library supplied by a rendering package.

   I haven't yet decided which course to pursue.  However, in the long
run, I'd like it to be possible to use 3DLDF for fancier graphics than
is currently possible using MetaPost and PostScript alone.


File: 3DLDF.info,  Node: Multi-Threading,  Prev: Shadows,  Up: Future Plans

Multi-Threading
===============

   When 3DLDF is run, there is only one thread of execution.  However,
it could benefit from the use of multiple threads.  In particular, it
may be faster and more efficient to have `Picture::output()' run in its
own thread.  In this case, it will no longer be possible to share
`current_picture' among figures.

   It may also be worthwhile to execute the code for "figures", i.e.,
the code between `beginfig()' and `endfig()', inclusive, in their own
threads.  This will require some changes in the way data are handled.
For example, if non-constant objects are shared among figures, there
may be no advantage to multi-threading because of the need to
coordinate the access of the threads to the objects.  If threads are
used, then non-constant objects should be declared locally within the
figure.  They may be locally declared copies of global objects.
Alternatively,  `beginfig()' could be changed so that objects could be
passed to it as  arguments, perhaps as a `vector<void*>' and/or a
`vector<Shape*>'.


File: 3DLDF.info,  Node: Changes,  Next: Bibliography,  Prev: Future Plans,  Up: Top

Changes
*******

Updated 14 January 2004.

* Menu:

* Changes in 3DLDF 1.1.5::
* Changes in 3DLDF 1.1.4.2::
* Changes in 3DLDF 1.1.4.1::
* Changes in 3DLDF 1.1.4::
* Initial version::


File: 3DLDF.info,  Node: Changes in 3DLDF 1.1.5,  Next: Changes in 3DLDF 1.1.4.2,  Prev: Changes,  Up: Changes

3DLDF 1.1.5
===========

   In release 1.1.5, I've tied up some loose ends.  I wanted to do this
before starting on the input routine.

   * Added `const real' STEP argument to the version of
     `Ellipse::intersection_points()' that takes an `Ellipse' argument.
     *Note Ellipse Reference; Intersections: Ellipse Intersections.

   * It is now possible to "typedef" `real' to either `float' or
     `double'.  This means that `real' can now be made a synonym for
     either `float' or `double' by using a `typedef' declaration.
     `real' is typedeffed to `float' by default.

   * Added `const bool ldf_real_float' and `extern const bool
     ldf_real_double' for use in non-conditionally compiled code.  They
     are set according to the values of `LDF_REAL_FLOAT' and
     `LDF_REAL_DOUBLE'.

   * `Transform::epsilon()' and `Point::epsilon()' now return different
     values, depending on the values of the preprocessor macros
     `LDF_REAL_FLOAT' and `LDF_REAL_DOUBLE'.  I have not yet tested
     whether good values are returned when `real' is `double'.

   * `MAX_REAL' and `MAX_REAL_SQRT' are no longer constants.  Their
     values are set at the beginning of `main()'.  However, users
     should not change their values.  `MAX_REAL' is the second-largest
     `float' or `double' on a given machine.  This now works for all
     common architectures.

   * Added `namespace System' containing the following functions:
     `get_endianness()', `is_big_endian()', `is_little_endian()',
     `get_register_width()', `is_32_bit()', `is_64_bit()', and the
     template function `get_second_largest()'.

     `namespace System' and its functions are documented in
     `system.texi', which is new in edition 1.1.5.

   * Replaced the various `create_new_'<type>`()' functions with the
     template function `create_new()'.  The latter is documented in
     `creatnew.texi', which is new in edition 1.1.5.

   * Added the file `3DLDF-1.1.5/CWEB/cnepspng.el' to the distribution.
     It contains the definitions of the Emacs-Lisp functions
     `convert-eps' and `convert-eps-loop'.  *Note Running 3DLDF;
     Converting EPS Files; Emacs-Lisp Functions: Converting EPS Files
     ELISP.

   * Added the files `3DLDF-1.1.5/CWEB/exampman.web' and
     `3DLDF-1.1.5/CWEB/examples.mp' to the distribution.  They contain
     the C++  and MetaPost code, respectively, for generating the
     illustrations in this manual.



File: 3DLDF.info,  Node: Changes in 3DLDF 1.1.4.2,  Next: Changes in 3DLDF 1.1.4.1,  Prev: Changes in 3DLDF 1.1.5,  Up: Changes

3DLDF 1.1.4.2
=============

   * The illustrations in the HTML output are now scaled to `magstep3'.


File: 3DLDF.info,  Node: Changes in 3DLDF 1.1.4.1,  Next: Changes in 3DLDF 1.1.4,  Prev: Changes in 3DLDF 1.1.4.2,  Up: Changes

3DLDF 1.1.4.1
=============

   * The HTML output now includes illustrations.


File: 3DLDF.info,  Node: Changes in 3DLDF 1.1.4,  Next: Initial version,  Prev: Changes in 3DLDF 1.1.4.1,  Up: Changes

3DLDF 1.1.4
===========

   * `MAX_REAL' is now the second largest float value.  However, the
     calculation is system dependent, and will only work on 32-bit
     little-endian architectures.  I will start working on porting this
     soon.

   * Fixed bug in `tsthdweb', that caused files to be compiled more
     often than necessary.  It will be necessary to keep an eye on this.

   * Added `Rectangle::is_rectangular()'.

   * Made `mediate()' a member function of `Point'.

   * It is now possible to generate this manual in the Info and HTML
     formats.


File: 3DLDF.info,  Node: Initial version,  Prev: Changes in 3DLDF 1.1.4,  Up: Changes

3DLDF 1.1.1
===========

   3DLDF 1.1.1 was the first version of 3DLDF since it became a GNU
package (the current version is 1.1.5).  It is now conformant to the
GNU Coding Standards, except that a functioning `3DLDF.info' cannot be
generated from `3DLDF.texi'.   The distribution now includes a
`configure' script, `Makefile.in' files, and other files generated by
Autoconf and Automake.  Recompilation is now handled by `make' rather
than the auxilliary program `3DLDFcpl'.  The files `3DLDFcpl.web' and
`3DLDFprc.web' have been removed from the distribution.

   The extension of the C++  files generated by `ctangle' is changed
from `c' to `cxx' before they are compiled.  After `ctangle' is run on
a CWEB file, `<filename>.c' is compared to the old `<filename>.cxx'
using `diff'.  Whitespace, comments, and `#line' preprocessor commands
are ignored.  The `<filename>.c' is only renamed to `<filename>.cxx'
and compiled if they differ.  This way, changes to the TeX text only in
a CWEB file no longer cause recompilation and relinking.

   The main Texinfo file is now called `3DLDF.texi'.  It was formerly
called `3DLDFman.texi'.  This is because Automake expects this name.
For this reason, the CWEB file passed as an argument to cweave has been
renamed `3DLDFprg.web'.  It was formerly called `3DLDF.web'.


File: 3DLDF.info,  Node: Bibliography,  Next: GNU Free Documentation License,  Prev: Changes,  Up: Top

Bibliography
************

   Cundy, H. Martyn and A.P. Rollet.  Mathematical Models.  Oxford 1961.
Oxford University Press.

     Unfortunately out of print.


Finston, Laurence D.  3DLDF:  The Program.  Go"ttingen 2003.

Fischer, Gerd.  Ebene algebraische Kurven.  Vieweg Studium.  Aufbaukurs
Mathematik.  Friedr. Vieweg & Sohn Verlagsgesellschaft mbH.
Braunschweig/Wiesbaden 1994.

Gill, Robert W.  Creative Perspective.  London 1975.  Thames and Hudson
Ltd.  ISBN 0-500-27056-2.

Harbison, Samuel P., and Guy L. Steele Jr.  C, A Reference Manual.
Prentice Hall.  Englewood Cliffs, New Jersey 1995.
ISBN 0-13-326232-4 {Case}.  ISBN~0-13-326224-3 {Paperback}.

Hobby, John D.  Smooth, Easy to Compute Interpolating Splines.
Discrete and Computational Geometery 1(2).  Springer-Verlag.  New York
1986.

Hobby, John D.  A User's Manual for MetaPost.  AT & T Bell Laboratories.
Murray Hill, NJ. No date.

Jones, Huw.  Computer Graphics through Key Mathematics.
Springer-Verlag London Limited 2001.  ISBN 1-85233-422-3.

Knuth, Donald Ervin.  Metafont:  The Program. Computers and
Typesetting; D.  Addison Wesley Publishing Company, Inc.  Reading,
Massachusetts 1986.  ISBN 0-201-13438-1.

Knuth, Donald Ervin.  The METAFONTbook.  Computers and Typesetting; C.
Addison Wesley Publishing Company, Inc.  Reading, Massachusetts 1986.

Knuth, Donald Ervin.  TeX: The Program. Computers and Typesetting; B.
Addison Wesley Publishing Company, Inc.  Reading, Massachusetts 1986.
ISBN 0-201-13437-3.

Knuth, Donald E. The TeXbook.  Computers and Typesetting; A.  Addison
Wesley Publishing Company, Inc.  Reading, Massachusetts 1986.

Knuth, Donald E. and Silvio Levy.  The CWEB System of Structured
Documentation.  Version 3.64--February 2002.

Rokicki, Tomas.  Dvips: A DVI-to-PostScript Translator for version
5.66a.  February 1997.  `http://dante.ctan.org/CTAN/dviware/dvips/'

Salomon, David.  Computer Graphics and Geometric Modeling.  Berlin 1999.
Springer-Verlag.  ISBN: 0-387-98682-0.

Stallman, Richard M. and Roland McGrath.  GNU Make.  A Program for
Directing Recompilation.  make Version 3.79.  Boston 2000.  Free
Software Foundation, Inc.  ISBN: 1-882114-80-9.

Stallman, Richard M.  Using and Porting the GNU Compiler Collection.
For GCC Version 3.3.2.  Boston 2003.  Free Software Foundation, Inc.

Stroustrup, Bjarne.  The C++  Programming Language.  Special Edition.
Reading, Massachusetts 2000.  Addison-Wesley.  ISBN 0-201-70073-5.

Stroustrup, Bjarne.  The Design and Evolution of C++ .  Reading,
Massachusetts 1994.  Addison-Wesley Publishing Company.
ISBN 0-201-54330-3.

Vredeman de Vries, Jan.  Perspective.  New York 1968.  Dover
Publications, Inc.  Standard Book Number: 486-21086-4.

     The beautiful perspective constructions in this volume are taken from
     the original work, first published by Henricus Hondius in Leiden in 1604
     and 1605.


White, Gwen.  Perspective.  A Guide for Artists, Architects and
Designers.  London 1968 and 1982.  B T Batsford Ltd.
ISBN 0-7134-3412-0.

