ccsupos%prism@GATECH.EDU (06/25/89)
Hi, I am using the subroutines "perspective" and "lookat" on IRIS 4D120GTX. I did not think I needed to push or pop matrices in order just change the projection, viewpoint and the point that is looked at. However, I cannot get the routines to work correctly so I am wondering if I did not miss something. I would appreciate any help on this as the user's guide is not very detailed. Olivier Schreiber
tarolli@dragon.wpd.sgi.com (Gary Tarolli) (06/28/89)
In article <8906250011.AA04052@prism>, ccsupos%prism@GATECH.EDU writes: > Hi, I am using the subroutines "perspective" and "lookat" on > IRIS 4D120GTX. I did not think I needed to push or pop matrices > in order just change the projection, viewpoint and the point that is > looked at. However, I cannot get the routines to work correctly > so I am wondering if I did not miss something. I would appreciate > any help on this as the user's guide is not very detailed. > Olivier Schreiber I cannot guess why your program does not work, I can only help clarify what perspective and lookat do. Perspective loads a matrix onto the matrix stack, destroying what was previously on top of the stack. Lookat multiplies a "lookat" matrix by the top of the stack and replaces the top of the stack with the result. Check the GL User's Guide to see the exact matrices that perspective and lookat generate. In general, you probably want to use perspective and lookat together, doing a perspective without a lookat or a lookat without a perspective is probably a bug. However, it is quite normal to load a perspective matrix, push it, and then apply a lookat. To apply a new lookat, do a popmatrix (gets back to the perspetive) do a pushmatrix (copies it on the stack) and then do another lookat. Hope this clears things up. To aid in debugging, write a routine to print a matrix out to the terminal, then call getmatrix and print the matrix out when things go awry.
ccsupos%prism@GATECH.EDU ("SCHREIBER, O. A.") (07/25/89)
I cannot guess why your program does not work, I can only help clarify what perspective and lookat do. Perspective loads a matrix onto the matrix stack, destroying what was previously on top of the stack. Lookat multiplies a "lookat" matrix by the top of the stack and replaces the top of the stack with the result. Check the GL User's Guide to see the exact matrices that perspective and lookat generate. In general, you probably want to use perspective and lookat together, doing a perspective without a lookat or a lookat without a perspective is probably a bug. However, it is quite normal to load a perspective matrix, push it, and then apply a lookat. To apply a new lookat, do a popmatrix (gets back to the perspetive) do a pushmatrix (copies it on the stack) and then do another lookat. Hope this clears things up. To aid in debugging, write a routine to print a matrix out to the terminal, then call getmatrix and print the matrix out when things go awry. In reference to the above help message, I have straightened out my handling of the transformation matrices. However, the twist given to the projection does not always correspond to the one that is input. Has anyone ever had this problem? Thanks in advance. Olivier Schreiber
thant@horus.sgi.com (Thant Tessman) (07/25/89)
In article <8907250331.AA20644@prism.gatech.edu>, ccsupos%prism@GATECH.EDU ("SCHREIBER, O. A.") writes: > > > In reference to the above help message, I have straightened out > my handling of the transformation matrices. However, the twist > given to the projection does not always correspond to the one that > is input. Has anyone ever had this problem? > Thanks in advance. > Olivier Schreiber This is probably due you assuming that z is up (a perfectly reasonable assumption, one would think) but that the 'lookat' for historical reasons thinks that y is up, not z. To use lookat with geometry where z is up, you can follow lookat with rotate(-900, 'x'); and pretend that z is y and y is -z. Or you can look how the lookat matrix is built (Appendix C of the Graphics Library User's Guide, Volume II) and build your own. Hope this helps. thant@sgi.com
tarolli@dragon.wpd.sgi.com (Gary Tarolli) (07/29/89)
In article <38766@sgi.SGI.COM>, thant@horus.sgi.com (Thant Tessman) writes: > In article <8907250331.AA20644@prism.gatech.edu>, ccsupos%prism@GATECH.EDU ("SCHREIBER, O. A.") writes: > > > This is probably due you assuming that z is up (a perfectly reasonable > assumption, one would think) but that the 'lookat' for historical reasons > thinks that y is up, not z. > > I think it is perfectly reasonable for y to be the up axis. Its not a historical reason, its a logical one. If z was up, then zbuffers would be called ybuffers wouldn't they? Zbuffers are called zbuffers because the z axis runs along the line of sight! This implies x and y are therefore up/down and right/left. -- Gary Tarolli
thant@horus.sgi.com (Thant Tessman) (07/29/89)
In article <39135@sgi.SGI.COM>, tarolli@dragon.wpd.sgi.com (Gary Tarolli) writes: > In article <38766@sgi.SGI.COM>, thant@horus.sgi.com (Thant Tessman) writes: > > In article <8907250331.AA20644@prism.gatech.edu>, ccsupos%prism@GATECH.EDU ("SCHREIBER, O. A.") writes: > > > > > > This is probably due you assuming that z is up (a perfectly reasonable > > assumption, one would think) but that the 'lookat' for historical reasons > > thinks that y is up, not z. > > > > > > I think it is perfectly reasonable for y to be the up axis. Its not a > historical reason, its a logical one. If z was up, then zbuffers would > be called ybuffers wouldn't they? Zbuffers are called zbuffers because > the z axis runs along the line of sight! This implies x and y are > therefore up/down and right/left. > -- > Gary Tarolli > > These are exactly the historical reasons I was refering to. It's logical to computer scientists who started out having to address pixels on a screen using x and y. (Zbuffers are called zbuffers because X and Y were taken already.) Unfortunately for computer scientists, the rest of the world thinks z is up. If we were building these things just for computer scientists it would have also had a left handed coordinate system (gods be praised it doesn't). Seriously, the hotline has spent a man-century or two trying to explain why the 'twist' never seems to do what people thought it did. thant@sgi.com