From guest Wed Nov 24 08:18:13 1993 From: Renee Strong Message-Id: <9311241617.AA16225@pat.mdc.com> Subject: rotates and then translates?? To: info-performer@sgi.sgi.com Date: Wed, 24 Nov 93 10:17:43 CST X-Mailer: ELM [version 2.3 PL11] Status: OR If we do the following, is performer still going to do the rotates first and then the translates? pushmatrix(); loadmatrix(ident); translate(obj->trans[0], obj->trans[1], obj->trans[2]); rot(pitch, 'y'); rot(yaw, 'z'); rot(roll, 'x'); getmatrix(mat); pfDCSMatrix(dcs, mat); popmatrix(); Renee Strong renee@pat.mdc.com From guest Wed Nov 24 08:47:59 1993 From: "Michael Jones" Message-Id: <9311240847.ZM643@babar.asd.sgi.com> Date: Wed, 24 Nov 1993 08:47:50 -0800 In-Reply-To: Renee Strong "rotates and then translates??" (Nov 24, 10:17am) References: <9311241617.AA16225@pat.mdc.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: Renee Strong , info-performer@sgi.sgi.com Subject: Re: rotates and then translates?? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Nov 24, 10:17am, Renee Strong wrote: > Subject: rotates and then translates?? : : If we do the following, is performer still going to do the rotates first : and then the translates? : : pushmatrix(); : : loadmatrix(ident); : : translate(obj->trans[0], obj->trans[1], obj->trans[2]); : : rot(pitch, 'y'); : rot(yaw, 'z'); : rot(roll, 'x'); : : getmatrix(mat); : : pfDCSMatrix(dcs, mat); : : popmatrix(); : >-- End of excerpt from Renee Strong This kind of thing is _really_ dangerous. You can only access GL from the draw process in multiprocess-applications, so this coding style which is ok on a single-process configuration would cause program termination if you specify a multiprocess mode of operation such as PFMP_APP_CULLDRAW. Why not use IRIS Performer host-based matrix routines instead? They will be as fast or faster, and won't tie you to an only-one-process-for-ever implementation. pfMatrix m, r; /* form translation matrix */ pfMakeTransMat(m, obj->trans[0], obj->trans[1], obj->trans[2]); /* pitch about y axis */ pfEulerMat(r, 0.0f, 0.0f, pitch); pfMultMat(m, m, r); /* yaw about z axis */ pfEulerMat(r, yaw, 0.0f, 0.0f); pfMultMat(m, m, r); /* roll about x axis */ pfEulerMat(r, 0.0f, roll, 0.0f); pfMultMat(m, m, r); /* set DCS' transformation */ pfDCSMatrix(dcs, m); -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Nov 24 08:49:07 1993 Date: Wed, 24 Nov 93 08:49:03 -0800 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9311241649.AA29566@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: RE: rotates and then translates?? Status: O The man page for pfDCS states: When independently setting translation, rotation, and scale, the pfDCS matrix is computed as S*R*T, where S is the scale, R is the rotation, and T is the translation. If you want to override this, you can create the matrix yourself: pfMakeEulerMat( myrotation, heading, pitch, roll ); PFMAKE_TRANS_MAT( mytranslation, obj->trans[0], obj->trans[1], \ obj->trans[2] ); pfMultMat( mytransform, mytranslattion, myrotation ); // Rot then Trans In fact, I have used this to override the order of the rotations as well: pfMakeEulerMat( rotate1, roll, 0.0f, 0.0f ); // Roll about heading axis pfMakeEulerMat( rotate2, 0.0f, pitch, 0.0f ); pfMakeEulerMat( rotate3, 0.0f, 0.0f, heading ); // Yaw around roll axis pfMultMat( myrotation, rotate2, rotate3 ); // Roll then pitch... pfPreMultMat( myrotation, rotate1 ); //...then yaw --------------------------------+------------------------------------------ William Briggs |"Monday, I could wait till NASA Ames Research | Tuesday. If I make up my mind. (415) 604-6438 | Wednesday would be fine, --------------------------------+ Thursday's on my mind. MailStop 262-2 | Friday'd give me time, PO Box 1000 | Saturday could wait. But Moffett Field, CA 94035-1000 | Sunday'd be too late." -Sting --------------------------------+------------------------------------------ From guest Wed Dec 8 11:45:32 1993 From: Renee Strong Message-Id: <9312081945.AA10160@pat.mdc.com> Subject: switch pitch and roll To: info-performer@sgi.sgi.com Date: Wed, 8 Dec 93 13:45:02 CST X-Mailer: ELM [version 2.3 PL11] Status: OR I just wanted to post this matrix for other engineers that consider pitch to be about the Y axis and roll about the X axis: x_y_swap_axis = { {0, 1, 0, 0}, {1, 0, 0, 0}, {0, 0, -1, 0}, {0, 0, 0, 1} }; We're loading this matrix first thing onto our channel matrix and it works and then pitching about the Y and rolling about the X and it works! Renee Strong renee@pat.mdc.com From guest Fri Nov 12 12:11:59 1993 Date: Fri, 12 Nov 93 14:11:49 CST From: Roy Decker Message-Id: <9311122011.AA02050@pat.mdc.com> To: info-performer@sgi.sgi.com Subject: Euler angle conventions ??? Status: OR As a new user of Performer, I was surprised to learn that the Euler angle conventions used when setting up viewpoints has the X-axis related to PITCH and the Y-axis related to ROLL. Most conventions (esp. in engineering) would establish just the opposite relationship (i.e. X-axis -> ROLL and Y-axis -> PITCH ). I guess I was just curious why this convention is used? Thanks, Roy Decker From guest Fri Nov 12 15:55:09 1993 Message-Id: <9311122341.AA09283@surreal.asd.sgi.com> To: Roy Decker Cc: info-performer@sgi.sgi.com Subject: Re: Euler angle conventions ??? In-Reply-To: Your message of "Fri, 12 Nov 93 14:11:49 CST." <9311122011.AA02050@pat.mdc.com> Date: Fri, 12 Nov 93 15:41:05 -0800 From: Jim Helman Status: OR It seems everyone has a different religion when it come to Euler angles. We had to choose one. We like this one because it follows the right hand rule sign wise (thumb the axis, fingers positively curl) and has a postive pitch correspond to "pitch up". rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Nov 15 18:10:54 1993 Return-Path: Message-Id: <9311160210.AA16673@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Cc: hasimoto@iml.mkhar.sharp.co.jp Subject: Re:Euler angle conventions ??? Date: Tue, 16 Nov 1993 11:10:13 +0900 From: Takeshi Hashimoto Status: OR I want subclass of pfDCS which uses x,y,z rotation,to use datas of Polhemus or other CAD (like Softimage). I made pfDCSRot2. It seems to work correctly. But GL command is called directly in this function, it may make trouble. Please tell me the best way. void pfDCSRot2(pfDCS *dcs,float argx,float argy,float argz) { pfMatrix m; pfMakeIdentMat(m); pushmatrix(); loadmatrix(m); pfGetDCSMatrix(dcs,m); translate(m[3][0],m[3][1],m[3][2]); rot(argz,'z'); rot(argy,'y'); rot(argx,'x'); scale(pfLengthVec3(m[0]),pfLengthVec3(m[1]),pfLengthVec3(m[2])); getmatrix(m); popmatrix(); pfDCSMatrix(dcs,m); } --- //\\ (O O) \o/ hasimoto@iml.mkhar.sharp.co.jp WOW From guest Mon Nov 15 23:58:41 1993 Message-Id: <9311160758.AA06639@surreal.asd.sgi.com> To: Takeshi Hashimoto Cc: info-performer@sgi.sgi.com Subject: Re: Euler angle conventions ??? Date: Mon, 15 Nov 93 23:58:16 -0800 From: Jim Helman Status: OR > I made pfDCSRot2. It seems to work correctly. > But GL command is called directly in this function, > it may make trouble. What it will make is a core file, if you try to use it anywhere but the draw process. Use the pfMStack or pfMatrix routines. Any operation you need is available directly or through compounding, e.g. GL's rot() -> pfRotMStack or pfMakeRotMat()+pfMultMat(). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 16 01:04:00 1993 Return-Path: Message-Id: <9311160903.AA17704@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Cc: hasimoto@iml.mkhar.sharp.co.jp Subject: Re: Euler angle conventions ??? Date: Tue, 16 Nov 1993 18:03:08 +0900 From: Takeshi Hashimoto Status: OR > What it will make is a core file, if you try to use > it anywhere but the draw process. I wrote these in showcull.c after pfFrame(). But showcull doesn't dumps core. Please let me know why. 305a306,308 > pushmatrix(); > rot(90.0f,'z'); > popmatrix(); I think the y,z,x rotation is better than x,y,z rotation, because it is easy to understand. Y is forward,X is rightward,Z is upward. So I should convert all datas to y,x,z rotation.... --- //\\ (O O) \o/ hasimoto@iml.mkhar.sharp.co.jp WOW From aschaffe Tue Nov 16 01:45:35 1993 From: aschaffe (Allan Schaffer) Message-Id: <9311160145.ZM8583@holodeck.asd.sgi.com> Date: Tue, 16 Nov 1993 01:45:34 -0800 In-Reply-To: Takeshi Hashimoto "Re: Euler angle conventions ???" (Nov 16, 6:03pm) References: <9311160903.AA17704@bach.iml.mkhar.sharp.co.jp> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: Takeshi Hashimoto , info-performer Subject: Re: Euler angle conventions ??? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Nov 16, 6:03pm, Takeshi Hashimoto wrote: > > What it will make is a core file, if you try to use > > it anywhere but the draw process. > > I wrote these in showcull.c after pfFrame(). But showcull > doesn't dumps core. Please let me know why. The answer to that has to do with the multiprocessing model that your application is using. Since you do -not- see this problem, it's likely that you are running on a machine with only one CPU. In this case, the default MP model is to have the APP, CULL, and DRAW all occur in the same process. (PFMP_APPCULLDRAW) In this mode, you can make a GL call from (more or less) any part of the program. But this is dangerous (probably fatal) if you ever intend to run on a multiple-CPU machine. On a machine with (say) 4 CPU's, the application would default to a separated APP/CULL/DRAW process model with each process on its' own CPU. (PFMP_APP_CULL_DRAW) If this were the case, then only the DRAW process would have an active GL context; meaning, you can only make GL calls from within a pipe initialization callback, the draw process callback, or node draw traversal callbacks. If you were to make GL calls from anywhere else (ie, within the APP or CULL), you would get a segmentation fault and core dump. Confusion about multiprocessing is the #1 source of problems in Performer applications. When testing, I definately recommend trying your application in a multi-process mode. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Mar 23 04:01:14 1994 Date: Wed, 23 Mar 94 13:04:13 +0100 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9403231204.AA02905@scl> To: info-performer@sgi.sgi.com Subject: From GL to PF ... may be a solution ... Status: OR Hi everybody ... Finaly it seams I found a way to go from GL view to PF view as follow but may be it is not really the good one ! ... anyway it seams to work currently ... pfMatrix stvViewMatrix; static pfMatrix stvConvertMatrix= { { 1.0f, 0.0f, 0.0f, 0.0f }, { 0.0f, 0.0f, 1.0f, 0.0f }, { 0.0f, -1.0f, 0.0f, 0.0f }, { 0.0f, 0.0f, 0.0f, 1.0f } }; pfCoord stvCamera; stvCamera.xyz[0]= glTransX; stvCamera.xyz[1]= glTransY; stvCamera.xyz[2]= glTransZ; stvCamera.hpr[0]= glRotZ; stvCamera.hpr[1]= glRotX; stvCamera.hpr[2]= glRotY; pfMakeCoordMat(stvViewMatrix, &stvCamera); pfPreMultMat(stvViewMatrix, stvConvertMatrix); pfChanViewMat(stvChannel, stvViewMatrix); Thank's to Renee Strong for her help ! (I think its "her" as Renee in french !) Merci et bienvenue ... Cedric Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Tue Mar 22 08:53:15 1994 Date: Tue, 22 Mar 94 17:57:59 +0100 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9403221657.AA27416@scl> To: info-performer@sgi.sgi.com Subject: From GL world to PF world ... how to translate viewing ?????? Status: OR HI ... Trying to recover camera trajectory from a GL defined world to to Performer world, I have several problems to get the right result ... My original information is XYZ position, XYZ target and roll of the camera in a GL environment ... how to translate it in a Performer based world ? ... Any information will be welcome to improve my beginer's knowledge about it ... Thank's to everybody ... Cedric PS: Is there another solution if I can get the Eulers angles from GL world ? Email: gce@syseca.fr ====================