From guest Wed Dec 1 01:41:11 1993 Message-Id: <199312010941.AA22437@artemis.cmr.no> To: iris-performer@sgi.sgi.com Cc: thune@cmr.no Subject: Color tables, iv files Date: Wed, 01 Dec 93 10:41:00 +0100 From: Nils Thune Status: O I have a few questions: 1. - How is EarthSky affected by enabling color table mode ? pfEnable(PFEN_COLORTABLE); pfApplyCtab(cTable); - If the EarthSky is effected by the cTable, how big should the table be to handle the EarthSky correctly? 2. - What is the best way of attaching a color table to a loaded geometry node? How can one find out how big the colortable should be? 3. - Is it possible to load iv files (Inventor geometry) into Performer (i.e. is there a loader for it) ? If not, will there be one in a later release? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 05 574040 Phone: 05 574355 (Direct) Fax : 05 574041 -------------------------------- From guest Wed Dec 1 12:26:47 1993 Message-Id: <9312012026.AA15376@surreal.asd.sgi.com> To: Nils Thune Cc: info-performer@sgi.sgi.com, thune@cmr.no Subject: Re: Color tables, iv files In-Reply-To: Your message of "Wed, 01 Dec 93 10:41:00 +0100." <199312010941.AA22437@artemis.cmr.no> Date: Wed, 01 Dec 93 12:26:22 -0800 From: Jim Helman Status: O 1. - How is EarthSky affected by enabling color table mode ? pfEarthSky is not affected by pfColortables. It disables the mode unless you have overriden it on. Instead you should try drawing the earth sky in normal mode, but use the pfEarthSky API to set the colors when you switch colortables for the rest of the scene. 2. - What is the best way of attaching a color table to a loaded geometry node? How can one find out how big the colortable should be? You can specify a pfColorTable in the pfGeoState for a pfGeoSet or use the pre- and post- draw callbacks on a node to change and restore the pfColortable for geometry underneath a node. The colortable needs to be large enough to be indexed by the largest color index stored in any pfGeoSets index array. 3. - Is it possible to load iv files (Inventor geometry) into Performer (i.e. is there a loader for it) ? If not, will there be one in a later release? An Inventor loader will be in the Performer 1.2 release. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 2 05:20:13 1993 From: FREDI@aster.si (Alfred Anzlovar, Aster, +386 (61) 1-683-511) Message-Id: <931202091605.ce@aster.si> Subject: UNSUBSCRIBE To: IRIS-PERFORMER@sgi.sgi.com X-Vmsmail-To: IRIS-PERFORMER@SGI.COM Status: O UNSUBSCRIBE From guest Thu Dec 2 05:32:54 1993 Message-Id: <199312021332.AA25677@artemis.cmr.no> To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: Schedule priority Date: Thu, 02 Dec 93 14:32:37 +0100 From: Nils Thune Status: O In my Performer application I set the schedule priority of the process as follows: schedctl(NDPRI, 0, NDPNORMMAX); // Increase schedule priority prctl(PR_RESIDENT); // Make the process immune to process swapout setuid(getuid()); // Set uid back to real-uid in case it has been changed Will this in any way effect Performer performance (is it allready done inside Performer) ? Is it safe to do it? I'm running on a Indigo 2 Extreme using C++, Motif, GLX and Perf. 1.2. - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 05 574040 Phone: 05 574355 (Direct) Fax : 05 574041 -------------------------------- From guest Thu Dec 2 10:39:20 1993 Date: Thu, 2 Dec 93 13:39:12 -0500 From: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Message-Id: <9312021839.AA22534@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Cc: tonnesen@enews.nrl.navy.mil, (Cindy, Tonnesen) Subject: pfSegsIsectNode difficulties Status: O I'm using the Performer 1.2 Beta Release -- and I'm trying to do something I anticipated would not be too difficult: detecting intersections between a line segment and objects in the scene. Currently, there's only one object in the scene and one line segment to test intersections from. Problems I'm having: pfSegsIsectNode() is currently always returning 1 - that one line segment hit something. When by sight, it is obvious that the line segment was no where near the object. My code looks like: ... pfGeode *root; pfSeg seg; pfHit **hits[1]; float nodehit; _pfSegSet segSet; long numHits; ... root = LoadIcon("/srvr/icons/70.icon"); pfNodeTravMask(root, PFTRAV_ISECT, 0x01, PFTRAV_SELF | PFTRAV_DESCEND | PFTRAV_IS_CACHE, PF_SET); /* I've also tried pfGSetIsectMask() in place of the above line; * both yield the same results. */ ... ... pfMakePtsSeg(&seg, vertics[0], vertices[1]); segSet.typeId = NULL; segSet.userData = NULL; segSet.segs[0] = seg; // set active mask to 0x01; set 0th bit to 1. segSet.activeMask = 0x01; segSet.isectMask = 0x01; segSet.mode = PFTRAV_IS_GSET | PFTRAV_IS_GEODE | PFTRAV_IS_PRIM; segSet.bcyl = NULL; segSet.discFunc = NULL; /* this function is always returning numHits = 1 */ numHits = pfSegsIsectNode(root, &segSet, hits); if (numHits) { nodehit = 0.0; pfQueryHit(hits[0][0], PFQHIT_GSET, &nodehit); if (nodehit != NULL) { /* intersection successful */ processing... } } Part of the difficulty in getting this to work is that I only have man pages as sent with the beta release as documentation, and there are NO examples in it of using the intersection routines. Any light anyone can shed on this would be highly appreciated - even if you do not have the answer to my question, I would *highly* appreciate some sample code that uses these routines successfully! Thank you, Cynthia Tonnesen Naval Research Lab From guest Thu Dec 2 11:14:49 1993 Date: Thu, 2 Dec 93 11:15:33 -0800 From: lblume@miranda (Leo Blume) Message-Id: <9312021915.AA07780@miranda.asd.sgi.com> To: info-performer@miranda Subject: re:pfSegsIsectNode difficulties Status: O Date: Thu, 2 Dec 93 13:39:12 -0500 tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) writes: I'm using the Performer 1.2 Beta Release -- and I'm trying to do something I anticipated would not be too difficult: detecting intersections between a line segment and objects in the scene. [stuff deleted] I too am interested in seeing an example of how pfHit, pfQueryHit, etc is supposed to be used (esp. in the context of pfChanPick). The data struct passed into pfChanPick is supposed to be a: pfHit **pickList[]; Is this supposed to be allocated or does pfChanPick do the allocation? If I am supposed to do the allocation, how big is this array supposed to be? Equal to the max. number of items I think will be hit?? -------------- Leo Blume lblume@sgi.com From guest Thu Dec 2 11:46:44 1993 Message-Id: <9312021946.AA24378@surreal.asd.sgi.com> To: Nils Thune Cc: info-performer@sgi.sgi.com Subject: Re: Schedule priority In-Reply-To: Your message of "Thu, 02 Dec 93 14:32:37 +0100." <199312021332.AA25677@artemis.cmr.no> Date: Thu, 02 Dec 93 11:46:30 -0800 From: Jim Helman Status: O You need to be careful on uniprocessors not to lock out important services like X. Doing so can hang the machine. pfConfig() currently sets non-degrading priorities only on multiprocessor machines. On an MP machine, schedctl, prctl and sysmp are needed to give solid realtime performance. On a uniprocessor, I'm not sure how much difference they will make, e.g. if something needs to run, it will eventually run and if something needs to be paged out for that to happen, something will be paged out (although in the prctl case at least it's not your Performer app). High frame-rate realtime can only be guaranteed on an MP machine. If your frame rate isn't too high and allows enough headroom, you can do reasonably well on a 1P. Getting rid of daemons a by doing "/etc/init.d/network stop" will help. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 2 18:08:30 1993 From: steffen@yoyodyne.corp.sgi.com Message-Id: <9312021808.ZM9573@yoyodyne.corp.sgi.com> Date: Thu, 2 Dec 1993 18:08:25 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe please... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Please unsubscribe me from the list... Thanks, Steffen -- Steffen Low Silicon Graphics Inc. International Business Development 2011 N. Shoreline Blvd steffen@corp.sgi.com P. O. Box 7311 voice 415-390-5022 M/S 3L-913 fax 415-965-1395 Mountain View, CA 94039-7311 From guest Fri Dec 3 13:21:54 1993 Date: Fri, 3 Dec 93 16:21:55 -0500 From: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Message-Id: <9312032121.AA04434@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com, performer-beta@crusty Cc: tonnesen@enews.nrl.navy.mil, (Cindy, Tonnesen) Subject: Intersections in Alpha 72 Beta Status: O 1) What is the proper strategy for detecting intersections between two performer objects? What are the functions that I should look at to do this? 2) What is the proper strategy for detecting intersections of line segments with performer objects? I've been using pfSegsIsectNode(). But since my line is actually contained in a GeoSet that has 3 DCS ancestors I must concatenate 3 matrices together and call pfXformPt3() twice, one for the startpoint and one for the endpoint of my line segment, to transform my line segment into world coords. This all happens before calling pfSegsIsectNode(). This is quite inefficient - What is a better way to do this? Thanks in advance for your help, Cynthia Tonnesen Naval Research Lab From guest Fri Dec 3 14:09:54 1993 Message-Id: <9312032205.AA07539@surreal.asd.sgi.com> To: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Cc: info-performer@sgi.sgi.com Subject: Re: Intersections In-Reply-To: Your message of "Fri, 03 Dec 93 16:21:55 EST." <9312032121.AA04434@enews.nrl.navy.mil> Date: Fri, 03 Dec 93 14:05:01 -0800 From: Jim Helman Status: O Performer does not currently have routines for volume-volume object collisions, but some are planned for a future release. Your method is correct, and not that terribly inefficient. In the current scheme which uses segments, the transformation you describe from object to world coordinates must be done someplace. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun Dec 5 01:02:14 1993 Message-Id: <199312050902.AA06202@artemis.cmr.no> To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: pfRemoveChild(...) Date: Sun, 05 Dec 93 10:02:03 +0100 From: Nils Thune Status: O Will a call to pfRemoveChild(scene, boat) not only remove the boat from the scene but also delete the boat? If the boat is to be removed and deleted should we call: pfRemoveChild(scene, boat); pfDelete(boat); - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Sun Dec 5 07:13:33 1993 Message-Id: <9312051513.AA26902@surreal.asd.sgi.com> To: Nils Thune Cc: info-performer@sgi.sgi.com Subject: Re: pfRemoveChild(...) In-Reply-To: Your message of "Sun, 05 Dec 93 10:02:03 +0100." <199312050902.AA06202@artemis.cmr.no> Date: Sun, 05 Dec 93 07:13:25 -0800 From: Jim Helman Status: O > If the boat is to be removed and deleted should we call: > > pfRemoveChild(scene, boat); > pfDelete(boat); Yes, but remember to create and delete nodes only in the application process. Also, pfDelete is not complete or MP safe in 1.0/1.1, but should work swimmingly in 1.2. If you do use it in 1.0/1.1, don't delete the boat for a few frames after you remove it just to make sure the back end draw process is done with all of it. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Dec 8 11:41:35 1993 From: Renee Strong Message-Id: <9312081941.AA10135@pat.mdc.com> Subject: performer and collision detection To: info-performer@sgi.sgi.com Date: Wed, 8 Dec 93 13:41:25 CST X-Mailer: ELM [version 2.3 PL11] Status: O Are there any plans to put body to body collision detection into future releases of Performer? When is Performer 1.2 supposed to come out? We had heard before Christmas. Renee Strong renee@pat.mdc.com 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: O 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 Wed Dec 8 12:40:32 1993 Message-Id: <9312082040.AA23122@surreal.asd.sgi.com> To: Renee Strong Cc: info-performer@sgi.sgi.com Subject: Re: performer and collision detection In-Reply-To: Your message of "Wed, 08 Dec 93 13:41:25 CST." <9312081941.AA10135@pat.mdc.com> Date: Wed, 08 Dec 93 12:40:21 -0800 From: Jim Helman Status: O > Are there any plans to put body to body collision detection into future > releases of Performer? It's on the list, but there are a couple things above it. > When is Performer 1.2 supposed to come out? We had heard before Christmas. I don't think a date has been officially announced. To be honest, I wouldn't expect to find a copy in my Christmas stocking (at least not one with the newly expanded manual), but not long thereafter. Performer 1.2 would certainly make a fine Valentine for the vis sim aficionado in your life. Those with urgent 1.0/1.1 issues should contact us or their SE. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 9 05:10:36 1993 Date: Thu, 9 Dec 93 14:04:52 +0100 From: matt@khm.Uni-Koeln.DE (Matthias Melcher) Message-Id: <9312091304.AA29421@Obelix.khm.Uni-Koeln.DE> To: IRIS-PERFORMER@sgi.sgi.com Subject: UNSUBSCRIBE Status: O UNSUBSCRIBE From guest Thu Dec 9 07:49:38 1993 From: Kevin Russo Message-Id: <199312091549.PAA01685@midway> To: info-performer@sgi.sgi.com Subject: Cursor changes Status: O I want my Performer1.1 app to be able to change the cursor shape in response to different modes in the simulation. As I understand it, since I'd have to use the GL cursor-routines (or X?) to do this, they can only be invoked in the draw proc. My question is what's the best way to handle changing the cursor shape? Should I make an empty node with a draw callback, where the node's draw traversal mask gets turned on only when I want to change cursors? Or is there a better way of handling this? Thanks for all suggestions. Kevin -- Kevin Russo russo@ait.nrl.navy.mil US Naval Research Lab Washington, DC From guest Wed Dec 15 12:03:04 1993 Date: Thu, 9 Dec 93 13:41:39 -0500 From: marrou@raider.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9312091841.AA01728@raider.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: pfGetNodeBBox Status: O This topic has been touched upon before, but my problem is slightly different. I am using pfGetNodeBBox() on a particular vehicle model, trying to get the visual bounding box, and using the extremities for intersection testing and terrain clamping. However, the bounding box seems to be slightly different than actual. That is, the vehicle goes up a hill before it gets there! Can someone give me a quick hint? Here is the hierarchy, if it makes any difference: DCS: 0 Id: 918 Group: (null) Id: 8 DCS: TopMvmt Id: 873 Geode: (null) Id: 879 GeoSet: 0x143d85f0 GeoState: 0143d61c0 End GeoSet End Geode: 879 Geode: (null) Id: 885 GeoSet: 0x143db060 GeoState: 0143d61c0 End GeoSet End Geode: 885 DCS: Fulcrum Id: 875 Geode: (null) Id: 884 GeoSet: 0x143bb140 GeoState: 0143d61c0 End GeoSet End Geode: 884 DCS: TonCyl Id: 871 Geode: (null) Id: 877 GeoSet: 0x143baf10 GeoState: 0143d61c0 End GeoSet End Geode: 877 DCS: Bridge Id: 869 Geode: (null) Id: 880 GeoSet: 0x143d7210 GeoState: 0143d61c0 End GeoSet End Geode: 880 DCS: Scissor Id: 867 Geode: (null) Id: 887 GeoSet: 0x143d6230 GeoState: 0143d61c0 End GeoSet End Geode: 887 End DCS: 867 End DCS: 869 End DCS: 871 End DCS: 875 End DCS: 873 End Group: 8 End DCS: 918 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From guest Fri Dec 10 04:25:51 1993 Message-Id: <9312101225.AA13570@ifr1.Luftfahrt.Uni-Stuttgart.DE> Date: Fri, 10 Dec 93 13:25:41 +0100 From: michael@ifr.luftfahrt.uni-stuttgart.de To: info-performer@sgi.sgi.com Subject: Wrong transformation for static coordinate systems in Performer 1.2 Status: O We recently installed the beta version of Performer 1.2 on our Indigo R4000 running 4.0.5F. When I tried to get an application running that I had developed with Performer 1.0 I experienced a severe problem. When I place an object into the scene with an SCS the object appears at an entirely wrong location. I found out that this only happens if the rotational part of the transformation is almost zero and the translation is not. If I specify an additional rotation of something like 0.01 deg the translational transformation will be ok. Is this a bug ? If yes is it already known ? I have provided a small code fragment that shows what I am doing. --- code fragment starts here ----------------- void init_stat_grid_3d(int index, Position* Pos, Rotation* Rot, int nx, int ny, int nz, float dx, float dy, float dz, float line_width, float red, float green, float blue, int *status) BEGIN pfGeode *geode; pfMatrix matrix; pfCoord coord; *status = OK; pfSetVec3(coord.xyz, Pos->x, Pos->y, Pos->z); pfSetVec3(coord.hpr, Rot->h, Rot->p, Rot->r); pfMakeCoordMat(matrix, &coord); StatObjTrans[index].earth_offset = pfNewSCS(matrix); /* load the database */ geode = grid_3d(nx,ny,nz,dx,dy,dz,line_width,red,green,blue); IF (geode != NULL) THEN pfAddChild(StatObjTrans[index].earth_offset, geode); ELSE *status = INITIALIZATION_ERROR; ENDIF IF (*status EQ OK) THEN pfAddChild(Scene, StatObjTrans[index].earth_offset); ENDIF return; END |----------------------------------------------------------------------| |Dipl.-Ing. Michael Paus | |University of Stuttgart, Inst. of Flight Mechanics and Flight Control | |Forststrasse 86, 70176 Stuttgart, Germany | |----------------------------------------------------------------------| |Phone: (+49) 711-121-1434 FAX: (+49) 711-634856 | |Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)| |----------------------------------------------------------------------| From aschaffe Fri Dec 10 21:12:41 1993 From: aschaffe (Allan Schaffer) Message-Id: <9312102112.ZM12772@holodeck.asd.sgi.com> Date: Fri, 10 Dec 1993 21:12:40 -0800 In-Reply-To: Kevin Russo "Cursor changes" (Dec 9, 3:49pm) References: <199312091549.PAA01685@midway> X-Mailer: Z-Mail (3.0B.1026 26oct93 MediaMail) To: Kevin Russo Subject: Re: Cursor changes Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 9, 3:49pm, Kevin Russo wrote: > I want my Performer1.1 app to be able to change the cursor shape > in response to different modes in the simulation. As I understand > it, since I'd have to use the GL cursor-routines (or X?) to do this, > they can only be invoked in the draw proc. That's correct, you should only make direct GL calls (like defcursor, setcursor, etc in this case) from within the draw process. > My question is what's the best way to handle changing the cursor > shape? Should I make an empty node with a draw callback, where > the node's draw traversal mask gets turned on only when I want > to change cursors? Or is there a better way of handling this? Instead of using an empty node and worrying about traversal masks, ordering, etc. I would probably implement this by doing the call to defcursor() (to construct the new GL cursor) in a pipe-initialization callback, and then do the call to setcursor() in a channel-draw callback. See complex.c for an example of setting up the callbacks. Using complex.c as a base, you would add the defcursor() stuff in the OpenPipeline() function, and make calls to setcursor() from within DrawChannel(). Happy hacking, Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Mon Dec 13 06:10:09 1993 Date: Mon, 13 Dec 93 10:07:44 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9312131507.AA01423@ldsa.com> To: info-performer@sgi.sgi.com Status: O I am having a problem that I'm sure is goign to seem very basic judging from the level of questions I have seen here. I am running Performer 1.0 with a single processor Indigo2 Extreme as target platform. All my program does right now is load 2 flight format models, place them on the screen one above the other, and rotate them in opposite directions. When I run this program, (requesting 30hz) it has a very disturbing stutter. Viewing the stats, it appears to be switching between 30hz and something around 5hz. This is not consistant, and sometimes does not occur at all. Tech support suggested that I run as root, but this is not an option for me. I am going to doing much more ambitious displays with flight format models, and I want to get this resolved as soon as possible. One last detail. I am writing my code in ada with a set of bindings provided to me by Mr Embry at SGI. I expect that this is probably a common problem that some of you may have encountered, and solved. Thanks in advance. Mike Williams (mwilliam@ldsa.com) Loral Defense Systems - Akron From guest Mon Dec 13 06:53:57 1993 From: fouts@exacto.atlanta.sgi.com (Christopher Fouts) Message-Id: <9312130954.ZM1708@exacto.atlanta.sgi.com> Date: Mon, 13 Dec 1993 09:54:01 -0500 In-Reply-To: mwilliam@ldsa.com (Micheal J. Williams) "" (Dec 13, 10:07am) References: <9312131507.AA01423@ldsa.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer 1.0 on Extremes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 13, 10:07am, Micheal J. Williams wrote: > Subject: | | I am having a problem that I'm sure is goign to seem very | basic judging from the level of questions I have seen here. | | I am running Performer 1.0 with a single processor Indigo2 | Extreme as target platform. All my program does right now is | load 2 flight format models, place them on the screen one above | the other, and rotate them in opposite directions. There's a problem with the clock routines for the Indigo2 Extreme version of the libraries. It's fixed in 1.2, but that won't be released for a bit. Someone else may have a workaround. -- Chris Fouts Email: fouts@atlanta.sgi.com Systems Engineer Phone: (404)-392-1333 Silicon Graphics Computer Systems Vmail: 5-8714 Atlanta, GA "What you see is real. What you smell is unfortunate." Tom Servo, Mystery Science Theatre 3000 From guest Mon Dec 13 07:25:15 1993 Message-Id: <9312131525.AA28858@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Mon, 13 Dec 93 10:07:44 EST." <9312131507.AA01423@ldsa.com> Date: Mon, 13 Dec 93 07:25:06 -0800 From: Jim Helman Status: O A single processor machine can't do realtime very well. But bouncing between 30Hz and 5Hz is absurd and running as root will not fix it (Performer sets non-degrading priorities, that's it). It could be anything from a gfx usage problem to a problem with ADA. Unfortunately, it's not a "common problem." And I don't see an easy path. Try to make it reproducible, i.e. steady 5Hz. And keep working with tech support. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 07:31:42 1993 Message-Id: <9312131531.AA28869@surreal.asd.sgi.com> To: fouts@exacto.atlanta.sgi.com (Christopher Fouts) Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.0 on Extremes In-Reply-To: Your message of "Mon, 13 Dec 93 09:54:01 EST." <9312130954.ZM1708@exacto.atlanta.sgi.com> Date: Mon, 13 Dec 93 07:31:34 -0800 From: Jim Helman Status: O Performer 1.0 doesn't know about the Indigo2 Extreme, since it didn't exist back then. The clock problem I'm aware of would not affect frame rate (run osview on an rlogin or tty and look at the swapbuf rate), but could cause bad time values. If the application is doing pfGetTime()-based animations, either low frame rate or bad times could cause "Extreme" jerkiness. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 08:00:57 1993 Date: Mon, 13 Dec 1993 08:01:43 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199312131601.IAA15079@mail.netcom.com> To: info-performer@sgi.sgi.com, jimh@surreal Subject: Re: Performer 1.0 on Extremes Status: O I also have noticed the frame rate stuttering reported by Mike WIlliams when running on a single processor Indigo2 Extreme, a Personal IRIS 4D/35GT+, and possibly on an Indigo Elan (can't remember for sure about this last one). What caused me to notice the stutter at first was that pfDrawChanStats went bananas and performed so badly that it was nearly impossible to read the graph because each frame time it reported bounced back and forth between fast and slow times. In the release notes of Performer 1.2 Beta it states that 1.0 has a bug in some of the pf routines that use the real time clock on machines that don't have a high resolution hardware clock. This bug was fixed in 1.2, so since I have a copy of 1.2 Beta I extracted the appropriate object module from my 1.2 library .a file and replaced the bad object module in the 1.0 library. That fixed the pfDrawChanStats display. However, I think I am still getting some uneveness in actual frame rate as reported by Mike Williams, tho I don't think mine is as extreme as the variation he reports. I have not benchmarked this behavior to prove it, either. Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Mon Dec 13 10:07:31 1993 Date: Mon, 13 Dec 93 10:09:07 -0800 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9312131809.AA05861@bessie.cs.nps.navy.mil> To: fouts@exacto.atlanta.sgi.com (Christopher Fouts), info-performer@sgi.sgi.com Subject: Re: Performer 1.0 on Extremes References: <9312131507.AA01423@ldsa.com> Status: O To get around the clock problem on the Extremes adn VGXs we had to use the normal system clock. While it had only a 100Hz accuracy it was a lot easier tehn waiting. Also, the code was now portable. The Fast timer option takes too much CPU time to be a vaild choice. Dave Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Mon Dec 13 12:13:52 1993 Message-Id: <9312132013.AA29166@surreal.asd.sgi.com> To: info-performer@crusty Subject: Re: Performer 1.0 on Extremes In-Reply-To: Your message of "Mon, 13 Dec 93 10:34:51 EST." <9312131034.ZM2370@exacto.atlanta.sgi.com> Date: Mon, 13 Dec 93 12:13:50 -0800 From: Jim Helman Status: O On Dec 13, 7:31am, Jim Helman wrote: > Subject: Re: Performer 1.0 on Extremes | | Performer 1.0 doesn't know about the Indigo2 Extreme, since it didn't | exist back then. The clock problem I'm aware of would not affect | frame rate (run osview on an rlogin or tty and look at the swapbuf | rate), but could cause bad time values. If the application is doing | pfGetTime()-based animations, either low frame rate or bad times could | cause "Extreme" jerkiness. Chris Fouts just corrected me. There is a frame rate problem when running in PFPHASE_FIXED or PFPHASE_FLOAT on an Extreme because Performer will attempt to throttle to a constant frame rate using the bad time values. Try PFPHASE_FREE. In 1.2, the time problem was fixed, and the Extreme now supports the pfVClock(), so frame control is better. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 11:43:24 1993 Date: Mon, 13 Dec 93 15:41:13 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9312132041.AA01669@ldsa.com> To: info-performer@sgi.sgi.com Status: O The pfChanPick command has a mode variable which id represented as a bitwise OR of five possible options. My header file only has a define for PFPK_M_ALL. Is this then my only option with Performer 1.0? I am going to use this command to allow the user to select flight format objects by clicking the mouse on them. Each model is loaded as a DCS node. What in the pfIsect structure is going to tell me what model was selected. I want to pass information ahead about what was chosen. I guess what I would expect is to have some unique identifier on each node as a add it to the scene. Then Performer could return this identifier to me to specify a particular node. That may be built in somewhere, but I don't see it. Thanx Mike Williams mwilliam@ldsa.com From guest Mon Dec 13 12:32:22 1993 Message-Id: <9312132032.AA29216@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Mon, 13 Dec 93 15:41:13 EST." <9312132041.AA01669@ldsa.com> Date: Mon, 13 Dec 93 12:32:15 -0800 From: Jim Helman Status: O If you ware picking a single object, you probably just want the closest hit, which is the default if you do not OR PFPK_M_ALL into the mode. You can also OR in /* isect modes */ #define PFTRAV_IS_PRIM 0x01 /* report isects at poly level */ #define PFTRAV_IS_GSET 0x02 /* report isects at geosets */ #define PFTRAV_IS_GEODE 0x04 /* XXX - libpf report isects at geode nodes */ #define PFTRAV_IS_NORM 0x08 /* return normal */ #define PFTRAV_IS_CULL_BACK 0x10 /* ignore backfacing polygons */ #define PFTRAV_IS_CULL_FRONT 0x20 /* ignore frontfacing polygons */ 1.2 uniquely identifies the object intersected by a path through the scene graph. Unfortunately, 1.0/1.1 only provides the pfGeoSet. If your models are not instanced (i.e. the same subgraph or geoset does not exist under multiple DCSes) the pfGeoSet will provide a unique ID. If you need to retain instancing, you could switch to pfSegsIsectNode, use a preIntersection traversal callback on each DCS and a discriminator callback to log the current DCS. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 12:51:33 1993 Message-Id: <9312132051.AA29306@surreal.asd.sgi.com> To: hitchner@netcom.com (Lew Hitchner) Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.0 on Extremes In-Reply-To: Your message of "Mon, 13 Dec 93 08:01:43 PST." <199312131601.IAA15079@mail.netcom.com> Date: Mon, 13 Dec 93 12:51:22 -0800 From: Jim Helman Status: O Lew Hitchner writes: This bug was fixed in 1.2, so since I have a copy of 1.2 Beta I extracted the appropriate object module from my 1.2 library .a file and replaced the bad object module in the 1.0 library. Mixing objects between releases is brazen, but unsafe. Don't try this one at home. In this case, it will actually break the hi-res clock on some machines because tokens internal to Performer changed. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 17:13:29 1993 From: "Wade Olsen" Message-Id: <9312131711.ZM29358@fnord.asd.sgi.com> Date: Mon, 13 Dec 1993 17:11:34 -0800 In-Reply-To: Kevin Russo "Cursor changes" (Dec 9, 3:49pm) References: <199312091549.PAA01685@midway> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: Kevin Russo , info-performer@sgi.sgi.com Subject: Re: Cursor changes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 9, 3:49pm, Kevin Russo wrote: > Subject: Cursor changes > I want my Performer1.1 app to be able to change the cursor shape > in response to different modes in the simulation. As I understand > it, since I'd have to use the GL cursor-routines (or X?) to do this, > they can only be invoked in the draw proc. > > My question is what's the best way to handle changing the cursor > shape? Should I make an empty node with a draw callback, where > the node's draw traversal mask gets turned on only when I want > to change cursors? Or is there a better way of handling this? > >-- End of excerpt from Kevin Russo I think a better way would be to place a structure in shared memory containing all such info (e.g. wireframe mode, disable texturing, cursor shape). This structure should be allocated before pfConfig (i.e. before performer forks draw and cull processes) so all processes have a pointer to it. The structure could also contain a counter that was incremented after any data was changed. Then in the channel draw callback a local static counter can be compared to see if something has changed. Another option that I prefer is a little more complicated and addresses the issue of GUI's in a different way. I have a Motif/Performer example where the application process opens a window, creates the user interface, and handles all events. The tricky part is some GLX code that allows the app process to disconnect from the GLX widget and allow the draw process to connect to it. This example works with performer 1.1 but should be easy to port to 1.2. Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From aschaffe Tue Dec 14 18:20:07 1993 From: aschaffe (Allan Schaffer) Message-Id: <9312141820.ZM24236@holodeck.asd.sgi.com> Date: Tue, 14 Dec 1993 18:20:07 -0800 In-Reply-To: Jim Helman "" (Dec 13, 12:32pm) References: <9312132032.AA29216@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.0B.1026 26oct93 MediaMail) To: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 13, 12:32pm, Jim Helman wrote: > > If you ware picking a single object, you probably just want the > closest hit, which is the default if you do not OR PFPK_M_ALL into > the mode. You can also OR in > > /* isect modes */ > #define PFTRAV_IS_PRIM 0x01 /* report isects at poly level */ > [...] Jim is correct. I would also add that there is a "bug" in 1.0, where PFPK_M_NEAREST (mentioned in the man page) isn't defined in pf.h It should be: #define PFPK_M_NEAREST 0 Since (foo | 0) equals foo, most people just ended up with PFPK_M_NEAREST anyways. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Tue Dec 14 18:30:21 1993 Date: Tue, 14 Dec 1993 21:29:45 -0500 From: William E Gerhard Message-Id: <199312150229.AA20926@stealth.afit.af.mil> To: info-performer Subject: unsubscribe Status: O From guest Tue Dec 14 21:40:46 1993 Date: Wed, 15 Dec 93 14:09:44 JST From: mizo@sgb.kobe.mhi.co.jp (Minori Mizoguchi) Return-Path: Message-Id: <9312150509.AA02007@sun4.sgb.kobe.mhi.co.jp> To: info-performer%sgi.com@kddlab.kddlabs.co.jp Subject: Performer 1.2 beta Reply-To: mizo@sgb.kobe.mhi.co.jp Status: O Is there any way we can get a beta version of Performer 1.2? Thanks, Minori Mizoguchi Mitsubishi Heavy Industries, Ltd. mizo@sgb.kobe.mhi.co.jp From aschaffe Tue Dec 14 22:03:48 1993 From: aschaffe (Allan Schaffer) Message-Id: <9312142203.ZM25539@holodeck.asd.sgi.com> Date: Tue, 14 Dec 1993 22:03:48 -0800 In-Reply-To: mizo@sgb.kobe.mhi.co.jp (Minori Mizoguchi) "Performer 1.2 beta" (Dec 15, 2:09pm) References: <9312150509.AA02007@sun4.sgb.kobe.mhi.co.jp> X-Mailer: Z-Mail (3.0B.1026 26oct93 MediaMail) To: mizo@sgb.kobe.mhi.co.jp Subject: Re: Performer 1.2 beta Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Dec 15, 2:09pm, Minori Mizoguchi wrote: > Is there any way we can get a beta version of Performer 1.2? The general answer is no; the beta sites are already well into the beta effort. Since we're not far from general (and well documented :-) ) release, you won't have to wait too long before 1.2. It's also a lot of work to support each site, so we like to keep the number small. As always, customers with unusual circumstances should get in touch with their marketing or sales contact. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Dec 15 08:36:30 1993 Message-Id: <9312151636.AA21725@sgi.sgi.com> Subject: IRIX 5.1 To: info-performer@sgi.sgi.com Date: Wed, 15 Dec 1993 17:35:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 656 From: Patrick Aschwanden Sender: paschwan@ifi.unizh.ch Status: O We got problems with the Performer 1.1 running on IRIX 5.1 . The Object-Files don't fit together. After compiling, we get following errors : /usr/bin/CC -ansi -D__EXTENSIONS__ -DREALITY -g -DDDBUG -I. -I/usr/include/Performer -I/usr/src/Performer/include -o complex4 complex4.o map.o mysgo.o env.o -L/usr/src/Performer/lib -L/usr/lib -L -L/f/paschwan/gnu/usr/local//usr/lib -lpf -lpr -lmpc -limage -lfm_s -lgl_s -lm -lfpe -lC -lc_s ld: Object file format error in: /usr/lib/libpf.a(pfProcess.o): cannot mix Elf and COFF objects. Any suggestions ?? Patrick Aschwanden paschwan@inf.ethz.ch Multi-Media-Lab, University of Zuerich From guest Wed Dec 15 08:55:49 1993 Date: Wed, 15 Dec 93 08:56:20 -0800 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9312151656.AA13211@bessie.cs.nps.navy.mil> To: Patrick Aschwanden , info-performer@sgi.sgi.com Subject: Re: IRIX 5.1 Status: O You can't mix files compiled on 4.0.5 and 5.X. As such you must recompile everything when you change operating systems. With the changes in the compiler, expect it to take an hour or two. The new compiler is stricter. Dave Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Wed Dec 15 12:47:34 1993 Message-Id: <9312152047.AA21974@surreal.asd.sgi.com> To: marrou@raider.vsl.ist.ucf.edu (Lance Marrou) Cc: info-performer@sgi.sgi.com Subject: Re: pfGetNodeBBox In-Reply-To: Your message of "Thu, 09 Dec 93 13:41:39 EST." <9312091841.AA01728@raider.vsl.ist.ucf.edu> Date: Wed, 15 Dec 93 12:47:25 -0800 From: Jim Helman Status: O > That is, the vehicle goes up a hill before it gets there! Perhaps you are using pfNodeBSphere(node, sph, PFBMODE_PSYCHIC)? First, on nodes, you should use pfGetNodeBSphere(), not pfGetNodeBBox(), which is currently useless since it merely returns a bbox around the node's bsphere, i.e. you get a bounding cube! If you want a tight bound on the vehicle, you should apply pfuCalcBBox() once at db load time to the group under the DCS and then use the DCS matrix at frame time to transform the bounding box. If a looser bound is OK, forget pfuCalcBBox()*pfGetDCSMat() and use pfGetNodeBSphere() on the DCS. There's no way for Performer to anticipate where the vehicle will be. I suspect you are seeing something which you don't expect because of the box-around-sphere behavior. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 16 11:47:11 1993 X-Authentication-Warning: afrodite.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: afrodite.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: Precision in Performer... Date: Thu, 16 Dec 1993 20:46:09 +0100 From: Nils Thune Status: O I have some problems with unstable objects/views when the object position becomes rather large. As an example, if the position part of the object is P(556615.0013, 587501.1945, 10.0000), and the orientation part is O(47.5678, 0.0000, 0.0000) and the heading of the orientation part is incremented with a small delta angle each frame, then I get a very jerky image. The view matrix is usually a simple translation matrix. The view and/or object jumps around and does not seem to be fixed to each other. This is also true when the view matrix is the identity. for (;;) { ......... objPosDir.hpr[PF_H] += deltaAngle; // If the heading will never be > 360.0 ! pfDCSCoord(dcs, &objPosDir); // Position object pfMakeCoordMat(m2, &objPosDir); // Get object position pfMultMat(m1, viewMatrix, m2); // and add view offset pfChanViewMat(channel, m1); // and set the view. .......... } Now, if I scale the x and y part of the object position with 1/1000.0f then the jerkyness is gone. Is there something wrong with my eyes, should I set the view matrix in a different way, or is it Performer which can't handle such numbers? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Thu Dec 16 12:50:12 1993 Message-Id: <9312162048.AA11936@surreal.asd.sgi.com> To: Nils Thune Cc: info-performer@sgi.sgi.com Subject: Re: Precision in Performer... In-Reply-To: Your message of "Thu, 16 Dec 93 20:46:09 +0100." <199312161946.UAA04550@afrodite.cmr.no> Date: Thu, 16 Dec 93 12:48:37 -0800 From: Jim Helman Status: O I belive you are simply exceeding the limits of single precision floating point numbers. If your object is one unit large and you position the object at (x, y+1, z) and the eye point at (x, y, z) with x, y, z large enough so that in the FP representation (y+1) == y, then the position relative to the eye point (y+1)-y is going to suffer severe precision problems. Normally, single precision floating point should get you to around 1.0e7 before suffering one unit jerkiness, but it's plausible that intermediate calculations might cause a loss of precision earlier. One solution is to maintain double precision tile offsets, model the tiles near the origin and handle the translations yourself so that neither the DCS nor the ChanView translations get too large. Angles substantially outside the range of -360 to 360 can also cause problems, but you indicate your angles stay small. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 16 16:34:26 1993 From: "Wade Olsen" Message-Id: <9312161633.ZM4081@fnord.asd.sgi.com> Date: Thu, 16 Dec 1993 16:33:27 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: A performer motif example Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O A few people have asked for the Performer/Motif example so here it is. The key point of this example is the application process handles all the x events for the GLX widget (and everything else). This was written for 1.0/1.1 so there will probably be a few changes to work with 1.2. To extract: save this message to a file. Run uudecode on it. Run "tar xvf " on the decoded tar file. Wade begin 644 performer_motif.tar M<&5R9F]R;65R7VUO=&EF+P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````#`P,#2P@ M=&AI2!I2!D;V5S('-O(&)Y(&]P96YI;F<@:71S"F]W;B!W:6YD;W&ES=&EN9R!'3%@@=VED9V5T(&-R96%T960@8GD@=&AE(&%P<&QI8V%T:6]N M"G!R;V-E2!S:6UP;&EF:65D+@H**B\*"B-I;F-L=61E(#QS=&1I;RYH M/@HC:6YC;'5D92`\7!E0H*"0D)"2\O(%1H:7,@R`B+6UP(BP@(BIM<%]M;V1E(BP@ M6')M;W!T:6]N4V5P07)G+"!.54Q,('TL"GT["@IS=&%T:6,@9FQO870@9&EA M;65T97(["0DO+R!$:6%M971E%]P;W,["0DO+R!# M=7)R96YT(&UO=7-E('!OF4["2\O($-UF4[ M"2\O('-H87)E9"!M96UOR!-3T1%7U=)4D5&4D%-12P@34]$15]415A455)%+"!.54U? M34]$15,@?3L*"G-T871I8R!S=')U8W0@9')A=U]M;V1E7W-TPH@("`@1TQ87TY/ M4DU!3"P@1TQ87T)51E-)6D4L("`)1TQ87TY/0T].1DE'+`H@("`@1TQ87TY/ M4DU!3"P@1TQ87UI325I%+"`@"4=,6%].3T-/3D9)1RP*("`@($=,6%].3U)- M04PL($=,6%]$3U5"3$4L"512544L"B`@("!'3%A?3D]234%,+"!'3%A?4D=" M+"`@(`E44E5%+`H@("`@1TQ87TY/4DU!3"P@1TQ87U=)3D1/5RP)1TQ87TY/ M3D4L"B`@("`P+"`P+"`P+`I].PH*"B\O($%N(%AT(&-A;&QB86-K(&9U;F-T M:6]N(&-A;&QE9"!W:&5N(&$@(F1R87<@;6]D92(@8G5T=&]N(&ES"B\O('1O M9V=L960N"@IS=&%T:6,@=F]I9"`*;6]D94-"*%=I9&=E="P@:6YT(&UO9&4L M(%AM5&]G9VQE0G5T=&]N0V%L;&)A8VM3=')U8W0@*B!C8BD*>PH@("`@9')A M=U]M;V1E2`](%A/<&5N1&ES<&QA>2AG;'A?:6YF;RT^9&ES<&QA>5]N86UE*3L* M("`@(%=I;F1O=R!G;'A?=VEN9&]W(#T@9VQX7VEN9F\M/GA7:6YD;W<["B`@ M("`*("`@(%A7:6YD;W=!='1R:6)U=&5S(&%T=')I8G5T97,["B`@("!81V5T M5VEN9&]W071TPH)("`@(&-O;F9I9UMI72YA%]W:6YD;W<[ M"@E]"@H)"0D)+R\@0V]N;F5C="!T:&4@1TP@8V]N=&5X="!T;R!T:&4*"0D) M"2\O($=,6'=I9&=E="!CPH@("`@PH@("`@("!I9B`H9')A=U]M;V1E'!O%]I;F9O"B\O('-T%]S:7IE M(#T@8V(M/G=I9'1H.PH)*G=I;E]Y7W-I>F4@/2!C8BT^:&5I9VAT.PH@("`@ M?0H*"0D)"2\O(%1H:7,@:&%P<&5NF5D+@H@("`@:68@*&-B+3YR96%S;VX@ M/3T@1VQX0U)?1TE.250I"B`@("!["@E$:7-P;&%Y("H@9&ES<&QA>2`](%AT M1&ES<&QA>2AW*3L*"5=I;F1O=R`@>%=I;F1O=R`](%AT5VEN9&]W*'2!S;R!D5]N86UE(#T@,#L*"6=L>%]I;F9O+3YX5VEN9&]W(#T@ M>%=I;F1O=SL*"@D)"0DO+R!296QE87-E(&5X8VQUPH) M=V]R:U]I9"`](%AT07!P061D5V]R:U!R;V,H87!P7V-O;G1E>'0L("A8=%=O M2D*("`@('L*"5AT4F5M M;W9E5V]R:U!R;V,H=V]R:U]I9"D["@H)"0D)+R\@268@=&AE2UW86ET M#L*("`@(&UO=7-E7WE?<&]S(#T@979E;G0M/GAB=71T;VXN M>3L*?0H*+R\@5&AIFEM+"`F87II;5]S:6XL("9A M>FEM7V-OFEM7W-I;B`J(&EN8VQ?8V]S.PH@("`@=FEE=U]P M;W-;,5T@/2!V:65W7V-E;G1EFEM7V-O MFEM.PH@("`@=FEE=U]D:7);,5T@/2!V:65W7VEN8VP["B`@ M("!V:65W7V1IPH@("`@:6YT(&YE M=U]X(#T@979E;G0M/GAM;W1I;VXN>#L*("`@(&EN="!N97=?>2`](&5V96YT M+3YX;6]T:6]N+GD["@H@("`@9FQO870@9'@@/2`H9FQO870I*&YE=U]X("T@ M;6]U%]P;W,I.PH@("`@9FQO870@9'D@/2`H9FQO870I*&YE=U]Y("T@ M;6]U5]P;W,I.PH*("`@(&UO=7-E7WA?<&]S(#T@;F5W7W@["B`@("!M M;W5S95]Y7W!O2X*("`@(&EF("A"=71T;VXQ M36%S:R`F(&5V96YT+3YX;6]T:6]N+G-T871E*0H@("`@>PH)9&ES=&%N8V4@ M*ST@+2AF86)S*&1I2`O(#$P,"XP*3L* M("`@('T*"@D)"0DO+R!2;W1A=&4@=&AE('9I97=E&UO M=&EO;BYS=&%T92D*("`@('L*"79I97=?87II;2`M/2!D>"`O(#(N,#L*"79I M97=?:6YC;"`M/2!D>2`O(#(N,#L*("`@('T*"@D)"0DO+R!4PH)9FQO870@9F]V7W@L(&9O=E]Y.PH)<&9'971# M:&%N1D]6*'1H94-H86YN96PL("9F;W9?>"P@)F9O=E]Y*3L*"@EF;&]A="!A M>FEM7W-I;BP@87II;5]C;W,["@EF;&]A="!I;F-L7W-I;BP@:6YC;%]C;W,[ M"@EP9E-I;D-OFEM7W-I;BP@)F%Z:6U?8V]S*3L* M"7!F4VEN0V]S*'9I97=?:6YC;"P@)FEN8VQ?"P@)GA?9G5D9V4L("9J=6YK*3L*"7!F4VEN0V]S*&9O=E]Y+"`F>5]F=61G M92P@)FIU;FLI.PH)>%]F=61G92`O/2`J=VEN7WA?F4["@H)=FEE=U]C96YT97);,%T@+3T*"2`@("`H87II M;5]C;W,@*B!D>"`J('A?9G5D9V4@*R!A>FEM7W-I;B`J("@M:6YC;%]S:6XI M("H@9'D@*B!Y7V9U9&=E*0H)"2H@9&ES=&%N8V4["@EV:65W7V-E;G1EFEM7W-I;B`J(&1X("H@>%]F=61G92`K(&%Z:6U?8V]S M("H@:6YC;%]S:6X@*B!D>2`J('E?9G5D9V4I"@D)*B!D:7-T86YC93L*"79I M97=?8V5N=&5R6S)=("T]"@D@("`@*"UI;F-L7V-O2`J(&1I5]F=61G93L*("`@('T*"B`@("!A9&IUF4H)B!A<'!?8V]N=&5X="P@(E!F36]T:68B+`H)"0D)(&]P=&EO M;G,L(%AT3G5M8F5R*&]P=&EO;G,I+`H)"0D)("9A4QE=F5L*%!&3D997U=!4DXI.PH@ M("`@=F]I9"`J(&%R96YA(#T@<&9'9713:&%R961!2!A%]I;F9O7W-TF5O9BAD$YG M:6YI=$-A;&QB86-K+`H)"2`@*%AT0V%L;&)A8VM0$YR97-I>F5#86QL8F%C:RP* M"0D@("A8=$-A;&QB86-K4')O8RER961R87=#0BP@,"D["B`@("!8=$%D9$5V M96YT2&%N9&QE"!B;W5N9#L*("`@('!F1V5T M3F]D94)";W@H9&%T82P@)B!B;W5N9"P@,"D["B`@("!P9E9E8S,@"D["B`@("!P9E-U8E9E8S,HF5;,ETI.PH@("`@9&ES=&%N8V4@ M/2!D:6%M971E2!F2D*>PH@("`@*G@@/2`P.PH@("`@*GD@/2`P.PI]"@IE>'1E"P@;&]N9R`J('DI"GL*("`@("IX(#T@ M*G=I;E]X7W-I>F4["B`@("`J>2`]("IW:6Y?>5]S:7IE.PI]"FEN*#0U+C`@ M+R`R("H@35]022`O(#$X,"DI.PH*("`@('!F0VAA;DYE87)&87(H=&AE0VAA M;FYE;"P@9&EA;65T97(@+R`Q,"XP+"!D:6%M971E Message-Id: <9312172121.AA06183@swlrgk> To: info-performer@sgi.sgi.com Status: O Will IRIS Performer 1.2 make stereo easier" or "automatic"? Since stereo is usually rendered in 2 separate windows, will Performer allow a straight-forward way to update these windows? Will it use specific parameters, such as offsetting objects within the scene using pitch, roll, and yaw, to cause the stereo effects? Also - I am using StereoGraphics stereo glasses. Thank you, Stephen Joyce Raytheon Co. From guest Sun Dec 19 17:55:16 1993 Message-Id: <9312200155.AA00497@surreal.asd.sgi.com> To: "Stephen Joyce {75069}" Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Fri, 17 Dec 93 16:21:46 EST." <9312172121.AA06183@swlrgk> Date: Sun, 19 Dec 93 17:55:09 -0800 From: Jim Helman Status: O Performer already supports multiple channels quite nicely. Performer 1.2 adds support for off-axis viewing frusta, which are needed for proper stereo rendering. In 1.2, pfChannels supports pfMakePerspFrust() which is like the GL window() function. You could do this under 1.0/1.1 but it was tricky to get the culling volume correct. Beyond that stereo is entirely a matter of setting up the viewing parameters. For the general case of an arbitrary eye position w.r.t. the monitor, Michael Deering's SIGGRAPH paper from 1992 is a good reference (except for its unfortunate use of PHIGS notation). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Dec 21 09:09:20 1993 From: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Message-Id: <9312211806.ZM7291@shark.paris.sgi.com> Date: Tue, 21 Dec 1993 18:06:21 +0100 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Cc: norbert@shark.paris.sgi.com Subject: Intersection beetwen bbox and nodes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi all, I have a simple question for all of us : How can i determine intersection between BBox and nodes or geoset ? In fact my question is more complex, i need to simulate a bomb explosion and i want to determine all objects that are affected by this explosion. Of course explosion area is a sphere. Any idea ? Thanks for your help. Norbert. -- +----------------------------------------------------------------+ | NN NN BBBBBB Country ID : IFR-340 | | NNN NN BB BB SGI Office Location : PARIS | | NNNN NN BBBBBB Name : Norbert BIANCHIN | | NN NNNN BB BB | | NN NNN BB BB E-mail Address : norbert@paris.sgi.com | | NN NN BBBBBB Fax Number : 33 1 34 88 80 76 | +----------------------------------------------------------------+ From guest Tue Dec 21 09:51:33 1993 Message-Id: <9312211751.AA23000@surreal.asd.sgi.com> To: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Cc: info-performer@sgi.sgi.com Subject: Re: Intersection beetwen bbox and nodes In-Reply-To: Your message of "Tue, 21 Dec 93 18:06:21 +0100." <9312211806.ZM7291@shark.paris.sgi.com> Date: Tue, 21 Dec 93 09:51:20 -0800 From: Jim Helman Status: O Determining all objects which are in or impinge upon a sphere is really a volume-volume intersection problem. You could create a spherical bristle of segments, but it would take a lot of them, probably too many, to give good coverage. Volume-volume intersections are on the list of things for a future release. However, since all the bounding and transform information is accessible, a user could always traverse the scene graph yourself and carry out the tests. If this is too much work, you can narrow things down quite a bit by using a bounding cylinder in pfSegsIsectNode() without any segments and specify a discriminator callback and PFTRAV_IS_GEODE in the mdoe. This will give you callbacks on all the pfGeodes whose bounding spheres potentially intersect the querying bounding cylinder. You could then test the pfGeoSets in the pfGeode more easily since you have the transformation in the pfIsect (pfHit in 1.2) structure handed to your discriminator. Then test the explosion sphere aginst the bounding box transformed by pfXformBox(). Currently, bounding cylinder testing is implemented only down to pfGeodes, but getting it down to the pfGeoSet level is currently has been mentioned as a must fix for 1.2. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From seppo@vision3d.helsinki.sgi.com Wed Dec 22 08:37:43 1993 From: "Seppo_Jarimo" Message-Id: <9312221835.ZM25975@vision3d.helsinki.sgi.com> Date: Wed, 22 Dec 1993 18:35:14 +0200 X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer Fatal (9): Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, Is this a known bug in Performer 1.1 ?: When trying to run Town or Village demo in an Onyx with 2GB memory and several GB's swap, one gets a message: Performer Fatal (9):pfInit: not enough space in swap, need 4096KB plus headroom, only found -2015150080KB Notice the "-" sign in front of the found swap space. Thanks, - Seppo Jarimo -- seppo@sgi.fi or seppo@helsinki.sgi.com Silicon Graphics Oy Tel: +358-0-4354 2071 Innopoli, Tekniikantie 12 Fax: +358-0-4354 3200 SF-02150 ESPOO SGI-mailstop: IFI-361 Finland From guest Wed Dec 22 08:37:48 1993 Date: Wed, 22 Dec 93 08:37:48 -0800 From: guest (Guest Account) Message-Id: <9312221637.AA01678@holodeck.asd.sgi.com> Apparently-To: info-performer-dist Status: O From guest Thu Dec 23 03:13:50 1993 Date: Thu, 23 Dec 93 03:13:50 -0800 From: guest (Guest Account) Message-Id: <9312231113.AA06650@holodeck.asd.sgi.com> Apparently-To: info-performer-dist Status: O From seppo@vision3d.helsinki.sgi.com Thu Dec 23 03:13:49 1993 From: "Seppo_Jarimo" Message-Id: <9312231316.ZM791@vision3d.helsinki.sgi.com> Date: Thu, 23 Dec 1993 13:16:45 +0200 In-Reply-To: Jim Helman "Re: Performer Fatal (9):" (Dec 22, 11:03am) References: <9312221903.AA01453@surreal.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: jimh@surreal Subject: Re: Performer Fatal (9): Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Jim, Thanks for your quick response. PFTMPDIR had nothing to do with it, but deleting the third swap file seen in the swap -l list below helped. So it is a kind of counter overflow type of bug. Merry Christmas, - Seppo Jarimo cypress 1% /etc/swap -l lswap path dev pri swaplo blocks free maxswap vswap 2 /var/tmp/.swap.virtual 128,278 2 0 0 0 0 80000 1 /dev/swap 128,273 0 0 524288 524288 524288 524288 3 /dev/dsk/dks4d4s1 128,1089 0 0 3928480 3928480 3928480 3928480 cypress 2% On Dec 22, 11:03am, Jim Helman wrote: > Subject: Re: Performer Fatal (9): > You should be able to run the town demo by setting PFTMPDIR > to /usr/tmp (or another temporary directory with 20-30MB > free). > > If the 2GB machine is being used for real Performer > development, I'd suggest getting Performer 1.2 as soon as > it's released. Or 1.2a72 if the user is SGI internal or a > customer you closely support. More test coverage on huge > machines would be nice. > > We don't have one that big, and as far as I know 1.1 was > never tested on a large system. Your message probably > indicates that a long is wrapping and the space allocation > is getting confused. Can you send the output of 'swap -l'? > > > rgds, > > -jim helman > > jimh@surreal.asd.sgi.com > 415/390-1151 > >-- End of excerpt from Jim Helman -- seppo@sgi.fi or seppo@helsinki.sgi.com Silicon Graphics Oy Tel: +358-0-4354 2071 Innopoli, Tekniikantie 12 Fax: +358-0-4354 3200 SF-02150 ESPOO SGI-mailstop: IFI-361 Finland From aschaffe Thu Dec 23 10:59:14 1993 Date: Thu, 23 Dec 93 10:59:14 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9312231859.AA07809@holodeck.asd.sgi.com> Apparently-To: info-performer-dist Status: O From aschaffe Thu Dec 23 10:59:14 1993 Date: Thu, 23 Dec 93 10:59:14 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9312231859.AA07806@holodeck.asd.sgi.com> To: info-performer Subject: Administrivia: Gone Fishin' Status: O Hello info-performer subscribers, Happy Holidays from the IRIS Performer group! I'll be out until January 4th and only occasionally checking email, so messages sent to info-performer-request may not be handled at the usual 30Hz. In my absence, the indomitable Jim Helman will keep an eye out for urgent administrative requests. You'll all be happy to know that a few of my new year's resolutions are to.. - update the Performer FAQ list again - make archives of info-performer available via ftp and of course, - write some more code samples for Performer 1.2 Happy hacking, Allan ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From jimh@surreal Thu Dec 23 11:19:19 1993 Message-Id: <9312231919.AA09953@surreal.asd.sgi.com> To: "Seppo_Jarimo" Cc: info-performer@sgi.sgi.com Subject: Re: Performer Fatal (9): In-Reply-To: Your message of "Thu, 23 Dec 93 13:16:45 +0200." <9312231316.ZM791@vision3d.helsinki.sgi.com> Date: Thu, 23 Dec 93 11:19:07 -0800 From: Jim Helman Status: O The problem was probably more than 2GB of swap. Either decreasing swap below 2GB or setting PFTMPDIR (which bypasses the entire swap allocation issue) should fix it under 1.1. The entire problem was created when IRIX 5.0 went to a strict memory reservation system which reserves sufficient swap even for unused portions of mmaps. Performer currently needs a single contiguous memory allocation. Usually, people who bought 1-2GB systems for Performer want to use as much as possible of it as shared memory, but we also don't want to completely lock out other programs. Hence the take half of everything compromise in 1.1. With 1.2 (release version, not in the betas) under IRIX 5.2 the problem goes away, because we're back to allocation on demand without reservation of the original mmap (MAP_AUTORESRV to mmap). 1.2 also has a routine pfSharedArenaSize to explicitly specify the desired size of the Performer shared memory mmap, but with of the AUTORESRV fix to IRIX, this shouldn't be required except on pre-5.2 systems or beta versions of 1.2. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 23 11:38:38 1993 Date: Thu, 23 Dec 93 11:19:20 -0800 From: guest (Guest Account) Message-Id: <9312231919.AA07941@holodeck.asd.sgi.com> Apparently-To: info-performer-dist Status: O From guest Mon Dec 27 07:39:25 1993 id AA18498; Mon, 27 Dec 93 10:38:31 -0500 Date: Mon, 27 Dec 93 10:38:29 -0500 From: bfl@cs.duke.edu (Brian Loss) Message-Id: <9312271538.AA15926@majors7.cs.duke.edu> To: info-performer@sgi.sgi.com Subject: Problem with GL calls in Performer 1.2 Status: O I am porting an application from Performer 1.0 to Performer 1.2 and have run into a slight problem. There is some code which draws a title screen which includes a title and a status bar indicating how much of a load has been completed. My problem is that the status bar does not show up properly. I draw it by drawing a closed line and then a rectangle. The code to draw the closed line works, but the code to draw the rectangle does not. Has anyone encountered such a problem. Here is some code: TPerfApp::DoTitle( const char *str, float status_bar ) { Matrix m; int xo, yo, xs, ys, nidX, midY; Boolean zstatus; float v[2]; // Figure out the center of the window pfGetPipeOrigin( fPipe, (long *) &xo, (long *) &yo ); pfGetPipeSize( fPipe, (long *) &xs, (long *) &ys ); midX = (xs / 2) + xo; midY = (ys / 2) + yo; // Save the projection and viewing matrices zstatus = getzbuffer( ); zbuffer( FALSE ); mmode( MPROJECTION ); getmatrix( m ); ortho2( xo, xs, yo, ys ); mmode( MVIEWING ); pfPushIdentMatrix( ); cpack( TTLBKGD ); clear( ); cpack( TTLFRGD ); fFonti24->Center( /* Print Title here */, midY + 200, midX ); ); if (str) fFonti24->Center( str, midY - 180, midX ); if (status_bar >= 0.0f) { cpack( 0xff0000ff ); v[0] = 425.0f; v[1] = 150.0f; bgnclosedline( ); v2f( v ); v[1] += 25.0f; v2f( v ); v[0] += 425.0f; v2f( v) ; v[1] -= 25.0f; v2f( v ); endclosedline( ); v[0] = 425.0f; v[1] = 150.0f; bgnpolygon( ); v2f( v ); v[1] += 25.0f; v2f( v ); v[0] += status_bar*425.0f; v2f( v ); v[1] -= 25.0f; v2f( v ); endpolygon( ); } swapbuffers( ); // Restore old projection and viewing matrices pfPopMatrix( ); mmode( MPROJECTION ); loadmatrix( m ); mmode( MVIEWING ); zbuffer( zstatus ); } // end DoTitle So, the code for the title and closed line work fine, but the code for the polygon does not work. I'm confused. I also tried a tmesh instead of a polygon and that didn't work either. Any help on this would be appreciated. aTdHvAaNnKcSe. Brian Loss _________________________________________________________________ Department of Computer Science, Duke University, Durham, NC 27706 Internet: bfl@cs.duke.edu UUCP: mcnc!duke!bfl _________________________________________________________________ From guest Tue Dec 28 06:22:49 1993 From: fouts@exacto.atlanta.sgi.com (Christopher Fouts) Message-Id: <9312280924.ZM866@exacto.atlanta.sgi.com> Date: Tue, 28 Dec 1993 09:24:20 -0500 In-Reply-To: bfl@cs.duke.edu (Brian Loss) "Problem with GL calls in Performer 1.2" (Dec 27, 10:38am) References: <9312271538.AA15926@majors7.cs.duke.edu> X-Face: YhB-P`"=w`PpC"Q\U50c{z,f1=9dickD?tmOz_y7x6ah0"98IIE9`Gs~)vRkgY8r^E*yXza*yz"zNNj_o7S)^E{7gO!dD Subject: Problem with GL calls in Performer 1.2 | | v[0] = 425.0f; v[1] = 150.0f; | bgnpolygon( ); | v2f( v ); v[1] += 25.0f; | v2f( v ); v[0] += status_bar*425.0f; | v2f( v ); v[1] -= 25.0f; | v2f( v ); | endpolygon( ); | } This polygon is backfaced. Try calling backface(FALSE) or reversing the order of the vertices. Evidently the GL initialization changed in 1.2 for I experienced a similar problem. -- Chris Fouts Email: fouts@atlanta.sgi.com Systems Engineer Phone: (404)-392-1333 Silicon Graphics Computer Systems Vmail: 5-8714 Atlanta, GA "What you see is real. What you smell is unfortunate." Tom Servo, Mystery Science Theatre 3000 From guest Tue Dec 28 08:18:21 1993 Date: Tue, 28 Dec 93 08:17:56 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9312281617.AA25792@tubes.asd.sgi.com> To: fouts@exacto.atlanta.sgi.com (Christopher Fouts), info-performer@sgi.sgi.com, bfl@cs.duke.edu (Brian Loss) Subject: Re: Problem with GL calls in Performer 1.2 References: <9312271538.AA15926@majors7.cs.duke.edu> Status: O >Evidently the GL initialization changed in 1.2 This is correct. We decided to go for speed at all costs since backface elimination can make a big difference. From guest Tue Dec 28 10:14:40 1993 id AA11270; Tue, 28 Dec 93 13:18:06 -0500 Date: Tue, 28 Dec 93 13:18:05 -0500 From: bfl@cs.duke.edu (Brian Loss) Message-Id: <9312281818.AA16435@majors7.cs.duke.edu> To: info-performer@sgi.sgi.com Subject: Re: Problem with GL calls in Performer 1.2 Status: O > From fouts@exacto.atlanta.sgi.com Tue Dec 28 09:23:37 1993 > Content-Type: text/plain; charset=us-ascii > Mime-Version: 1.0 > > Subject: Problem with GL calls in Performer 1.2 > | > | v[0] = 425.0f; v[1] = 150.0f; > | bgnpolygon( ); > | v2f( v ); v[1] += 25.0f; > | v2f( v ); v[0] += status_bar*425.0f; > | v2f( v ); v[1] -= 25.0f; > | v2f( v ); > | endpolygon( ); > | } > > This polygon is backfaced. Try calling backface(FALSE) or reversing the > order of the vertices. Evidently the GL initialization changed in 1.2 for > I experienced a similar problem. > > > -- > > Chris Fouts Email: fouts@atlanta.sgi.com > Systems Engineer Phone: (404)-392-1333 > Silicon Graphics Computer Systems Vmail: 5-8714 > Atlanta, GA > > "What you see is real. What you smell is unfortunate." > > Tom Servo, Mystery Science Theatre 3000 > > > > I totally missed that. Thanks. However, in my program's initizaliation, I make the following calls: pfCullFace( PFCF_OFF ); pfOverride( PFSTATE_CULLFACE, PF_ON ); and they did not seem to solve the problem (I don't call pfOverride with PFSTATE_CULLFACE again). However, when I made the vertices of my polygon in counterclockwise order, it shows up. Am I using pfOverride incorrectly? Brian Loss _________________________________________________________________ Department of Computer Science, Duke University, Durham, NC 27706 Internet: bfl@cs.duke.edu UUCP: mcnc!duke!bfl _________________________________________________________________ From guest Tue Dec 28 10:57:01 1993 Date: Tue, 28 Dec 93 10:56:00 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9312281856.AA26017@tubes.asd.sgi.com> To: bfl@cs.duke.edu (Brian Loss), info-performer@sgi.sgi.com Subject: Re: Problem with GL calls in Performer 1.2 Status: O >I totally missed that. Thanks. However, in my program's initizaliation, I >make the following calls: > > pfCullFace( PFCF_OFF ); > pfOverride( PFSTATE_CULLFACE, PF_ON ); > >and they did not seem to solve the problem (I don't call pfOverride with >PFSTATE_CULLFACE again). However, when I made the vertices of my polygon in >counterclockwise order, it shows up. Am I using pfOverride incorrectly? > This is the correct usage of pfOverride and should definitely work. Are you calling this in your pipe initialization function (pfInitPipe)? How about a code fragment or a gldebug trace?