Bug in spec, and spec. addition proposal

Eric A. Haines ([email protected])
Mon, 15 May 95 11:52:42 EDT


The gist: here's a long-winded explanation of a problem in the VRML 1.0 spec,
and a primitive extension (cylinder becomes more general and useful) I'd like
to see.

Len Wanger -- [email protected] comments on the spec:
> Cone: the description is pretty good. To clarify which the bottom is
> change "with its apex at 1" to "with its apex at 1 and its bottom at -1".
>
> Cone and Cylinder: Instead of saying the dimension they are centered
> around specify which dimension their major axis lies on.
>
> Cylinder: Which face is considered the top and which is considered
> the bottom? The spec. should specifying which is the top and bottom
> face (i.e. top is y=1 and bottom is y=-1).

I've been adding a VRML exporter for the SPD package, and noticed an annoying
limitation of this "cone/cylinder" definition: you cannot display a section
of a cone, all cones must have points (great for ice-cream cone design,
unnecessarily limiting otherwise). In other words, you cannot display, say, a
part of a cone where the radius at the base is say 1.0 and at the apex is 0.8.
[Or so I thought, but there's a loophole in the spec which allows you to
(maybe) do so - more below].

Such a conic section is handy for CAD and art and other applications. I
personally don't care about the CAD applications so much (If your CAD system
is halfway decent it'll be outputting polygons, anyway. Also, CAD would want
to be able to control the inner and outer radius of the endcaps for any real
work). But growing things can be nicely modeled with cone pieces. For
example, an elm tree starts with a radius of 1.0 at the base and 0.9 at the
apex of a height 10 cone section. Put a sphere at the end, then grow two more
cone sections at angles for branches, each which has a base radius of 0.9 and
ends at 0.81. Continue this process as much as you wish and you have a
tree-like model (there is code for a simple tree generator in the SPD
[standard procedural database] package, see
ftp://princeton.edu/pub/Graphics/SPD for the package).

My suggestion is to consider extending the Cone{} primitive in 1.0 to include
a topRadius in version 1.1 or 2.0 or whatever. Normally the topRadius is 0.0,
but if set to a positive value it would create a reasonable conic section.
This provides upward compatibility (cones without a topRadius listing are
assumed 0.0 and do not have a top face) and more flexibility. Code-wise it is
not a big deal: it's essentially a cylinder with angled faces and possibly
with or without a top. It should also be allowed that bottomRadius == 0.0
when topRadius > 0.0 for more (easily implemented) flexibility, and there's now
a top face (like for the cylinder) which can be selected for display or not.

Now here's the bug in the spec:

In fact, due to the spec you *could* transform a cylinder into such an
entity by using the last column of the MatrixTransform. For example:

MatrixTransform {
matrix 1 0 0 0
0 1 0 0
0 0 1.125 0.125
0 0 0.125 1.125
}
Cylinder {
parts ALL
radius 1
height 2
}

so that at z=-1 (i.e. [x y -1 1]), the computed W is 1.0 and the base radius
is then 1.0 at Z == -1.0 in world space; at z=1, the compute Z is 1.25,
computed W is 1.25 [and so the world space Z is 1.0] and the apex radius is
transformed to 0.8 (i.e. when you divide the x,y component by w you scale
them by 1/1.25 = 0.8). You're confused? That's part of my point; it was no
cakewalk designing this matrix to do this transform properly.

The point is that the VRML 1.0 spec *does* allow the user to use the last
column to set a perspective divide for the MatrixTransform, and this matrix
above certainly isn't singular (which the spec warns against).

So should we really allow people to use perspective matrices (for this is what
it is) to perform modeling? I highly recommend against allowing this, since
VRML does allow quadric surfaces. For example, to quote Pat Hanrahan from
_An Introduction to Ray Tracing_ page 85:

Unfortunately, when an object is transformed not only are its
coordinates affected but it may be transformed into an object of a
different type. For example, a common modeling technique is to scale a
sphere into an ellipsoid. Perspective transformations can change a
sphere into an arbitrary quadric surface such as a hyperboloid or
paraboloid. Non-rational curves and surfaces may be transformed into
rational curves and surfaces by 4 x 4 transformations. Because the
type of surface changes under transformation, the type of ray-surface
intersection calculation required also changes.

Similarly, the way you handle these within a z-buffer context also changes:
hyperboloid and paraboloids have surfaces which extend to infinity, and most
z-buffers do not render well with w = 0 conditions. Incidentally, Pat's
section is an excellent short primer on matrices for graphics people - I refer
to it a fair bit. It explains how to properly transform normals, for example
(if you're transforming them by the modeling matrix you're doing it wrong),
how to get the eye's location from an arbitrary view matrix, etc.

Anyway, I'm certainly going to assume you cannot use perspective matrices to
model in VRML, and I assume most browsers will blithely ignore the fourth
column. However, the spec. should definitely take a stance on this issue:
either the fourth column is ignored and this is explicitly stated, or it is
supposed to be used. There's an escape hatch of "some matrices (such as
singular ones) may result in errors", but that's supposed to cover matrices
which have determinants of 0 or similar, I would hope. Perspective matrices
are valid, but are usually not handled correctly or at all when used for
modeling.

Whaddya think, sirs?

Eric Haines