Direction of Projection

[Miller, James V (CRD)]

I am kinda out of the loop here so I do not know what the goals of changing the camera system were.
Was the code incorrect or just confusing?

My opinion is to follow a phigs-ian implementation (for those who remember PHIGS). A viewing
coordinate system is "always" defined by a VRP (camera origin), PRP (camera location), VPN (view
plane normal), VUP (view up), and view window (region of the view plane visible).  For parallel
projection, a DOP is "calculated" from the PRP and center of the view window. 

Now, this only addresses the implementation.  Another question is what is the appropriate API? Right
now we only support OpenGL rendering, so could just adopt an OpenGL style of API (not my preference).
Another option is provide an API which is a constrained version of the above phigsian model.  Having
to set a window on the viewplane is a pain for most users, so specifying a view angle simplifies the
API.  However, there are cases where specifying the view window and an off-axis PRP is the only way
to accomplish something, for instance stereo rendering moves the PRP, and power wall rendering moves
the view window.

Under most viewing situations, people place the prp along the vpn and use a view window that is
centered around the vrp.  With this model, the DOP is -VPN. Do we need to provide a more general
parallel projection API? Stereo rendering with parallel projection won't work.  Not too many people
have power walls, and those that do can probably live with perspective rendering.  Any other
applications of off-axis DOP?

Jim

-----Original Message-----
From: David Gobbi [mailto:dgobbi at irus.rri.on.ca]
Sent: Wednesday, May 03, 2000 12:27 PM
To: vtk-developers at public.kitware.com
Subject: Re: Direction of Projection


On Wed, 3 May 2000, Ken Martin wrote:

> At 07:21 AM 5/3/00 -0400, you wrote:
> >Folks,
> >         I talked to Jim Miller about the Direction of Projection in the 
> > camera. His first reaction
> >was" DOP is only used for parallel projections." Sure enough, I checked 
> >Foley and vanDam (pg 231, top
> >paragraph).
> >
> >Should we revisit this?
> 
> Again I don't have Foley vanDam here.  But I don't see how this changes 
> anything. We don't use DOP in perspective projections, we use VPN, but... 
> -DOP still is not the same as VPN. If you want to keep using VPN that is 
> fine, but it is not the vector between the camera position (PRP or COP I 
> believe) and the focal point (VRP). Maybe what we want is a boolean 
> indicating (assume VPN is -DOP) which is was what the (3 years or so ago) 
> old code did (but without the boolean). But that is confusing because the 
> shears being introduced are there to handle the case where VPN != -DOP. 
> With the shear angles set, a call to GetVPN that returns -DOP will be 
> misleading.
> 
> - Ken

One easy solution is to remove SetDirectionOfProjection(), I don't think
it has any real value anyway.  GetDirectionOfProjection() would be left
in.

Having both GetViewPlaneNormal() or GetDirectionOfProjection() is a
good thing.  However, I think that it is best if the only way to
set the DirectionOfProjection is via SetPosition(), SetFocalPoint().
And that the only way to create a VPN which is not -DOP is by explicitly
creating a shear by setting the angle between the view plane and the
position->focalpoint vector.

 - David

P.S. I've committed a fix for vtkCamera, the Zoom was broken by a typo.
     Next time I'll test things a bit more before committing.  Does 
     either the vtkbaseline or the main vtk module have the facilities 
     for running all the regression test automatically, like the 
     dashboard does?