Re: Ortho Cameras

Gavin Bell ([email protected])
Fri, 14 Oct 1994 18:03:43 -0700


On Oct 14, 5:52pm, Linas Vepstas wrote:
> > Focal distance?
> ?? The focal distance is the distance between the eye and the lookat
> point. The lookat point defines the origin of screen coordinates.
> If you were to do depth-of-field effects, the screen is that plane
> in which there is no blurring due to depth-of-field.

Got it. VRP/VRN/etc in the Foley&VanDam terminology.

> I didn't mean to ding inventor, but now that I've looked at it
> carefully, I wish to propose that a textbook-style camera may be
> nicer to have/use. Certainly more flexible & powerful.

I don't like the reference point / lookat point / view plane normal
model because it makes it hard to treat cameras like other objects for
animation purposes.

Consider moving the viewer through space. With the "textbook" view
model, that involves changing both the reference point and the lookat
point. Rotating the camera about the eyepoint is just as bad,
requiring changing the lookat point and the view plane normal.

With Inventor's model, a camera has a position and orientation; to move
or rotate the camera you only have to change one value.

Even nicer, code to animate a translation or rotation can be directly
plugged into a cameras position or orientation field.

Assuming you're willing to give up the flexibility of a view plane
normal for ease of use (I've never used non-perpendicular projections,
except for when doing stereo viewing, and stereo viewing should be
hidden from an author of a VRML document), that just leaves two ways of
specifying the 'zoom' for the camera:

-- width and/or height at the "screen" (focalDistance, to me) plane
-- horizontal and/or vertical field of view

It is trivial to convert between these; a VRML implementation could
certainly store the information in the camera either way. So the
question is really which is easier for a person writing VRML files to
understand.

And I claim that it is easier to understand the concept of
field-of-view angle, because it is independent of the focal distance.
With the field-of-view + focalDistance model, I can just say:
PerspectiveCamera {
position 10 10 10
focalDistance 100
}
... and get a camera at 10,10,10 with a reasonable (default) field of
view and tell the browser the object of interest is 100 units in front
of me.

With a focalDistance + screenHeight model, I would have to:
PerspectiveCamera {
position 10 10 10
focalDistance 100
screenHeight ???something???
}
... respecify the screenHeight every time I specified a new
focalDistance.