[Home]
Table of contents
3D modelling softwares have two types of outputs: images showing
2D views or a file to be fed into a 3D printer. The former
accounts for the lion's share. 2D image processing softwares
come in two flavours: vector and raster. In contrast, 3D
modellers almost exclusively rely on vector description of the
3D world (except for brain imaging softwares that work in terms
of voxels). Yet the 2D image output from a 3D modeller is always
a raster image. Indeed, ray-tracing algorithms need to know
the image resolution even before they start working!
The software I am discussing here takes the path less trodden: 3D vector
model to 2D vector images.
My main aim is to produce mathematical 3D models (like a surface,
lines, cone, cylinders, boxes etc). The output images will be
part of my books (typeset using LaTeX) and printed in B/W. I also
want to embellish my figures with math
expressions. Photrealistically shaded 2D
views of 3D models look gorgeous on the screen. But they lose
much of their lustre during the monochromatic printing. They are
worse than hand drawn figures.
Well, not quite. There used to be a software called sketch
that produced LaTeX figures beased on a vector descriptions of a
scene. Apart from the fact that it relied on some now-outdated
Postscript utilities, it had another serious draw back. It could
not allow curved surfaces. A cone had to be approximated by a
pyramid with a polygonal base, and sketch would draw
all the edges.
Popular 3D modelling softwares like Blender and Art of Illusion
have a post-processing feature to create vector 2D output. They
first produce a 2D raster image, and then perform edge detection
to generate the 2D description. The result is quite
unpredictable, and generally requires a lot of tweaking to get it
right.
Our approach is to move directly from the 3D vector desciption to
2D vector representation using mathematics.
When we see a 2D projection of a 3D scene, it consists of
various lines and curves. Some of these are part of the 3D scene,
while others are viewing artifacts. For example, the two vertical
edges of this cylinder are really not present in the 3D
desciption:
Similarly, the part of the base circumference hidden away from
view (and hence shown in dashed lines) depends on the viewpoint.
However, the upper circumference is indeed part of the 3D desciption.
Traditional 3D renderers tend to draw only the things present in
the 3D desciption, leaving the fictitious lines and curves to
form as a by product.
But we prefer to generate the fictitious curves
mathematically. The lines represent local horizons, places where
the surface smoothly curves in or out of view. It is easy to see
that the tangent plane at such a point must contain the eye. So
if we can parametrise the surface as $(x(u,v), y(u,v))$ and
the eye s at $(a,b,c),$ then
we look for those $(u,v)$, where the tangent plane contains
the point $(a,b,c).$ In general, this conditin leads to an
implicit relation between $u$ ad $v.$ But for quite a
few set ups of practical usefulness, one may get a simple
explicit form as well.
The main structure is given by the following four files.
The generic input needs the following classes:
The generic output needs the following
Here are the 3D objects that constitute a 3D scene. First the
ones with immutable topology:
Then the ones with mutable topology:
Some special cases of the the last type:
The entire software is written using computer scientists'
coordinate system, i.e., the $y$-axis is vertically
upwards, $x$-axis points to the right, while
the $z$-axis sticks out at the viewer. This orientation must
be maintained while creating a new skeleton.
Skeleton files (generally having file extension .3d, though it is
not compulsory) are ASCII files with two types of lines: a vertex
line and an edge line. A tyical
