Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!apple!well!levine From: levine@well.sf.ca.us (Ron Levine) Newsgroups: comp.graphics Subject: Re: Right-handed coordinates in PHIGS Summary: Left handed coordinates exist. Message-ID: <24618@well.sf.ca.us> Date: 7 May 91 04:40:19 GMT References: <24534@well.sf.ca.us> Distribution: comp Lines: 151 To recap my original posting, <24534@well.sf.ca.us>, the three main points are: (1) If you are person confronted with an arbitrary 3D cartesian coordinate system, say as a physical model or drawing, then you can tell its handedness by the right hand rule: thumb +x, index +y, middle +z. But if you are a PHIGS program running in a computer confronted with a coordinate system specified as a transformation matrix linking it to a system of known handedness (or equivalently as three basis vectors expressed in terms of their components with respect to a system of known handedness), then you must compute the sign of the determinant of the 3x3 linear part of that transformation, by one algorithm or another-- systems related by transformations with positive determinant have the same handedness. (2) The only place that coordinate handedness matters in computer graphics is in operations which make use of the vector cross product. (There remains to discuss where PHIGS uses the cross product, and what ill effects might appear in your output display if you inadvertently or intentionally use a left handed system when computing one of these cross products. I will discuss these questions in another article.) (3) The PHIGS standard document specifies that all coordinate systems are right handed. This third point is the subject of this article; in particular, the fact that this specification is not supported by the rest of the definition of PHIGS, and is not met in practice. Under the specified semantics of the relevant PHIGS functions, it is quite possible for an application to cause any of three of the five coordinate systems which are always present in PHIGS to be left handed. I have verified that the possibility exists in my favorite PHIGS implementation, which conforms to the specified semantics for these functions. And this is good, because it is sometimes advantageous for an application to introduce a left handed system. Device Coordinates, the most concrete of the PHIGS systems, at the downstream end of the transformation pipeline, is easiest to deal with. And here is an appropriate place to begin with a picture of a workstation display with axes drawn in it, as in the recent book from the U.K. Moreover, the PHIGS standard insists that DC has its origin at the lower left far corner, and the axes as in the picture. So it is safe to say that Device Coordinates are always right-handed. But it is rarely INTERESTING to say that DC are right handed, because most devices in common use have only 2D display surfaces and the DC z-coordinate has little practical significance. Note that, under this specification, PHIGS DC might not coincide with the natural device coordinates for some devices, for many devices have y increasing downward. Also note that the definition in the cited book would not help you determine which way to add a z-axis to such a system to make it right handed, but the right hand rule would help you with that decision. Normalized Projection Coordinates are related to Device Coordinates by the workstation transformation. The application does not set this transformation explicitly, but rather provides two sets of data which define it: the workstation viewport and the workstation window. The latter is a box (short for rectangular parallelopiped) in the NPC unit cube, the former a box in the Device Coordinate space. The only way to give the workstation transformation a negative determinant is to specify at least one of these boxes with at least one of its limit-pairs in the reverse order, and the standard specifies that this shall be an error. So NPC are always right handed because DC are. View Reference Coordinates are mapped to Normalized Projection Coordinates by the view mapping matrix, an element of the view representation, which the application can specify any way it wants. In particular, the application may intentionally or inadvertently specify a view mapping matrix with a negative determinant (say a reflection), and so a View Reference Coordinate system which is left handed with respect to the right handed NPC. If you use the utility function EVALUATE VIEW MAPPING MATRIX 3 to compute this matrix from its defining "view- volume" boxes, then this accident won't happen, because this function has error checks preventing it. Similar remarks apply to the view orientation transformation, from World Coordinates to View Reference Coordinates, another element of the view representation. You can specify the view orientation matrix yourself and introduce a handedness change, if you wish, or you can avoid the problem by using the provided utility function, EVALUATE VIEW ORIENTATION MATRIX 3, to compute the matrix from the view orientation data: view plane normal, view up vector, and view reference point. Modeling Coordinates, at the input end of the transformation pipeline, are connected to World Coordinates by the modeling transformation. The modeling transformation is in traversal state, so may change frequently, and may well be different for every primitive in a structure. Again, there is nothing to stop the application from supplying any modeling transformation it wishes, as an argument to SET LOCAL TRAN 3 or SET GLOBAL TRAN 3, and so it may make the Modeling Coordinates left handed. If you use the utility functions TRANSLATE 3, ROTATE X, ROTATE Y, or ROTATE Z, to determine the transformation matrices for translations and rotations about coordinate axes, then you will preserve right handedness. But notice that if you supply a scale vector with one or three negative components as an argument to the functions SCALE 3, or BUILD TRAN 3, then you are defining a transformation with a negative determinant, and it is not a specified error condition for these functions. So it is possible to introduce left handed Modeling Coordinates, even when using only the PHIGS utility functions to compute the transformation matrices. Summing up, you can be sure to keep all coordinate systems right handed if you use only the supplied utility functions to compute viewing and modeling matrices, and if you avoid using negative scale factors in the utility functions which take a scale vector as input. Otherwise, you may intentionally or inadvertently make Modeling, World, or View Reference Coordinates left handed with respect to Normalized Device Coordinates. Now, I think it is never desirable to use left handed World or View Reference Coordinates. However, there are times when an application may well wish to use left handed Modeling Coordinates: namely, for complex objects with planes of symmetry (not unusual). Why compute and store all the vertex coordinates and other data for both halves of a symmetric object? In PHIGS you can use the same data as argument to two primitive calls, one generating the mirror image of the effect of the other, by using the modeling transformation to insert a reflection in the symmetry plane between the two primitive calls. Reflection changes handedness. Of course, when you do this, you may have to take into account the possible ill effects from getting the wrong signs for cross products, a problem I'll discuss in another article. What we see here is a deficiency in the logical consistency of the PHIGS specification. It is not the only one. All this is perhaps in somewhat more detail than would be appropriate for a book aiming to be a "practical introduction to PHIGS". However, if such a book raises the issue by attempting to define "right handed coordinate system", then it ought at least to give a correct and useful definition, and, further, it should give the uninitiated reader some clue as to the significance and scope of the concept. Ron Levine Dorian Research, Inc. (415)-535-1350