[metapost] Re: [metafont] Re: Intersections of NURBs

[Laurence Finston]

Larry Siebenmann wrote:

> 
> If urged, I can agree to identify an ellipse with the planar
> Jordan region it bounds, thus viewing an ellipse as a planar
> surface. 

I see what you mean.  Please pardon my imprecision.  Clearly, an 
ellipse is a curve.  For purposes of filling and surface hiding, I
consider the planar region it encloses as part of the `ellipse' 
object, where `ellipse' is a data type defined in the GNU 3DLDF language
which references an object of type `class Ellipse', which is defined 
internally in the C++ code that implements the 3DLDF interpreter.

> But I am still sorely confused.  What about
> 2-dimensensional surfaces in R^3? -- Spheres in R^3 rather than
> circles; or ellipsoids in R^3 rather than ellipses;  etc. ???

I have defined two classes `Line' and `Plane' which are only used 
internally for vector operations.  There are no corresponding 
data types `line' and `plane' defined in the 3DLDF language.  A 
`Plane' comprises a `Point' that represents a point on the plane,
a `Point' that represents a normal to the plane, and a `real' value that
represents the distance of the plane from the origin.  `real' is defined 
as a synonym either for `float' or `double' by means of a `typedef' 
declaration, depending on the value of a preprocessor macro.  The value 
of the macro is meant to be set by an option to the `configure' 
script distributed with GNU 3DLDF, but I don't remember off-hand whether 
I've implemented this already or not.  In my sources, `real' is a synonym 
for `double'.  

Points in 3DLDF are represented by objects of `class Point', and their 
coordinates are represented by a `valarray' of four `reals', i.e., I'm 
using homogeneous coordinates.  Each `Point' also contains an object of 
type `class Transform', which contains a 4 X 4 matrix of `real' values.

`Paths' contain a `vector<Point*>'.  The classes `Triangle' (which I forgot to

mention in my last posting), `Reg_Polygon', `Rectangle', `Ellipse', and 
`Circle' are all derived from `Path'.  The 3DLDF language defines a
corresponding type for each of these classes, and `Transform' and `Point',
i.e.,
`point', `transform', `path', `triangle', etc.

`paths' and the types derived from it may be planar or not.  If I declare a
`circle' in 3DLDF code, and assign to it as follows:

circle c;
c := unit_circle;

`c' will lie in the x-z plane.  I don't know whether it's possible to make a
`circle' non-planar by means of a transformation represented by a 4 x 4
matrix, 
but if it is, it's allowed in 3DLDF.  In particular, since each `Point' has
its own `Transform', it will be possible to apply different transformations to
each
one, although I have not yet implemented a means of doing this interactively.

I currently define the following types of solid objects:  `cuboid',
`tetrahedron', `octahedron', `dodecahedron', `icosahedron', and
`trunc_octahedron' ("trunc" stands for "truncated").  Each one is represented 
internally by a class, i.e., `Cuboid', `Tetrahedron', etc.  There are other
classes in the hierarchy that do not have corresponding types in the 3DLDF
language, i.e., `Solid', `Solid_Faced', and `Polyhedron'.  I have not yet
implemented spheres or ellipsoids, and I plan to make big changes in the way
solids are implemented.  I'm particularly interested in polyhedra.

> 
> There are difficulties in general with extending the convex hull 
> property to NURBS.  Maybe they can be overcome.

[...]

Thank you very much for your explanations.  I will need some time before I'm
able to understand them.  I'm currently working on learning linear algebra 
and analytic geometry, as well as reading Piegl and Tiller.  Given the
difficulties with NURBs, I may concentrate on the former for now.

> 
> I was implicitly suggesting that objects be left in some
> to-be-develloped affine 3DMP format and the 2D display tasks be
> farmed out to some cross-platform 3D==>2D display application with a
> role analogous to that of a DVI-viewer or of Distiller + Acrobat
> Reader. The viewer application would only have to deal with simple
> projections with center an eyeball in R^3. But it would indeed have
> have to deal with "surface hiding" and hence a modicum of
> intersection theory. 3 dimensional reality is more affine than
> projective; thus it is useful to study dimension 3 by affine (and
> even orthogonal) methods; that's the basic reason for my suggestion.
> 

This is an interesting suggestion.  It's quite different from what 3DLDF does
now.  It's very important to me that 3DLDF always be able to write MetaPost
code, although I believe I will have to use PNG format for advanced rendering.
 Any software I use for displaying and/or preparing printable output will have
to be Free Software, and preferably GNU packages.  The GNU Plotutils and
libpng look promising, but it's time-consuming learning other people's
software, and they can't usually just be "plugged in".  I also strongly prefer
programming myself 
to reading other people's code.  However, eventually, I'll have to "bite the
bullet".

As far as platforms are concerned, I am fortunate in that the GNU Coding
Standards only require maintainers to ensure that their packages run on GNU
systems, i.e., GNU/Linux and the Hurd.  In practice, not many people have the
Hurd yet, and I don't myself, unfortunately, so I'm just concerned with Linux.
 
I would, of course, be very happy if anyone wanted to port 3DLDF to other
systems, but I'm even happier that I don't have to do it myself.

Thanks again.

Laurence