Direction of Projection
dgobbi at irus.rri.on.ca
Wed May 3 16:15:09 EDT 2000
I'll borrow a copy of F&D and look through that section again, to
ensure that the definitions used in vtkCamera match. The new camera
code should use the same definitions as the old camera code (except for
the WindowCenter creating a shear for parallel projections, which I'm
certain was wrong).
The breakdown of the camera view and projection transformations in
the new code hardly follows F&D at all, though. Its approach is much
closer to OpenGL (which is much, much cleaner IMHO and every bit as
correct). I didn't take specification of oblique projection angles
from either F&D or OpenGL, but as far as I know these are standard
as per drafting texts.
An oblique view plane would probably only be used with perspective
for head-tracked stereo with a powerwall. Setting oblique projection
angles is probably not the best way to do this, but it can be used
to set up the correct view for one eye or the other (not both at
the same time). The old vtkCamera code couldn't support head-tracked
stereo either, though. I've written a section on what is involved
inside vtkProjectionTransform.cxx, someone could eventually add the
functionality to vtkCamera.
On Wed, 3 May 2000, Miller, James V (CRD) wrote:
> 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?
> -----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
> 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?
More information about the vtk-developers