So why change my projection functions?

---

This article refers to the projection matrix formulation in this post.

---

---

Why is this any better than what I currently use?

• It is easy to visualize and manipulate.
• It has a lot more functionality.
• It can be interpolated.
• It supports stereoscopic 3D.
• It simplifies shadow mapping adjustment.
• It correctly supports the skews required for oblique projections.
• It simplifies the use of offset projections (which are generally under-used because they are not understood).
• It can reduce the number of code paths because the same calculation can be used for multiple matrix forms.
• ...

---

OK, any specifics?

• Camera pull:

This increases or decreases the volume of the frustum while leaving the field of view unchanged. For instance, in a Tennis game, you may want to have the camera inside the stadium and in front of the crowd, but find that the field of view has to be set so large that you get a fish eye effect. Camera pull allows the field of view to be narrower by effectively 'pulling' the virtual camera back. This can be achieved by simultaneously moving the viewport and projection center z values. Without this formulation, the common method of producing camera pull is to move the virtual camera backwards along it's z axis while simultaneously moving the near and far clip values forwards. Camera pull can also be used to modify the spread of depth buffer values to reduce z-fighting.

• Dolly zoom (aka vertigo zoom or tracking zoom):

This involves moving the camera back or forward while simultaneously adjusting the field of view so that the subject remains the same size. This can be achieved by setting the viewport depth to be the same as the subject and moving the projection center z value (ensuring that it does not cross the near clip depth). Without this formulation, the dolly zoom effect is complex, requiring camera movement and constant recalculation of an appropriate field of view.

• Planar zooms:

This involves zooming to any sub-section of the view without rotation. It is intrinsically an offset projection. Planar zooming is similar to the effect used in Blade-Runner to zoom into a photo, it can also be used for tiled rendering. This can be achieved by moving the viewplane and viewport to the point of interest. This can also be achieved by sub-frustum extraction which will be explained in a future post about frustum remapping.

• Simple zoom multiples:

To create a 2x zoom, simply divide the viewport with and height by 2, for a 3x zoom divide by 3 etc.. It might seem that this is nothing special, but with field of view based projections, simply halving the field of view does not produce a 2x zoom. For instance a 2x zoom on a 90 degree field of view equates to approximately a 53 degree field of view, not 45 degrees.

• Blending between parallel and perspective projections:

Because the formulation allows control of the viewplane and viewport, blending between parallel and perspective projections with or without skew is possible by simply blending the input parameters. Standard projection calculations cannot directly achieve this because the viewplane and viewport cannot be specified.

• Oblique projections:

These can be achieved by setting the perspective control parameter p to zero and applying x and/or y offsets to the viewport or center of projection.

• Controlling stereoscopic focus:

The formulation allows control of the viewplane (stereoscopic convergence plane) and eye seperation giving complete control over the stereoscopic effect. When used with stereoscopic 3D controlled by a device driver, the eye seperation should not be used, however as objects on the viewplane will always have a w value of 1.0, the application will still have greater control over the stereoscopic effect than most standard implementations.

• Driving user attention:

Offset projections are great for driving the attention of users. Psychologically, humans always have a conscious or unconscious desire to look towards the vanishing point of an image. By moving the viewport to the right, the viewer will want to move to the left and so on. Viewers can be driven to any point of interest using offset projections. For instance, in the game 'God of War' there are sections where the character is climbing a cliff face with the camera facing the cliff. As the character moves left and right on the cliff, the camera pans to keep him in view. Assuming that there are sufficient protruberences from the cliff to give the player a sense of the vanishing point, panning the viewport instead of the camera would not only keep the character on screen, it would drive the player to want to climb up the center of the cliff.

---

But what about FOV and the other controls I'm used to?

These can all be implemented as helper functions to set the parameters this form requires. A modifier queue should already form part of most good camera systems and all your existing controls should be easy to adapt to this form.

---