Graphics Reference
In-Depth Information
As another example, the
contours
of a smooth surface, that is, the points
where the view ray lies in the tangent plane, generally form a set of smooth,
closed curves on the surface, curves that don't intersect one another. For instance,
the contour of a sphere is always a circle on the sphere's surface. For some sur-
faces, from
some
points of view, the contours may have intersections or sharp
corners, but from a randomly picked direction they will be smooth. By contrast,
the contours of a closed triangulated mesh consist of edges that lie between front-
facing and back-facing polygons. These contours are therefore polygonal rather
than smooth curves. But as Figure 25.14 shows, the polygonal curves may inter-
sect, and may do so
generically
(i.e., there's a nonzero probability that for a ran-
domly chosen direction such problems occur).
Figure 25.15: The slices of a
torus are smooth (blue) except at
the min, max, and the two “crit-
ical” levels where the slices are
figure-eights (red).
To the degree that we treat triangulated meshes as surfaces in their own right,
rather than as approximations of smooth surfaces, these oddities are hardly sur-
prising. In a mesh, almost all points are flat: The curvature, no matter how you
measure it, is zero. On the other hand, the curvature along edges or at vertices
is, by the usual measures, infinite. It's as if the curvature that was spread out
over a smooth surface got “condensed” into tiny packets of high curvature. All
the techniques of differential geometry, which depend on taking derivatives of a
parameterization of the surface, must be rethought in this context. The resultant
discrete differential geometry
is an active area of research [Ban65, BS08].
In Figure 25.2, the cube has sharp edges and is
intended
to be a sharp-edged shape.
By contrast, the wavy surface does have a bend at each edge, but the bend is very
small, and the intent is that it should be seen as a smooth shape. When you work
with a mesh in a graphics program, you don't generally know which one of these
is intended. Expressed differently, you know the
data
for the mesh, but you don't
know what it
means
. Just as RGB image formats that fail to say what R, G, and B
mean can have many interpretations (see Chapter 17), meshes that don't include
a description of their meaning are ambiguous, and any single interpretation you
choose in writing a program will be wrong in some cases. This is an example of
the Meaning principle: The numbers (and other data) used to represent meshes
don't have enough meaning to be unambiguous, and this failure of meaning leads
to failed algorithms.
For the bulk of this chapter, we'll assume that meshes are being used to
approximate smooth surfaces, thus assigning a meaning to each mesh. In Chap-
ter 6, we saw how this assumption can lead to problems. The pyramid looked odd
until we remade it from several different meshes. But this remaking entailed its
own problems: To make the pyramid taller now requires that we move not a single
vertex, but several copies of that vertex. The important topological structure was
broken in order to provide a correct rendering structure. For instance, although
the original pyramid might have been a watertight mesh, the new pyramid is not.
That's partly a consequence of the design of graphics interfaces. For instance, both
OpenGL and DirectX require that all the properties of a vertex, such as its normal
vector and texture coordinates, be tied to the vertex position in an indexed triangle
strip. If you want to make a shape like a cube, where a single vertex must have
multiple normal vectors, you're compelled to create multiple vertices at the same
location, leading to nonwatertight models. And all current hardware APIs spec-
ify properties either at the per-mesh level or at the per-vertex level, so concepts
