Policy Matters
As we said earlier, the Java 3D renderer needs to know where the eyes are relative to the screen. This information uniquely defines the view frustum and constitutes the first part of the viewing computation. Given the eye to screen transforms, there are a number of options for using that information to render a frame. Java 3D sets most of these options through policies. The name policy might sound a bit foreboding, but it's really nothing more than a set of rules and operating principles. The idea here is that policies establish the general set of rules for rendering views and really serve to group the options in a logical fashion.
Commonly Used Policies
Several primary policies exist that pertain to most situations. They are as follows:
View Policy
One of the primary policies that comes into play is the view policy. The view policy determines which of two basic sets of transforms are to be used in rendering views. Thus, there are two view policy options, referring to the two distinct series of transforms. The first, SCREEN_VIEW is the default and is suitable for displays such as multiple projection CAVE systems, FishTank VR, and VR desks such as the ImmersaDesk. SCREEN_VIEW requires that the tracker base is rigidly attached to the display screen.
The second policy option is the HMD_VIEW policy, which is used when the screen is attached to the user's head (that is, an HMD). Remember, when the screen is attached the user's head, the camera (not the ViewPlatform) must be translated and rotated rapidly whenever the head moves and rotates. The difference between moving the camera and moving the ViewPlatform is a common source of confusion when learning the view model. The only way to affect the position of the ViewPlatform is to access the TransformGroup that contains the ViewPlatform (as we have done in the previous two chapters). Note that it is possible to set up a chain of transforms so that the ViewPlatform would be chained to the head tracker, but this is not the optimal approach.
To reiterate, the ViewPlatform is only one frame of reference in the chain of transforms that determines the final viewing and projection matrices for each eye and each screen. In the default case, appropriate for the typical desktop display, the ViewPlatform orientation and position is equivalent to the view matrix because we have fixed screen and eye positions centered about the origin of the view platform. On the other hand with head tracking, the screens (eyes) are moving about relative to the view platform. Their positions and orientations relative to the view platform have to be concatenated with the ViewPlatform position and orientation to get the final view transform.
With an HMD_VIEW policy, the left and right screens are the only things slaved to head movement with the HMD_VIEW policy. This relationship is established with the Screen3D setHeadTrackerToLeftImagePlate() and setHeadTrackerToRightImagePlate() methods. From the sensor read and the CoexistenceToTrackerBase transform, we get the position and orientation of the screens and eyes in coexistence coordinates. The view attach policy and screen scale defines the transform from coexistence coordinates to ViewPlatform coordinates. From there we get to the virtual world coordinates and final viewing transform. Recall that the projection transform is determined by the position of the eyes relative to the image plates.
Monoscopic View Policy
The monoscopic view policy is used when Java 3D is creating a monoscopic image (that is, a rendering from the perspective of a single eye). Somewhat counterintuitive is the fact that in most cases when using an HMD, even though you are generating stereo pairs, you are really in a monoscopic view mode because the application is generating two monoscopic views to produce the stereo perception. Of course, fixed screens, when not in stereo mode, also have a monoscopic view policy. However, they can generally accept the default, and therefore we have not had to change this parameter. There are three options for monoscopic view policy—LEFT_EYE_VIEW, RIGHT_EYE_VIEW, and CYCLOPEAN_EYE_VIEW (the default). We also note that not all HMDs have a separate screen for each eye. Some HMDs display interleaved stereo and therefore would have a monoscopic view policy of CYCLOPEAN_EYE_VIEW. Java 3D can accommodate both types of HMD easily.
In the HMD example, LEFT_EYE_VIEW and RIGHT_EYE_VIEW are used in the two Canvas3Ds that we use to display the image to each eye. In the single and multiple monitor situations, we need the CYCLOPEAN_EYE_VIEW. CYCLOPEAN_EYE_VIEW is the default and represents the view from a point halfway between the two eyes (hence the name cyclopean). CYCLOPEAN_EYE_VIEW is also the correct policy to have for those stereo situations in which alternate images are shown to each eye.
Screen Scale Policy
It is occasionally necessary to change the screen scale policy particularly for ease of calibration. In this case, the screen scale policy should be changed from its default value of View.SCALE_SCREEN_SIZE to View.SCALE_EXPLICIT. The screen scale would then be set to 1.0 with the View object's setScreenScale() method. Values other than 1.0 are also useful in certain situations, however, by and large, 1.0 is most common.
Projection Policy
The projection policy determines whether the projection matrix is computed for parallel or perspective. The two possible values are View.PARALLEL_PROJECT and View.PERSPECTIVE_PROJECTION. Recall from Chapter 1, “Media, Imaging, and Visualization Programming on the Java Platform,” that most applications use perspective viewing, but some CAD/CAM and other applications require parallel projection.
View Attach Policy
Understanding the view attach policy is critical to understanding how the physical world of screens, trackers, and the body are mapped in the virtual world through coexistence. In other words, the view attach policy defines the mapping of coexistence coordinates and view platform coordinates.
There are three options for attaching the view: View.NOMINAL_HEAD (the default), View.NOMINAL_FEET, and View.NOMINAL_SCREEN. Generally, you do not have to change this policy from its default.
For a ViewAttachPolicy of NOMINAL_HEAD, the ViewPlatform origin is at the origin of the nominal head—the center eye halfway between the left and right eyes. If the WindowEyepointPolicy is the default RELATIVE_TO_FIELD_OF_VIEW, the nominal head origin is centered about the +Z axis of coexistence coordinates at the offset required to produce the desired field of view relative to the width of the canvas at the coexistence origin. Otherwise, the Z offset is defined by the NominalEyeOffsetFromNominalScreen attribute of PhysicalBody.
The View.NOMINAL_FEET is used to anchor the user's virtual feet to the virtual ground. Rendering is done to ensure that the Y component is zero in the ViewPlatform's coordinate system.
For a ViewAttachPolicy of NOMINAL_SCREEN, the ViewPlatform origin is set directly to the origin of coexistence so that ViewPlatform coordinates and coexistence coordinates are identical except for scale (reflected in the screen scale). Because of this easy mapping, the NOMINAL_SCREEN ViewAttachPolicy is preferable with head tracking and multiple screens.
In truth, this is only correct if CoexistenceCenterInPworldPolicy is NOMINAL_SCREEN.NOMINAL_SCREEN is the default value, and there really isn't any need to set it to anything else because the proper effects can always be achieved with it set to that default. Most developers can and should ignore the CoexistenceCeenterInPworldPolicy because it adds yet another level of complexity to the view model with little benefit. It is important, however, not to confuse the CoexistenceCenterInPworldPolicy with the ViewAttachPolicy.
Finally, we note again that in HMD_VIEW mode, the ViewAttachPolicy setting is ignored and NOMINAL_SCREEN is always used instead.