>From: "Gavin Bell" <[email protected]>
>Date: Fri, 14 Oct 1994 18:03:43 -0700
>Subject: Re: Ortho Cameras
>
>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.
Just as hard as animating a cylinder. Somehow, you have to change
the locations of both ends of the cylinder. (Or the cylinder "origin",
the cylinder "direction", and the cylinder "length". And lets not
forget the radius. God forbid its a truncated cone, with a radius
at each end.)
I don't buy that argument.
>Rotating the camera about the eyepoint is just as bad,
>requiring changing the lookat point and the view plane normal.
That's easy! Don't do that! Treat the camera as a rigid object.
Here's what I mean: Consider the cylinder again. There are
two coordinate models for it. One is "floppy": I specify each
endpoint as a 3D point, independently. If you animate it, there
is some chance that you will change the distance between the endpoints,
and so the cylinder will grow & shrink in length. It'll look rubbery.
There is also the "rigid" coordinate model: you specify the cylinder
origin and direction. The length won't "accidentally" change, the
cylinder will behave more like an ordinary physical rod.
If you treat the camera as a rigid object, instead of all these
floppy normals and points, you won't have any problem moving it
around.
>With Inventor's model, a camera has a position and orientation; to move
>or rotate the camera you only have to change one value.
Gee, I wrote the above before I read this sentance.
Yes. This is exactly what I mean. This is true for both camera models,
not just for Inventor.
>Even nicer, code to animate a translation or rotation can be directly
>plugged into a cameras position or orientation field.
I was suggesting that you replace the opening angle parameter with
a screen width & height. I didn't say "throw out position & orientation".
>Assuming you're willing to give up the flexibility of a view plane
>normal for ease of use
You are not giving up ease of use !!! You are getting it !!
to use than the simple-minded one. You aim it, and you shoot. With the
simple minded camera, you fiddle with rotations & translations (ahh,
lesseee, to point it that-a-way, I gotta rotate around this axis -- no,
that axis, and, ahh, translate backwards a little, oops forwards, and
lessee, the opening angle is just a little too big...) Yuck. I went
through that for years until I "discovered" PHIGS style cameras.
> (I've never used non-perpendicular projections,
The standard demo is the split screen demo -- where scwartzenegger
walks behind a screen and turns into a wire-frame stick figure.
You draw the scene once with gouraud shaded polygons, then set
up the camera, and again with wire-frame. (You also have to set
up the clip planes as well).
>except for when doing stereo viewing, and stereo viewing should be
>hidden from an author of a VRML document),
Yes.
> 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.
What's the point of focal distance (in your model) ??
What does it do?
>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.
Jeez. Play fair. What's wrong with "A reasonable (default)
screen height"? Heck, I could claim that
Perspective Camera {
...
FieldOfView ?????something????
}
but I'm not sure what the point of that would be.
--linas