From guest Tue Feb 1 14:51:35 1994 From: m218822@fltsim.MDC.COM (Bill Balloni) Message-Id: <9402012144.AA03862@fltsim.MDC.COM> Subject: Dynamic Database Loading/Paging. To: info-performer@sgi.sgi.com Date: Tue, 1 Feb 1994 15:44:34 -0600 (CST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1173 Status: O I am interested in the subject of loading a database for rendering by Performer in a "demand paged" fashion. I have limited experience with Performer but realize that database loading can be controlled at the user's application level (as opposed to other visual packages). I anticipate needing to deal with databases that are 1GB and over in size. Obviously, the memory required for this database is prohibitive (and damned expensive!). I envision being able to keep a region of the database (say all data within a 20km radius) in memory. The rest would remain on the disk. As is needed, data would be read from disk in a demand paged manner. This would allow smaller memory sizes but (probably) require significant application complexity to support. Has anyone addressed this problem? What are the hows and whys regarding this approach ("don't bother" may be the majority response but I hope not). If you have some information or an opinion I would love to here from you. Thanks, Bill Balloni McDonnell Douglas Aerospace St. Louis, MO Flight Simulation Facility email: balloni@fltsim.MDC.COM From guest Tue Feb 1 14:14:40 1994 Return-Path: From: abramsh@maestro.MITRE.ORG (Howard Abrams) Message-Id: <9402011714.ZM15902@maestro> Date: Tue, 1 Feb 1994 17:14:08 -0500 X-Mailer: Z-Mail (2.1.0 10/27/92) To: info-performer@sgi.sgi.com Subject: Snow/Rain Cc: plevy@maestro.mitre.org Status: O I was planing on creating a snow/rain effect on performer. Has anyone had any success in doing this? I had planed on making several texture mapped polygons, and moving the texture or polygons to animate the snow/rain. Does anyone know if this would be a good approach, and if so, can I move the texture instead of the polygon? Also, I had heard that 1.2 will have smoke and dust effects. Will it also have rain? --Howard From guest Tue Feb 1 18:09:34 1994 Date: Tue, 1 Feb 1994 18:07:58 -0800 (PST) From: Michael Macedonia Subject: Re: Dynamic Database Loading/Paging. To: Bill Balloni Cc: info-performer@sgi.sgi.com, dave pratt In-Reply-To: <9402012144.AA03862@fltsim.MDC.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 1 Feb 1994, Bill Balloni wrote: > > Has anyone addressed this problem? What are the hows and whys regarding > this approach ("don't bother" may be the majority response but I hope not). > If you have some information or an opinion I would love to here from you. > > Thanks, > > Bill Balloni McDonnell Douglas Aerospace St. Louis, MO > Flight Simulation Facility > email: balloni@fltsim.MDC.COM Contact Dr. Dave Pratt at pratt@cs.nps.navy.mil. He addressed this problem already in NPSNET. Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From guest Wed Feb 2 06:08:25 1994 Date: Wed, 2 Feb 94 09:06:27 EST From: elkins@degas.nswc.navy.mil (Les Elkins b40 x43850) Message-Id: <9402021406.AA01668@degas.nswc.navy.mil> To: info-performer@sgi.sgi.com Subject: Color changes Status: O Hello... I'm in the process of learning how to use Performer, and to that end have written a loader to read some 3D objects I've had lying around on a disk. The loader reads the files and constructs GeoStates based on the materials data, then reads each polygon into a GeoSet, then ties the appropriate GeoState to it. I then set the color of each geoset to white, stick all of the geosets in a file under a single pfGroup, add these to a scene, and things seem to work fine. However, when I load a .flt file into the same scene and add it into the scene graph, the objects read by my loader sometimes turn grey or black. Most often, but not always, this happens when the object from the .flt file changes LOD (I'm usually loading in esprit.flt). The object read by the .flt loader, of course, looks fine... I've looked into the flight loader source, but don't see any 'smoking guns' pointing to things I might be stepping on. I'm probably not initializing something correctly in my ignorance, but could someone give me any hints as to what to look for? I'm running Performer 1.0 on a Crimson w/VGXT, under IRIX 4.0.5J. If more info is needed to give a diagnosis, please let me know. Thanks in advance, Les Elkins elkins@degas.nswc.navy.mil From guest Wed Feb 2 09:39:45 1994 From: "Marc SIMON Presales support" Message-Id: <9402021857.ZM814@girl.paris.sgi.com> Date: Wed, 2 Feb 1994 18:57:15 +0100 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Questions about Perf1.2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I have some questions about features of GL vs PERFORMER. - Is there a way in Performer to manage pagination of texture like in GL . - For managing the pfLayer i read that Perf1.2 uses DisplacePolygon, but if i well remember displace polygon modify the Z value of a polygon by a factor calculated by the use of the polygon orientation, and this factor is 0.0 if the polygon as its normal oriented direct to the viewer.So for coplanar polygon in front of the viewer it will no works fine Is'it right ??? Is there a way to avoid this ??? - Is there a way to store informations on every nodes of the hierarchy ?? - I heard that Performer sorts the polygons before the drawing to optimise the graphics (Especially mode transitions).But what kind of sorting Performer uses .. Is it only to group polygons with the same textures to avoid Texbind ??? - My last question is not especially for Performer guys, in fact it seems that the GL call "msmask()" is very slow . Is it right ??? Thanks in advance smarc@paris.sgi.com Marc SIMON From guest Wed Feb 2 10:48:58 1994 From: renee@pat.mdc.com Message-Id: <9402021848.AA01883@pat.mdc.com> Subject: pfLights To: info-performer@sgi.sgi.com Date: Wed, 2 Feb 94 12:48:25 CST X-Mailer: ELM [version 2.3 PL11] Status: O I have Performer 1.0. In the documentation pfLightPos needs an x, y, z and w but w is not defined. Is W supposed to be 0.0 for infinte and 1.0 for a local light? When is Performer 1.2 going to be available????? Renee Strong renee@pat.mdc.com From guest Wed Feb 2 11:57:11 1994 Message-Id: <9402021955.AA05477@sgi.sgi.com> Date: 2 Feb 94 14:01:00 EST From: "Scott Davidson" Subject: 1.0 to 1.1 compatability To: "info-performer" Status: O We're working with the University of Pennsylvania to build a Performer loader of Peabody geometry. The loader is fairly basic but we're concerned about loader compatability between Performer 1.0 and 1.1. Are there any show-stoppers between 1.1 and 1.0 that we should be worried about. Thanks, Scott Davidson NAWCTSD From guest Wed Feb 2 12:16:56 1994 Date: Wed, 2 Feb 94 15:14:54 -0500 From: pnc@viminal.me.psu.edu (Pramod N. Chivate) Message-Id: <9402022014.AA18046@viminal.me.psu.edu> To: info-performer Status: O how can i remove my name from IRIS Performer mailing list? ______________________________________________________________________ Pramod N. Chivate 743 Southgate Drive 241 Mechanical Engg. Bldg. State College, PA 16801. Penn State University (814) 867-2137 University park, PA 16802. Fax: (814) 863-4848 E-mail: pnc@me.psu.edu > Learning is finding out what you already know. Doing is demonstrating > that you know it. Teaching is reminding others that they know just > as well as you. We are all learners, doers and teachers. From guest Wed Feb 2 13:12:57 1994 Message-Id: <9402022112.AA01988@surreal.asd.sgi.com> To: "Scott Davidson" Cc: "info-performer" Subject: Re: 1.0 to 1.1 compatability In-Reply-To: Your message of "02 Feb 94 14:01:00 EST." <9402021955.AA05477@sgi.sgi.com> Date: Wed, 02 Feb 94 13:12:54 -0800 From: Jim Helman Status: O > Are there any show-stoppers between 1.1 and 1.0 that we should be > worried about. 1.0 and 1.1 are identical in terms of API and functionality, except for the following bug fixes listed in the release notes. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 What follows is a brief description of bugs that were found in IRIS Performer 1.0 and fixed in 1.1. This chapter lists the problems with the IRIS Performer libraries, libpr and libpf, and with the shared memory configurations. "libpr" Floating point exceptions can cause severe and mysterious performance degradation. pfNotifyLevel levels of PFNFY_DEBUG and PFNFY_INFO enable floating point exceptions so the application is alerted to this potentially disastrous situation. In 1.0, underflows were not trapped and consequently caused some problems. In 1.1, underflows are trapped. pfFilePath would exit with a FATAL error if it was called twice. Applying a back-sided material which had a color mode (pfMtlColorMode), would set the GL lmcolor mode. Since IrisGL does not support lmcolor for back-sided materials, this could have caused front-sided materials to use an improper lmcolor mode. Intersection caching for non-indexed quads was broken and could case a core dump when intersection with pfGeoSets of this type. pfGetCurState returned a pfGeoState which was the top of the state stack rather than the current pfState. pfGetCurGState returned a pfGeoState which was the top of the state stack rather than the most recently applied pfGeoState. "libpf" Perhaps the most heinous bug in 1.0, pfInitGfx on RealityEngines would call lsetdepth(0x0, 0x0), essentially disabling zbuffering. combinLODs() in the MultiGen .flt converter (in file hier.c) did not set the LOD center of combined LODs. This would result in strange LOD behavior for LODs which were not modelled about the origin. pfClone()'ed pfSequences were not updated by pfFrame so they essentially did not work. Intersections with pfSequences could sometimes turn them off (PFSEQ_STOP). collide.c was shipped with a hardwired intersection mode which turned off intersection caching, substantially reducing intersection performance. pfFlatten()'ed pfLightPoints were broken for multiprocessing modes when the application and cull processes were separate. From guest Wed Feb 2 13:13:04 1994 From: "Michael Jones" Message-Id: <9402021313.ZM2054@babar.asd.sgi.com> Date: Wed, 2 Feb 1994 13:13:02 -0800 In-Reply-To: "Scott Davidson" "1.0 to 1.1 compatability" (Feb 2, 2:01pm) References: <9402021955.AA05477@sgi.sgi.com> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: "Scott Davidson" , "info-performer" Subject: Re: 1.0 to 1.1 compatability Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 2, 2:01pm, Scott Davidson wrote: > Subject: 1.0 to 1.1 compatability :We're working with the University of Pennsylvania to build a Performer :loader of Peabody geometry. This "Peabody" is a file format? (or is it Mr. Peabody of Sherman and Peabody fame ;-) :The loader is fairly basic but we're :concerned about loader compatability between Performer 1.0 and 1.1. :Are there any show-stoppers between 1.1 and 1.0 that we should be :worried about. There were no changes of note between 1.0 and 1.1; certainly none that would effect geometry. -- 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 Feb 2 21:36:24 1994 Date: Thu, 3 Feb 94 00:39:03 -0500 From: hildebra@flash.vsl.ist.ucf.edu (Andrew Hildebrand ) Message-Id: <9402030539.AA12921@flash.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: HMD and FASTRACK Status: O Does anyone or has anyone used an HMD or the Polhemus Fastrack in a Performer simulation. If so, how did you do it. If you have code, that would be great, if you cannot, or do not want to release it, some hints would be greatly appreciated..... THNAKS ______________________________________________________________________________ Andrew Hildebrand The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) hildebra@vsl.ist.ucf.edu _______________________________________________________________________________ From guest Thu Feb 3 02:22:31 1994 Date: Thu, 3 Feb 94 02:23:54 -0800 From: goetzjr@gravy3.cs.nps.navy.mil (john goetz) Message-Id: <9402031023.AA20662@gravy3.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: pfCylinders Status: O I am trying to model circular foot pads on uneven terrain. I create several segments extending from the bottom of the foot pad, all of which are long enough to always intersect with the ground. I then call: pfCylAroundSegs(cyl, segment, nsegs); and change the parameters of the pfCylinder as follows: pfSetVec3(cyl->center, foot_data[leg].foot_xyz[2], foot_data[leg].foot_xyz[0], foot_data[leg].foot_xyz[1]); // conversion from GL coordinates cyl->halfLength = 3.0f; cyl->radius = 22.5f; The halfLength puts the end of the pfCylinder at the bottom of the foot pad. I then perform the intersection testing: /* find intersection with terrain */ isect = pfSegsIsectNode(G_dirt, segment, nsegs, PFTRAV_IS_PRIM| PFTRAV_IS_CULL_BACK|PFTRAV_IS_NORM, TERRAIN_MASK, cyl, result, NULL); hoping that the pfCylinder will tell me when the foot pad touches the ground, then using the "result" data to contour the foot pad to the ground. When contact was detected the data was as follows: ground height 0.50 cyl center 195.424 -109.000 12.585 cyl axis 0.000 0.000 -1.000 cyl radius 22.500 cyl halflength 3.000 The bottom of the pfCylinder should be at 9.585 which should not be intersecting with the ground yet. Can somebody please explain? Thank You. John Goetz goetzjr@cs.nps.navy.mil From guest Thu Feb 3 01:38:29 1994 From: "Ran Yakir" Message-Id: <9402031137.ZM5750@amcor.bvr.co.il> Date: Thu, 3 Feb 1994 11:37:10 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: 1.2 bug in pfESkyMode Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi ! It seems like there is a bug (feature ?) in pfESkyMode, When using the clear mode PFES_SKY_CLEAR. PFES_SKY_CLEAR sould draw sky AND clear the bottom part of the viewport. Instead, it just draws the sky, thus behaving like PFES_SKY. Bye Ran Yakir From guest Thu Feb 3 09:58:46 1994 Message-Id: <9402031758.AA14808@surreal.asd.sgi.com> Date: Thu, 3 Feb 94 10:18:28 EST From: mwilliam@ldsa.com (Micheal J. Williams) Subject: Static backgrounds (fwd for mwilliam@ldsa.com) To: info-performer@sgi.sgi.com Status: O I need to know if there is a way to draw static background with GL and let Performer handle moving models without requiring me to redraw the background every frame. I have a dataset composed of evenly spaced elevation posts. I display this elevation data as either wire frame, or shaded polgons during the draw callback. I load flight format models into Performer, and let it manage those. Currently, I am redisplaying my terrain with each frame. The dataset is 500x500 posts, and this display is taking most of my time. I was hoping to find some way of drawing this terrain only once (since it does not move reletive to the eyepoint), but have just the models redrawn every frame. I originally wanted to load the terrain matrix into either a geoset, or geode but I had very little luck doing so. I am working on an Indigo2 Extreme running Performer 1.0. I am writing my code in Ada (serious pain), but I would actually prefer replies using 'C'. Thanks Mike Williams mwilliam@ldsa.com From guest Thu Feb 3 10:21:28 1994 From: "Craig Phillips" Message-Id: <9402031102.ZM17362@binky.paradigmsim.com> Date: Thu, 3 Feb 1994 11:02:36 -0600 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: light points Cc: vick@binky.paradigmsim.com, vega@spiffy.paradigmsim.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O there is no api for getting the number of lights in a pfLightPoint. I haven't tried pfGetNumChildren, but that doesn't seem like it should work. Also, the lightpoint is created specifing the maximum number of lights. there is nothing in the man page about adding, deleting or turning off a light point. whats the condition that makes a light active or inactive? -- __________________________________________________ Craig Phillips Paradigm Simulation Inc. craig@paradigmsim.com 214-960-2301 __________________________________________________ From guest Thu Feb 3 10:19:53 1994 From: renee@pat.mdc.com Message-Id: <9402031819.AA05999@pat.mdc.com> Subject: light help To: info-performer@sgi.sgi.com Date: Thu, 3 Feb 94 12:19:45 CST X-Mailer: ELM [version 2.3 PL11] Status: O What am I doing wrong here? I'm running Performer 1.0 on a PI. I modified the light code from simple.c. My lights, Sun1 and Sun2, only show up if the fourth argument is 1.0. I thought that would make them local lights. And the position doesn't seem to matter one bit. Both lights seem to be coming from the same spot so the colors are blending together. I've tried normalizing the position vector and it didn't make any difference. I tried using the exact light code that's in simple.c and the sun only showed up when I set the fourth argument to 1.0. Thanks Renee Strong renee@pat.mdc.com void *arena; static void OpenPipeline (pfPipe *p) { pfLight *Sun1, *Sun2; pfLightModel *lmodel; /* negotiate with window-manager */ foreground(); prefposition(100,500,100,500); winopen("IRIS Performer"); /* negotiate with GL */ pfInitGfx(p); arena = pfGetSharedArena(); /* create light sources */ Sun1 = pfNewLight(arena); //pfLightPos(Sun1, -0.979367, 0.202079, -0.001943, 1.0f); pfLightPos(Sun1, -151.209320, 31.200001, -0.300000, 1.0f); pfLightColor(Sun1, 0.0, 1.0, 0.0); pfLightAmbient(Sun1, 0.0, 0.0, 0.0); Sun2 = pfNewLight(arena); //pfLightPos(Sun2, 0.001904, -0.013963, -0.999901, 1.0f); pfLightPos(Sun2, 0.300000, -2.200000, -157.548874, 1.0f); pfLightColor(Sun2, 1.0, 0.0, 0.0); pfLightAmbient(Sun2, 0.0, 0.0, 0.0); /* create a default lighting model */ lmodel = pfNewLModel(arena); pfLModelAmbient(lmodel, 0.2, 0.2, 0.2); pfApplyLModel(lmodel); pfLightOn(Sun1); pfLightOn(Sun2); cout << "curently active lights: " << pfGetCurLights(lights) << "\n"; pfCullFace(PFCF_BACK); } From guest Thu Feb 3 12:29:52 1994 From: "Chris Mumford" Message-Id: <9402031308.ZM1950@vino.paradigmsim.com> Date: Thu, 3 Feb 1994 13:08:59 -0600 X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O unsubscribe -- Chris Mumford Paradigm Simulation, Inc. 15280 Addison Rd. Suite 360 Dallas, TX 75248 USA (214) 960-2301 ( Voice ) (214) 960-2303 ( FAX ) chris@paradigmsim.com From guest Fri Feb 4 00:11:10 1994 Return-Path: Message-Id: <9402040602.AA07986@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Subject: Re: Performer 1.2 and Softimage In-Reply-To: Your message of "Thu, 20 Jan 1994 14:57:18 PST." <9401201457.ZM18105@babar.asd.sgi.com> Cc: hasimoto@iml.mkhar.sharp.co.jp Date: Fri, 04 Feb 1994 15:02:29 +0900 From: Takeshi Hashimoto Status: O Oh... I've read just now the mails about Softimage.... We are using Softimage and Performer. I made simple Softimage loader to Performer, by modifying Softimage DKit. It can read only triangulated meshes. I think reading triangulated mesh data is easy, but reading texture,material and animation data is difficult. Anyone who are interested in reading Softimage datas to Performer, please mail me or this mailing list. I want more information to make the loader powerful. --- //\\ (O O) \o/ hasimoto@iml.mkhar.sharp.co.jp WOW From guest Fri Feb 4 00:45:22 1994 From: "Dennis Pierce" Message-Id: <9402040344.ZM21670@sgimco.orlando.sgi.com> Date: Fri, 4 Feb 1994 03:44:54 -0500 In-Reply-To: abramsh@maestro.MITRE.ORG (Howard Abrams) "Snow/Rain" (Feb 1, 5:14pm) References: <9402011714.ZM15902@maestro> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: abramsh@maestro.MITRE.ORG (Howard Abrams), info-performer@sgi.sgi.com Subject: Re: Snow/Rain Cc: plevy@maestro.mitre.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 1, 5:14pm, Howard Abrams wrote: > Subject: Snow/Rain > > I was planing on creating a snow/rain effect on performer. Has >anyone had any success in doing this? I had planed on making several >texture mapped polygons, and moving the texture or polygons to animate >the snow/rain. Does anyone know if this would be a good approach, and if >so, can I move the texture instead of the polygon? > > Also, I had heard that 1.2 will have smoke and dust effects. Will >it also have rain? > >--Howard > >-- End of excerpt from Howard Abrams let's talk... I built this function into an IG in a former life and since we never patented the approach, it's now yours... the main issue with rain is that unless its really heavy, at night, or you're looking through binoculars, rain is pretty much invisible - not so for snow unless you're in whiteout conditions so, the basic issue is to present enough of an illusion to fool the eye into thinking that it is seeing some obstruction - this means that very muted colors should be used for rain and snow the approach taken was to place pseudorandom numbers into a top array and side array, and to draw some occulting object where the row, column indicated that the object should be drawn - each frame, the rows are marched downward by shifting a starting index into the column, and the columns can be shifted sideways (for blowing rain or snow) by shifting the starting index into the top row - this approach takes absolutely trivial storage (two linear arrays) and works amazingly well now, the speed with which the rows are shifted gives the speed of the rain - likewise for the blowing rain side shifts - plus, you can "dance" the rain or snow by shifting both directions in the row the number pattern and interpretation of this pattern gives the density of the rain or snow - I used 1's and 0's as the numeric values, but you could expand the approach with higher valued digits and build feathered edge objects by building some sort of guassian ramp at various points in the arrays hard rain is set by something like the following: 0 0 0 1 0 0 1 1 0 0 0 1 0 0 1 1 1 0 0 if you interpret this to mean that every 1,1 is drawn, the resulting pattern is something like 1 1 1 1 1 1 1 1 1 1 1 1 which, when moved at the correct vertical velocity (which is controlled by the amount you change the column offset with each frame), gives a nice set of streaks moving down the screen snow is less streaky, and, possibly, wider - definately slower if you use numbers other than 0 and 1, you can intepret the addition range as colors and have light and dim drops or flakes as I said earlier, the real magic here is the correct generation of the row and column values, and the speed at which the items move on the screen as for implementation, the overlay planes are good, but instead of clearing the entire plane, just erase the current pattern and draw the new pattern during the vertical retrace interval - if you're doing the entire screen, there may not be enough time in the 1.7 ms to accomplish this, so you may be forced into doing that double buffer thing couple this with a few wider blobs and you've got a pretty convincing windshield I've been wanting to put this into practice but just have not had the time to play the way I should - maybe soon I know this is skeletal, but if it seems like something that will help and if you want to pursue it further, let me know and I'll be more than happy to cobble a quickie or just present better details seeee ya... -- Dennis Pierce, SGI, 900 Winderley Place, Ste 130, Maitland, FL 32751 email: dpierce@sgi.com vmail: 8548 tel : 407.660.0073 late : 407.660.2789 fax : 407.660.8981 cell : 407.256.8447 From guest Fri Feb 4 08:32:10 1994 Date: Fri, 4 Feb 94 11:33:51 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9402041633.AA01738@cae.ca> To: info-performer@sgi.sgi.com Subject: Perf. 1.0 memory usage Status: O Somebody just pointed out to me that my Performer 1.0 application appears to have a size of about 70,000 pages (that's 280 Mb!) according to the ps and top commands. That is very interesting (and potentially dangerous) since the machine it is running on only has 128 Mb of combined physical and virtual memory. In real life, the program never seems to actually use more than 15 to 20 Mb. The memory appears to get reserved when I call pfInit(). Does Performer need to reserve that much memory? Is there a chance that it might try to actually use it and run out of swap space? Is there a way to control Performer's appetite so that the other users of the computer won't freak out when they look at my processes? ---------------------------------------------------------- jfr@cae.ca J.F. Richard CAE Electronics Ltd. Montreal, Canada ----------------------------------------------------------- From guest Fri Feb 4 09:41:23 1994 From: "Michael Jones" Message-Id: <9402040941.ZM12430@babar.asd.sgi.com> Date: Fri, 4 Feb 1994 09:41:01 -0800 In-Reply-To: jfr@cae.ca (Jean-Francois Richard) "Perf. 1.0 memory usage" (Feb 4, 11:33am) References: <9402041633.AA01738@cae.ca> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: jfr@cae.ca (Jean-Francois Richard), info-performer@sgi.sgi.com Subject: Re: Perf. 1.0 memory usage Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 4, 11:33am, Jean-Francois Richard wrote: > Subject: Perf. 1.0 memory usage : :Somebody just pointed out to me that my Performer 1.0 application :appears to have a size of about 70,000 pages (that's 280 Mb!) :according to the ps and top commands. That is very interesting :(and potentially dangerous) since the machine it is running on :only has 128 Mb of combined physical and virtual memory. In real :life, the program never seems to actually use more than 15 to 20 Mb. : :The memory appears to get reserved when I call pfInit(). Does Performer :need to reserve that much memory? Is there a chance that it might try :to actually use it and run out of swap space? Is there a way to :control Performer's appetite so that the other users of the computer :won't freak out when they look at my processes? The default allocation is 256MB. This issue has been dealt with in the upcoming 1.2 release of IRIS Performer with the new pfSharedArenaSize() function: just call it before your pfInit() call. Here's the reference page for the new functions (also pfSharedArenaBase() can be handy too). pfSharedMem(3pf) Silicon Graphics pfSharedMem(3pf) NAME pfInitArenas, pfGetSharedArena, pfGetSemaArena, pfTmpDir, pfGetTmpDir, pfSharedArenaSize, pfGetSharedArenaSize, pfSharedArenaBase, pfGetSharedArenaBase - Shared Memory Functions C SPECIFICATION #include long pfInitArenas(void); void * pfGetSharedArena(void); usptr_t * pfGetSemaArena(void); void pfTmpDir(char *dirname); const char* pfGetTmpDir(void); void pfSharedArenaSize(ulong size); ulong pfGetSharedArenaSize(void); void pfSharedArenaBase(void *base); void * pfGetSharedArenaBase(void); DESCRIPTION pfInitArenas creates a shared memory arena that can be used to allocate memory, locks and semaphores from (see pfMalloc, pfNewSema, pfNewLock). This function is called by pfInit so it is not necessary to call it when using libpf functions. Calling pfInitArenas again after using pfBlist, pfBpipe, pfQueue, pfNewLock, pfNewSema will have adverse affects due to the resetting of internal data structures. pfInitArenas uses usinit to create arenas for both locks and shared memory. These arenas are reflected in the Unix file system. Where these files are created is important. There must be as much space available to the file as is allocated for the arenas. 16K bytes are allocated for the locks and semaphores, which supports approximately 4K locks. pfTmpDir and the environment variablle PFTMPDIR control where pfInitArenas creates its arenas. If neither is specified, the semaphore arena is created in /usr/tmp and the shared memory arena is created in /dev/zero (swap space). If a temporary directory is specified, then files are created in that directory for the shared memory and semaphore arenas. Both these files are unlinked so that they are removed from the file system when the process terminates. Once created, these arenas cannot grow, so Performer tries to create a large (256MB) arena. For shared memory, swap space, the default, is usually preferable to using a file in a directory specified by PFTMPDIR. Using an actual file is slightly slower at allocation time and requires actual disk space for extending the file length to equal the amount of memory allocated (pfMalloc) from the arena. Swap space under 4.0.5 is not resevered or allocated until pfMalloc, so Performer can create a large arena without tying up actual swap space until it's used by pfMalloc. But under 5.0.1/5.1, arena space needs to be reserved up front. In this case, Performer limits the size of its shared memory arena to a fraction of the currently available swap space. This may cause some moderate or large applications to fail during pfMalloc. To avoid this problem under 5.0.1/5.1, increase the virtual size of swap space by creating a zero length file called /swap and adding a line to /etc/fstab: /swap swap swap vlength=5000000 and reboot the system. Under 5.1.2, this is no longer necessary since Performer uses a new IRIX mechanism for reserving swap space as the arena usage grows. pfSharedArenaSize can be used to override the arena size that Performer uses by default (256MB). size specifies the desired size in bytes. pfGetSharedArenaSize returns the arena size in bytes. pfSharedArenaBase sets the base address for the mapping of the shared memory arena. Normally, IRIX chooses the base address. This is useful if the application needs closer control over the layout of virtual address space, e.g. to avoid conflicts with other mappings. pfGetSharedArenaBase returns the base address for the arena. pfGetSemaArena returns a handle to the lock arena and pfGetSharedArena returns a pointer to the shared memory arena. This pointer cannot be used directly, only as an argument to pfMalloc. pfGetTmpDir returns the temporary directory set using pfTmpDir. NOTES These arenas can only be used by related processes. Meaning those processes that share a common heritage. Use pfDataPool for sharing memory between unrelated processes. pfInitArenas should be called before any other forks or sprocs are made. SEE ALSO acreate, usinit, pfMalloc, pfFree -- 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 Fri Feb 4 10:16:57 1994 Message-Id: <9402041816.AA11146@surreal.asd.sgi.com> To: jfr@cae.ca (Jean-Francois Richard) Cc: info-performer@sgi.sgi.com Subject: Re: Perf. 1.0 memory usage In-Reply-To: Your message of "Fri, 04 Feb 94 11:33:51 EST." <9402041633.AA01738@cae.ca> Date: Fri, 04 Feb 94 10:16:25 -0800 From: Jim Helman Status: O Somebody just pointed out to me that my Performer 1.0 application appears to have a size of about 70,000 pages (that's 280 Mb!) according to the ps and top commands. That is very interesting (and potentially dangerous) since the machine it is running on only has 128 Mb of combined physical and virtual memory. In real life, the program never seems to actually use more than 15 to 20 Mb. With Performer 1.0 on IRIX 4 and Performer 1.2 on IRIX 5.2, this large initialization is not a problems since the OS allocates space on demand without any pre-reservation. However with Performer 1.1 on IRIX 5.X, even though OS does not allocate the space until used, it does pre-reserve that much swap space. This can be bad. Performer will try to find a reasonable initialization size, however sometimes it may reserve too much and keep you from running other large programs. In this event, set the PFTMPDIR to a directory with a lot of space, e.g. /usr/tmp. Load times will be slower than when using swap, but you won't have swap space problems. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Feb 4 10:28:42 1994 Date: Fri, 4 Feb 1994 10:26:50 -0800 From: "David H. Whittington" Message-Id: <199402041826.AA28456@aw101.iasl.ca.boeing.com> To: info-performer@sgi.sgi.com Status: O Please unsubscribe me! Dave Whittington Boeing Commercial Aircraft (206)662-4610 From guest Fri Feb 4 11:27:38 1994 Date: Fri, 4 Feb 94 14:22:29 -0500 From: lbatayt%r2d2@relay.nswc.navy.mil (Lou Batayte) Message-Id: <9402041922.AA01366@r2d2> To: info-performer@sgi.sgi.com Subject: 1.x memory usage Status: O I just got a copy of the NASA/COSMIC FAST visualization code. In the initialization for that package they tell the installer to change the variable in the kerne,l "int availsmem_accounting = 0" to "int availsmem_accounting = 1". They further comment that this may cause some programs to "break" that don't care if the memory they have allocated is actually available. Will this mod to the kernel cause performer to break? From guest Fri Feb 4 12:02:34 1994 Date: Fri, 4 Feb 94 11:52:39 -0800 From: greg@snapper.arc.nasa.gov (greg pisanich) Message-Id: <9402041952.AA15923@snapper.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: performer and DIS Status: O Hi. I'm actually just learning about the capabilities of performer. And I'm interested in using it with Distributed Interactive Simulation (DIS). Could someone please help me resolve these questions: Does Performer has any DIS capabilities in it, or is there is any plan to add the DIS standard to it? I had heard a rumor of this. If not, is there any commercial or public-domain DIS standard code available that any one can tell me about? Is there a DIS mailing list? Thanks! GP. -------------------------------------------------------------------------- Greg Pisanich Email: greg@eos.arc.nasa.gov Tel: 415 604-1332 FAX: -0801 Flight Human Factors Division, NASA Ames Res. Ctr., MS269-6, MF, CA 94035 From guest Fri Feb 4 12:38:18 1994 Message-Id: <9402042023.AA12222@surreal.asd.sgi.com> To: lbatayt%r2d2@relay.nswc.navy.mil (Lou Batayte) Cc: info-performer@sgi.sgi.com Subject: Re: 1.x memory usage In-Reply-To: Your message of "Fri, 04 Feb 94 14:22:29 EST." <9402041922.AA01366@r2d2> Date: Fri, 04 Feb 94 12:23:36 -0800 From: Jim Helman Status: O Performer prefers availsmem_accounting=0 (note that the variable goes away in 5.2). Having availsmem_accounting=1 could cause the problems I described in the previous message regarding Performer reserving too much swap space for other processes to run. I would leave availsmem_accounting=0. I'm not familiar with how FAST allocates memory, however, I would expect at worst that when FAST runs out of memory, it will dump core rather than print out an error message and exit. One of the authors of FAST was a strong advocate for strict memory accounting (up front rather than when used). I forgot to mention in my previous mail, that under late 5.1 and 5.2 you can still turn off availsmem accounting by adding a large section of "virtual swap" To do this: su # chkconfig vswap on # edit /etc/config/vswap.options The same thing can be achieve by creating a zero length file /somefile and putting a line in your /etc/fstab or interactively invoking the swap(1) (swap -a -v 999999 /somefile) command. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Feb 4 12:37:08 1994 From: "Graham (Grambo) Beasley" Message-Id: <9402041235.ZM16122@beast.asd.sgi.com> Date: Fri, 4 Feb 1994 12:35:36 -0800 In-Reply-To: greg@snapper.arc.nasa.gov (greg pisanich) "performer and DIS" (Feb 4, 11:52am) References: <9402041952.AA15923@snapper.arc.nasa.gov> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: greg@snapper.arc.nasa.gov (greg pisanich), info-performer@sgi.sgi.com Subject: Re: performer and DIS Cc: graham@beast Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 4, 11:52am, greg pisanich wrote: > Subject: performer and DIS > Hi. I'm actually just learning about the capabilities of performer. And I'm > interested in using it with Distributed Interactive Simulation (DIS). > > Could someone please help me resolve these questions: > > Does Performer has any DIS capabilities in it, or is there is any plan to add > the DIS standard to it? I had heard a rumor of this. Right now, Performer does not have direct "DIS capabibilities" in it, as you probably are aware DIS (Distributed Interactive Simulation) can mean a lot of things, in the communication sense I take it you are asking whether it has DIS communications ability?. On March 17, 93 the IEEE approved DIS 1.0 as IEEE 1278 which is a communications standard for PDU's. Performer does not directly support this, several firms offer communications package which interface with this standard, and Performer can be used as the visual processing layer to optimally view your DIS based scene. If you are talking about the DIS portion that deals with the visual data-base, Performer can help you immensely there. DIS uses a SIF (std interchange format) that evolved from project 2851. One can write a loader that loads this SIF data into Performer, or use one of the popular modelling packages to convert SIF data to a "standard" format with an existing loader. As part of the Performer 1.2 development and release cycle the Hunter Liggett database that was used at iitsec 93 was converted by Software Systems into a MultiGen v-13.0 file format (which they supply a performer loader for). This database has been partially optimized for use with Performer 1.2 and should run at 30HZ on a 4 CPU Onyx. There will be a DIS database, moving models, free-be textures, etc. included on the forthcoming Performer 1.2 CD available shortly. > > If not, is there any commercial or public-domain DIS standard code available > that any one can tell me about? try wkatz@mak.com > > Is there a DIS mailing list? Loads, dpending on which special interest group you are interested in?, There is not a PerformerDIS mailing list, but if there is enough interest I would be happy to form one? GB -- "Do not follow where the path may lead. Go instead where there is no path and leave a trail." ---------------------------------------------------------------------- Graham (Grambo) Beasley Silicon Graphics, Inc. MTS (Simulator Guy) (415) 390-5420 graham@sgi.com ---------------------------------------------------------------------- From guest Fri Feb 4 13:03:54 1994 Date: Fri, 4 Feb 1994 13:04:32 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199402042104.NAA06929@mail.netcom.com> To: info-performer@sgi.sgi.com Subject: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ??? Cc: mdgood@netcom.com, ptinker@netcom.com, vmatt@netcom.com Status: O Performers, We currently run different versions of Performer on different IRIS hosts (on my main workstation I have 1.2 beta installed with 1.0 sitting in separate directories, e.g., /usr/include/Performer_1_0, etc.). Also, we may soon be using different SGI hosts running different IRIX versions. I've been trying to find a clean way to identify what version of IRIX and what version of Performer I am compiling/linking from and executing from for use in Imakefiles and compiler #ifdef's. Up until recently I did this by manually editing my Imakefiles or Makefiles. I was hoping there might be some default environment variables set, or some global pre-processor define's a la __sgi, __unix, host_mips, etc. For the IRIX version I realize I can do something cute with "uname" in my .cshrc file to set my own env. variable that will tell me what version of IRIX I'm running, e.g.: setenv __IRIX_VERSION `uname -r` With a little further kludgey processing I can fix up this env. variable to use in Imakefiles and #define's for C or C++ files (note, cpp #ifdef's can only use integer values not something like 4.0.5). But, I'd rather not rely on expecting a login user to have such a .cshrc kludge. Is there something better? As far as Performer versions, I've thought of a couple of hacks. One is to use some #define'd value that's declared in version 1.2 but not in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in Imakefiles and source files. Alternately, I though of another kludge such as, set pf_vers_date \\`grep Date /usr/include/Performer/pf.h` setenv __PF_VERSION `echo $pf_vers_date[2]` For now I'm requiring myself to explicitly use a -D on my imake command line that I test for in the Imakefile which creates a compiler -D define in my Makefile that I can test for in my source code (whew!!!). This also seems risky and depends on explicit user action rather than something built in. Is there something better? Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Fri Feb 4 13:06:44 1994 From: "Michael Jones" Message-Id: <9402041306.ZM13532@babar.asd.sgi.com> Date: Fri, 4 Feb 1994 13:06:35 -0800 In-Reply-To: greg@snapper.arc.nasa.gov (greg pisanich) "performer and DIS" (Feb 4, 11:52am) References: <9402041952.AA15923@snapper.arc.nasa.gov> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: greg@snapper.arc.nasa.gov (greg pisanich), info-performer@sgi.sgi.com Subject: Re: performer and DIS Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 4, 11:52am, greg pisanich wrote: > Subject: performer and DIS :Hi. I'm actually just learning about the capabilities of performer. And I'm :interested in using it with Distributed Interactive Simulation (DIS). : :Could someone please help me resolve these questions: : :Does Performer has any DIS capabilities in it, or is there is any plan to add : the DIS standard to it? I had heard a rumor of this. IRIS Performer has no specific DIS protocol or application-level support routines. It is, however, just the thing for developing such applications. :If not, is there any commercial or public-domain DIS standard code available :that any one can tell me about? Several companies have produced PDU processing software that does vehicle position extrapolation, player ingress/egress, and other DIS-specific tasks. At the 1993 I/ITSEC show in Orlando, over 30 companies were using both IRIS Performer and the MaK stealth software for easy DIS integration. I'd suggest that you contact John Morrison at MaK (jm@mak.com). They are an IRIS Performer beta site and have been very active in DIS developments: MaK Technologies 380 Green Street Cambridge, MA 02139 Phone (617) 876-8085 :Is there a DIS mailing list? I don't know of a specific one. You might consider that given the huge ratio of IRIS Performer users in the DIS networking component of I/ITSEC '93 (more than 80% by my count) that this mailing list is the de facto one. -- 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 Fri Feb 4 14:39:17 1994 From: "Dennis Pierce" Message-Id: <9402041739.ZM7726@sgimco.orlando.sgi.com> Date: Fri, 4 Feb 1994 17:39:02 -0500 In-Reply-To: steveh@k2.mss.ctaeng.com (Steve Hurt) "Snow and Rain" (Feb 4, 7:01am) References: <9402041401.AA03171@k2.mss.ctaeng.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: steveh@k2.mss.ctaeng.com (Steve Hurt), dpierce@sgi.sgi.com Subject: Re: Snow and Rain Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 4, 7:01am, Steve Hurt wrote: > Subject: Snow and Rain > >I just red your message on snow and rain fx. In it you present >some really good ideas, what kind of "occulting object" would >you recommend? > >Thx. >-------------------------------------------- >Steve Hurt CTA Incorporated. >5670 Greenwood Plaza Blvd Suite 200 >Englewood, Colorado 80111 > >303) 889-1286 >steveh@ctaeng.com >-------------------------------------------- > >-- End of excerpt from Steve Hurt an occulting object is just a blob - in its most simple form, the object is just a screen dot (pixel) - a more advanced form would be an alpha blended gaussian distributed circle where the outer edges are nearly transparent and the center is opaque - I didn't want to sound so pedestrian by saying "pixel" because my old system didn't have any transparency features and I think that it would be quite beneficial to explore a more "correct" presentation with this new fancy RE hardware but... please understand that ANY additional use of transformation and fill hardware will be difficult to justify, so the simpler, the better - and I think you'll find that a few streaks (for rain) or a few floating pixel clusters (for snow) will be sufficient to convey a reasonable presentation of precepitation - also, be aware that the successful implementation of this will probably be largely based on "fooling" the eye into thinking that more is being shown than is actually being presented - I don't think there is sufficient bandwidth in the RE to draw a physical model of rain or snow PLUS do the real task of terrain, culture and models the real novelty of the approach presented is that it solves the problem of having dots fall in a controlled manner with two simple linear arrays - contrast this with a full-up 1280x1024 array this pseudo-random approach can also be used to generate random, but repeatable ground features such as roads, tree patterns, bush clutter, and the like - for some applications, the rapid generation of "good enough" terrain and culture can be done procedurally instead of actually modeling the features - this gives an "infinite" scape to play on without having to actually build the model first - I'm sure the approach has been implemented a couple of hundred times by the real IG folks hope this helps... bye. -- Dennis Pierce, SGI, 900 Winderley Place, Ste 130, Maitland, FL 32751 email: dpierce@sgi.com vmail: 8548 tel : 407.660.0073 late : 407.660.2789 fax : 407.660.8981 cell : 407.256.8447 From aschaffe Fri Feb 4 19:28:47 1994 From: aschaffe (Allan Schaffer) Message-Id: <9402041928.ZM18173@holodeck.asd.sgi.com> Date: Fri, 4 Feb 1994 19:28:46 -0800 In-Reply-To: hitchner@netcom.com (Lew Hitchner) "IRIX and Performer version nos. for Makefiles and compiler #ifdefs ???" (Feb 4, 1:04pm) References: <199402042104.NAA06929@mail.netcom.com> X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: hitchner@netcom.com (Lew Hitchner) Subject: Re: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ??? Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 4, 1:04pm, Lew Hitchner wrote: > As far as Performer versions, I've thought of a couple of hacks. One > is to use some #define'd value that's declared in version 1.2 but not > in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in > Imakefiles and source files. Alternately, I though of another kludge > such as, > > set pf_vers_date \\`grep Date /usr/include/Performer/pf.h` > setenv __PF_VERSION `echo $pf_vers_date[2]` In 1.2's /usr/include/Performer/pr.h there is defined: #define PF_MAJOR_VERSION 1 #define PF_MINOR_VERSION 2 That will at least distinguish 1.2 from 1.0/1.1, and I expect it to stick around for later releases too. Offhand I can't think of an easy way to distinguish 1.0 from 1.1.. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Fri Feb 4 21:09:58 1994 Date: Sat, 5 Feb 94 00:09:54 -0500 From: barras@flash.vsl.ist.ucf.edu (Andrew Barras) Message-Id: <9402050509.AA06156@flash.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: Mailing List Status: O Please remove my name from the mailing list. THANKS ______________________________________________________________________________ Andrew Barras The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) barras@vsl.ist.ucf.edu _______________________________________________________________________________ From guest Sun Feb 6 23:32:42 1994 Date: Mon, 7 Feb 94 18:32:31 +1100 From: ben@moffatt.vislab.su.edu.au (Ben Simons) Message-Id: <9402070732.AA17240@moffatt.vislab.su.edu.au> To: info-performer@sgi.sgi.com Subject: unsubscribe Cc: Status: O unsubscribe BTW, THERE IS WAY TOO MUCH PERFORMER MAIL COMING THROUGH. I PRESUME THAT ALL THIS INFO IS ARCHIVED SOMEWHERE ANYWAY. I'VE COLLECTED SOME 17-THOUSAND LINES OF MAIL FROM THIS GROUP. TOO MUCH ALREADY!!! I'D SUGGEST YOU GET YOURSELVES A NEWS GROUP! ben. _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-692-3005 AUSTRALIA. 2006. From guest Mon Feb 7 01:20:35 1994 Message-Id: <9402070920.AA09883@surreal.asd.sgi.com> To: ben@moffatt.vislab.su.edu.au (Ben Simons) Cc: info-performer@sgi.sgi.com Subject: Re: unsubscribe In-Reply-To: Your message of "Mon, 07 Feb 94 18:32:31 +1100." <9402070732.AA17240@moffatt.vislab.su.edu.au> Date: Mon, 07 Feb 94 01:20:22 -0800 From: Jim Helman Status: O I agree about the quantity, but given the rules and attitude towards newsgroup creation in the comp.blah hierarchy, I don't think I'd want to try it with less than 500 people. We have talked about creating a separate lower-volume mailing list for announcements...when we have the time! In the meantime, for those who want the information, I'd suggest getting your mailer to automatically sort your incoming mail into different folders so you don't get overwhelmed with biff beeps. MH can do it, and I'm sure most other mail packages can as well. Another alternative, if you have a good newsadmin, is to gateway the mailing list into a local newsgroup. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Date: Mon, 7 Feb 94 18:32:31 +1100 From: ben@moffatt.vislab.su.edu.au (Ben Simons) To: info-performer@sgi.sgi.com Subject: unsubscribe unsubscribe BTW, THERE IS WAY TOO MUCH PERFORMER MAIL COMING THROUGH. I PRESUME THAT ALL THIS INFO IS ARCHIVED SOMEWHERE ANYWAY. I'VE COLLECTED SOME 17-THOUSAND LINES OF MAIL FROM THIS GROUP. TOO MUCH ALREADY!!! I'D SUGGEST YOU GET YOURSELVES A NEWS GROUP! ben. _______________________________________________________ Ben Simons Physics Building, A28, VisLab Systems Manager Sydney University. NSW. Phone +61-2-692-3005 AUSTRALIA. 2006. From guest Mon Feb 7 02:38:04 1994 Date: Mon, 7 Feb 94 11:42:02 +0100 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9402071042.AA20826@scl> To: info-performer@sgi.sgi.com Subject: Performer & TDI Explore Status: O Bonjour ... Is there anybody trying to use TDI explore 3.02 scene and data base in Performer or interrested in ? (same question with Inventor !) Merci et bienvenue ------------------------------------------------------------------------------ = Cedric GAUTIER - SYSECA (SDA) a Thomson Company - Tel: (33)(1) 49 11 75 47 = = 315 Bureaux de la Colline 92213 St-Cloud FRANCE - Fax: (33)(1) 49 11 71 10 = = Virtual Image Group (3D Simulation/Virtual Reality) - email: gce@syseca.fr = ------------------------------------------------------------------------------ From guest Mon Feb 7 02:59:23 1994 Date: Mon, 7 Feb 94 11:00:44 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9402071100.AA04937@death.reading.sgi.com> To: info-performer@sgi.sgi.com Subject: More Intersection Questions.... Status: O I am relayin the question from DRA Farnborough in the UK, they own more ONYX's than the rest of the universe but they have no e-mail. The application is line of sight & occulting calculations, if a pfSegsIsectNode is used on a vector between two moving objects they want to test for terrain intersections. It works but there are many intersections being returned and they only need to wait for the first terrain intersection so they are looking to improve performance. They specify a discriminator callback which prints a message that it has been called and returns PFTRAV_TERM. However the callback is invoked multiple times for each intersection instead of just once. Is this a bug or a mis-understanding of the man page ? ANGUS HENDERSON "Imagine your witty quote here" From guest Mon Feb 7 09:02:21 1994 Message-Id: <9402071633.ZM11368@unknown.zmail.host> Date: Mon, 7 Feb 1994 16:33:12 +0000 In-Reply-To: "Richard Gallery" "Re: Performer problem" (Jan 7, 9:31am) References: g<755350832WedGMT@gallery> <9401070931.ZM14006@unknown.zmail.host> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: dxf format Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi My reason for asking about dxf format is that I have got some 3D models, not designed in Autocad, which can be written to dxf. Also, I have been told that there will be a dxf file format loader for Performer quite soon. So I would appear to have a quick route from my models to dxf to Performer. However if dxf has basic limitations like not knowing about texture, or material specification, or has an incomplete colour space, then I don't want to know about it (I can write my own converter anyway in that case). Any information you have would be useful. I have looked at an Aoutocad manual, but it is several years old, and in any case I have the impression of being overwhelmed with information that does'nt appear relevant from reading it. Thanks Richard Galelry From guest Mon Feb 7 09:21:06 1994 From: "Michael Jones" Message-Id: <9402070839.ZM16807@babar.asd.sgi.com> Date: Mon, 7 Feb 1994 08:39:09 -0800 In-Reply-To: angus@death.reading.sgi.com (Angus Henderson) "More Intersection Questions...." (Feb 7, 11:00am) References: <9402071100.AA04937@death.reading.sgi.com> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: angus@death.reading.sgi.com (Angus Henderson), info-performer@sgi.sgi.com Subject: Re: More Intersection Questions.... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 7, 11:00am, Angus Henderson wrote: > Subject: More Intersection Questions.... This is really Jim Helman's question, but I'll give it a shot... :The application is line of sight & occulting calculations, if a :pfSegsIsectNode is used on a vector between two moving objects :they want to test for terrain intersections. It works but there :are many intersections being returned and they only need to wait :for the first terrain intersection so they are looking to improve :performance. : :They specify a discriminator callback which prints a message that :it has been called and returns PFTRAV_TERM. : :However the callback is invoked multiple times for each intersection :instead of just once. [before we even start: you are specifying CLIP_END, right? and isect caching is on? make sure before proceeding...] I presume that you mean "...callback is invoked multiple times for each intersection _search_ instead of just once." Given that the database is not sorted into a total order in the BSP sense, we must look at all "possible" nodes for each intersection. Possible nodes are those whose bounding volumes are closer at some point along the search vector than the closest known intersection. Here's the idea (boxes represent bounding volumes): * +-------------+ +------|--+ | seg: --------|------|W-|-------S--|-----------------> | +----- B -----+ +--- A ---+ Now if the first node tested in the search is A, and the intersection is found at point W, we still need to test node S, since it's bounding volume extends closer to the origin of the search vector than the closest known intersection point. (This fact is indicated by the small asterisk) The result of searching node B is in this case point 'S', which is seen to be more distant and will thus be discarded. :Is this a bug or a mis-understanding of the man page ? Performance oriented customers (which is just about everyone) can get best performance by minimizing the overlap of nodes. How is this best done? By organizing the database spatially: form a quad-tree or oct-tree like hierarchy with your data. If the nodes A and B above had not been in overlap, there could have been but one search. Also, make sure that your geosets are not too big: 5 to 50 polys makes sense, but thousands of polygons in a geoset can be dangerous since the intersection test must be performed on _each_ primitive in the geoset whenever the set's bounding volume is hit by the vector. For even greater performance in intersection processing, look to IRIS Performer 1.2, which has these important new intersection features: 1. pfPartition node for direct spatial indexing into an automatically built grid-like search structure. 2. parallel intersection processing to let extra CPU's be used for correspondingly greater intersection throughput. -- 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 Mon Feb 7 11:08:31 1994 Message-Id: <9402071908.AA19812@surreal.asd.sgi.com> To: angus@death.reading.sgi.com (Angus Henderson) Cc: info-performer@sgi.sgi.com Subject: Re: More Intersection Questions.... In-Reply-To: Your message of "Mon, 07 Feb 94 11:00:44 GMT." <9402071100.AA04937@death.reading.sgi.com> Date: Mon, 07 Feb 94 11:08:21 -0800 From: Jim Helman Status: O > They specify a discriminator callback which prints a message that > it has been called and returns PFTRAV_TERM. > However the callback is invoked multiple times for each intersection > instead of just once. Three possibilites: 1) You mean multiple callbacks per request, for different pieces of geometry as mtj suggests. 2) The request contains multiple segments and you are only terminating one of them, so you still get callbacks on the others. (You can OR PFTRAV_IS_ALL_SEGS into the return to have PFTRAV_TERM apply to all segments) 3) There's a bug. Also, if all they want is terrain, the best way to speed things up would be to use pfNodeTravMasks to set a bit in the intersection mask of the terrain subgraph and clear it elsewhere and then restrict the intersection request to that subgraph using the request's intersection mask. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Feb 7 11:36:14 1994 Message-Id: <9402071936.AA19954@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com Subject: Re: Static backgrounds (fwd for mwilliam@ldsa.com) In-Reply-To: Your message of "Thu, 03 Feb 94 10:18:28 EST." <9402031758.AA14808@surreal.asd.sgi.com> Date: Mon, 07 Feb 94 11:36:04 -0800 From: Jim Helman Status: O > I need to know if there is a way to draw static background with > GL and let Performer handle moving models without requiring me to redraw > the background every frame. One way to do this is to keep a copy of the rendered scene, including Z, in another buffer, e.g. the left stereo buffer, and then do a rectcopy() to blat it do your working buffer where you render the models. In Performer, you'd use the draw process callbacks for issuing the GL commands to make this happen. For best performance, you need the rectcopy source and destination positions to be the same (hence the use of a coincident buffer) but I think the Z copy rate may still limit you to a relatively low frame rate (20Hz?) unless the window is fairly small. srf knows more about this than I do. Perhaps, she'll comment. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Feb 7 12:02:03 1994 Date: Mon, 7 Feb 94 15:03:16 -0500 From: tonnesen@enews.nrl.navy.mil (Cindy Tonnesen) Message-Id: <9402072003.AA27957@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O unsubscribe, please From guest Mon Feb 7 12:52:26 1994 From: Brett Alexander Hutley Message-Id: <199402072032.AA05427@frost.bain.oz.au> Subject: unsubscribe To: info-performer@sgi.sgi.com Date: Tue, 8 Feb 1994 07:32:51 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12 Status: O unsubscribe From guest Mon Feb 7 12:58:25 1994 id AA14716; Mon, 7 Feb 94 15:56:21 EST Message-Id: <9402072059.AA21730@sultan> To: info-performer@sgi.sgi.com Subject: please unsubscribe me Reply-To: dpy@sultan.CV.COM Date: Mon, 07 Feb 94 15:59:15 EST From: David Youatt Status: O -- David Youatt, dpy@sgi.com, (508) 562-4800 SGI Consultant, dpy@sultan.cv.COM for local mail From guest Tue Feb 8 11:32:15 1994 Message-Id: <9402072107.AA16244@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Feb 1994 16:07:53 -0500 To: info-performer@sgi.sgi.com From: ngo@interval.com (Tom Ngo) (by way of barrus@merl.com (John W. Barrus)) Subject: How to remove oneself from the mailing list Status: O It seems like it might be time for this message again. I hope that Tom doesn't mind that I repost his message, since he said it so nicely. John B. ------------------------------------------ *** This is not a flame *** Everyone, please note the following excerpt from the introductory message for this mailing list, copied below. If you wish to unsubscribe, please send your mail to iris-performer-request@sgi.com, not iris-performer@sgi.com. The latter address copies your request to everyone on the list! --Tom Ngo (after plowing through more than 80 mail messages, of which a significant number were requests to be removed from iris-performer). * * * If your email address changes, you wish to be removed, your post bounces, etc. please notify the list administrator. Send all administrative requests to: info-performer-request@sgi.com ============================================================================= Tom Ngo 415/354-3616 (Voice) Interval Research Corporation 415/354-0872 (FAX) 1801-C Page Mill Rd Palo Alto, CA 94304 ngo@interval.com From guest Mon Feb 7 14:51:19 1994 Date: 07 Feb 1994 15:25:22 -0800 From: daryl@leia.hrl.hac.com (Daryl Miyagishima) Subject: unsubscribe To: info-performer@sgi.sgi.com Message-Id: <9402072325.AA24414@leia.hrl.hac.com> Content-Transfer-Encoding: 7BIT Status: O Please unsubscribe me. Thank you. Daryl K. Miyagishima EMAIL: 00a4269@msgate.emis.hac.com Member of the Research Staff SMAIL: Hughes Research Labs (310)317-5185 Work 3011 Malibu Canyon Rd. (310)317-5695 Fax Malibu, CA 90265-4737 From guest Tue Feb 8 11:17:36 1994 From: Steve Elkins Message-Id: <199402081917.LAA13724@eos.arc.nasa.gov> To: info-performer@sgi.sgi.com Status: O To : info-performer From : S. Elkins Subject : Machine hang and logout. We are running a flight simulation based on the perfly demo from Performer 1.0/1.1. The simulation is running on a 2cpu ONYX RE2 with 2 rm boards, and IRIX 5.1.1.3. The problem is that after a random amount of time, anywhere from a few seconds to several hours, the graphics lock up and the system logs us out. The SYSLOG shows either : unix: WARNING: RE pipe 0: FIFO timeout - or - unix: WARNING: RE pipe 0: lightweight deactivation timed out when the hang/logout problem occurs. We have two ONYX systems and this problem occurs on both of them. Is this a problem with Performer 1.0/1.1 or something else? Has anyone else had a problem with systems locking up? Thanks for any information reguarding this problem. S. Elkins spelk@eos.arc.nasa.gov Sterling Software - NASA Ames Division From guest Tue Feb 8 17:16:20 1994 From: "Sharon Fischler" Message-Id: <9402081716.ZM2597@rose.asd.sgi.com> Date: Tue, 8 Feb 1994 17:16:10 -0800 In-Reply-To: Steve Elkins "" (Feb 8, 11:17am) References: <199402081917.LAA13724@eos.arc.nasa.gov> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: Steve Elkins , info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O +>---- On Feb 8, 11:17am, Steve Elkins wrote: > Subject: onyx hang problem ->To : info-performer ->>From : S. Elkins ->Subject : Machine hang and logout. -> ->We are running a flight simulation based on the perfly demo from ->Performer 1.0/1.1. The simulation is running on a 2cpu ONYX RE2 with ->2 rm boards, and IRIX 5.1.1.3. -> ->The problem is that after a random amount of time, anywhere from a few ->seconds to several hours, the graphics lock up and the system logs us out. ->The SYSLOG shows either : -> ->unix: WARNING: RE pipe 0: FIFO timeout - or - ->unix: WARNING: RE pipe 0: lightweight deactivation timed out -> ->when the hang/logout problem occurs. We have two ONYX systems and this ->problem occurs on both of them. Good information. It would also be helpful to know 1) does this only happen when you run as root? 2) are you doing anything to isolate CPUs? 3) the output of hinv Thanx! srf. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Tue Feb 8 18:42:35 1994 Message-Id: <9402090244.AA21429@Crazypete.AI.SRI.COM> To: "Sharon Fischler" Cc: Steve Elkins , info-performer@sgi.sgi.com In-Reply-To: Your message of "Tue, 08 Feb 1994 17:16:10 PST." <9402081716.ZM2597@rose.asd.sgi.com> Date: Tue, 08 Feb 1994 18:44:17 -0800 From: Stephen Lau Status: O ->The problem is that after a random amount of time, anywhere from a few ->seconds to several hours, the graphics lock up and the system logs us out. ->The SYSLOG shows either : -> ->unix: WARNING: RE pipe 0: FIFO timeout - or - ->unix: WARNING: RE pipe 0: lightweight deactivation timed out -> We have a 4 process Onyx 4E2 and we had a similar problem. The fix was to upgrade our boards to the latest rev. Hope this helps. Upgrading to the latest version of IRIX, 5.1.1.3 or 5.2 didn't help. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "No, no, not Orwellian, HUXLEY! SRI International | Brave New World." 333 Ravenswood Ave., Menlo Park, CA. 94025| - George Coates, "Box Conspiracy: (415) 859-2925 (415) 326-6200| An Interactive Sho" ------------------------------------------------------------------------------- From guest Tue Feb 8 18:59:24 1994 Message-Id: <9402090301.AA21536@Crazypete.AI.SRI.COM> Cc: "Sharon Fischler" , Steve Elkins , info-performer@sgi.sgi.com In-Reply-To: Your message of "Tue, 08 Feb 1994 18:44:17 PST." <9402090244.AA21429@Crazypete.AI.SRI.COM> Date: Tue, 08 Feb 1994 19:01:18 -0800 From: Stephen Lau Status: O >We have a 4 process Onyx 4E2 and we had a similar problem. Umm..that should have read "We have a 4 processor Onyx...". I hope SGI's can handle more then four processes... :) Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "No, no, not Orwellian, HUXLEY! SRI International | Brave New World." 333 Ravenswood Ave., Menlo Park, CA. 94025| - George Coates, "Box Conspiracy: (415) 859-2925 (415) 326-6200| An Interactive Sho" ------------------------------------------------------------------------------- From guest Tue Feb 8 20:08:03 1994 From: "Wade Olsen" Message-Id: <9402082008.ZM5928@fnord.asd.sgi.com> Date: Tue, 8 Feb 1994 20:08:00 -0800 In-Reply-To: aschaffe@holodeck (Allan Schaffer) "Re: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ???" (Feb 4, 7:28pm) References: <199402042104.NAA06929@mail.netcom.com> <9402041928.ZM18173@holodeck.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: aschaffe (Allan Schaffer), hitchner@netcom.com (Lew Hitchner) Subject: Re: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ??? Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 4, 7:28pm, Allan Schaffer wrote: > Subject: Re: IRIX and Performer version nos. for Makefiles and compiler #i > On Feb 4, 1:04pm, Lew Hitchner wrote: > > As far as Performer versions, I've thought of a couple of hacks. One > > is to use some #define'd value that's declared in version 1.2 but not > > in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in > > Imakefiles and source files. Alternately, I though of another kludge > > such as, > > > > set pf_vers_date \\`grep Date /usr/include/Performer/pf.h` > > setenv __PF_VERSION `echo $pf_vers_date[2]` > > In 1.2's /usr/include/Performer/pr.h there is defined: > > #define PF_MAJOR_VERSION 1 > #define PF_MINOR_VERSION 2 > > That will at least distinguish 1.2 from 1.0/1.1, and I expect it to > stick around for later releases too. Offhand I can't think of an > easy way to distinguish 1.0 from 1.1.. > > Allan > > > -- > Allan Schaffer > Silicon Graphics > aschaffe@sgi.com > >-- End of excerpt from Allan Schaffer In the makefile you can have this to tell if your on irix4.* or irix5.* and set flags accordingly. #if SVR4 # Its IRIX5... #else # Its IRIX4... #endif -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Wed Feb 9 00:43:27 1994 Message-Id: <9402090843.AA10194@sgi.sgi.com> Date: Wed, 09 Feb 94 03:43:25 EST From: M904662P@ISOBB3.PWFL.COM To: info-performer@sgi.sgi.com Subject: Infrared Sensor Imaging on SGI Platforms? Status: O From: Marcus Rothstein Deutsche Aerospace (DASA), Munich, GERMANY Phone: 011-49-89-607-28312 FAX: 011-49-89-607-22491 ----------------------------------------------------------------------- Subject: Infrared Sensor Imaging on SGI Platforms? Is it possible to display true IR images that would parallel a standard visual database with specific IR attributes and materials (perhaps by special coding or a shadow DB)? Marcus Mail Address: c/o P&W; 400 Main St. 103-01; EHartford,CT 06108 Internet Address: rothstmd@pwfl.com ----------------------------------------------------------------------- From guest Wed Feb 9 06:18:39 1994 From: kotto@caeg.rmi.de Date: Wed, 9 Feb 94 14:31:45 +0100 Message-Id: <9402091331.AA02803@caeg> To: srf@sgi.sgi.com Subject: Machine hang and logout Cc: info-performer@sgi.sgi.com, spelk@eos.arc.nasa.gov, lau@ai.sri.com Reply-To: kotto%caeg.uucp@Germany.EU.net Status: O > ->unix: WARNING: RE pipe 0: FIFO timeout - or - > ->unix: WARNING: RE pipe 0: lightweight deactivation timed out > > We have a 4 process Onyx 4E2 and we had a similar problem. The fix > was to upgrade our boards to the latest rev. Hope this helps. Upgrading > to the latest version of IRIX, 5.1.1.3 or 5.2 didn't help. Upgrading to the latest rev level didn't help on our Onyx. Yesterday we got a new GE10 and the logout still occurs. gfxinfo tells us : 12 GE (GE10 rev. 0x7/011) 4 RM4 boards (rev. 00112/00112/00112/00112) According to our local SGI tech support this is the latest rev. Currently we run only Performer based programmes on this machine. I can not tell whether any pure GL progam could do the same. We don't run as root and don't isolate processors. Klaus ---------------------------------- | Klaus Otto, CAE Electronics GmbH | | kotto%caeg.uucp@Germany.EU.net | ---------------------------------- From guest Wed Feb 9 05:39:57 1994 Date: Wed, 9 Feb 94 14:34:38 +0100 From: Ivan.Ivanov@zfe.siemens.de (Ivan K. Ivanov) Message-Id: <9402091334.AA19928@stack.zfe.siemens.de> To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O I'd like to unsubscribe this news group. Txs, iki. From guest Wed Feb 9 05:53:09 1994 id AA12750; Wed, 9 Feb 94 08:51:02 EST Message-Id: <9402091351.AA12750@cvbnet.CV.COM> From: Gregory Smith x4431 5-2 Subject: Re: onyx hang To: srf@rose (Sharon Fischler) Date: Wed, 9 Feb 94 8:50:08 EST Cc: info-performer@sgi.sgi.com In-Reply-To: <9402081716.ZM2597@rose.asd.sgi.com>; from "Sharon Fischler" at Feb 8, 94 5:16 pm Mailer: Elm [revision: 70.85] Status: O > > +>---- On Feb 8, 11:17am, Steve Elkins wrote: > > Subject: onyx hang problem > ->To : info-performer > ->>From : S. Elkins > ->Subject : Machine hang and logout. > -> > ->We are running a flight simulation based on the perfly demo from > ->Performer 1.0/1.1. The simulation is running on a 2cpu ONYX RE2 with > ->2 rm boards, and IRIX 5.1.1.3. > -> > ->The problem is that after a random amount of time, anywhere from a few > ->seconds to several hours, the graphics lock up and the system logs us out. > ->The SYSLOG shows either : > -> > ->unix: WARNING: RE pipe 0: FIFO timeout - or - > ->unix: WARNING: RE pipe 0: lightweight deactivation timed out > -> > ->when the hang/logout problem occurs. We have two ONYX systems and this > ->problem occurs on both of them. > We had the same issue with our onyx. The problem was caused by a bad ( out of rev ) RM4 board. Ask to have your board levels checked and replaced if necessary. From aschaffe Wed Feb 9 07:50:36 1994 From: aschaffe (Allan Schaffer) Message-Id: <9402090750.ZM28595@holodeck.asd.sgi.com> Date: Wed, 9 Feb 1994 07:50:30 -0800 In-Reply-To: M904662P@ISOBB3.PWFL.COM "Infrared Sensor Imaging on SGI Platforms?" (Feb 9, 3:43am) References: <9402090843.AA10194@sgi.sgi.com> X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: M904662P@ISOBB3.PWFL.COM Subject: Re: Infrared Sensor Imaging on SGI Platforms? Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 9, 3:43am, M904662P@ISOBB3.PWFL.COM wrote: > > Is it possible to display true IR images that would parallel a > standard visual database with specific IR attributes and materials > (perhaps by special coding or a shadow DB)? The basic topic to look into for forward-looking IR is the pfColortable. You can define pfColortables on a per-GeoState basis, just in the same way you would define materials, etc. Or, you could do things yourself in a callback -- Javier Castellar posted a message about this a few months ago: If you wish to simulate a complete IR scene you should include a quantization effects on the IR sensors. Some types of IR sensors are using only a few bits per pixel in a non linear distribution across the IR signal. You can emulate this fine tune effect with a very simple callback to GL, just using the GL cmaskcall at your choice: RGBwritemask( Rmask, Gmask, Bmask) or writemask(color_map_mask) You can force to be aliased at any spectrum just turning off the bits which you wish on each component or color map( 0xFF will be without dicretization effect, 0xF0 will have a strong quantization effect ... etc). We have used it to match a real bad IR sensor and the final result is very similar to the real. (TOW IR sensors) Hope to help. Javier Castellar javier@madrid.sgi.com Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Feb 10 05:13:07 1994 Message-Id: <9402101301.ZM17856@unknown.zmail.host> Date: Thu, 10 Feb 1994 13:01:02 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: 3D Studio Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi Are there any plans to do a 3DS (from Autodesk) loader for Performer. I have some 3DS models that I would like to read into a Performer application. I have approached Autodesk about access to the file format, but they appear reluctant to release this (I appreciate the need to guard proprietary information). So, anyone else done this/thinking of it, any feedback would be appreciated. Thanks Richard Gallery From guest Thu Feb 10 07:30:55 1994 Date: Thu, 10 Feb 94 10:29:37 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9402101529.AA05760@ldsa.com> To: info-performer@sgi.sgi.com Status: O I noticed a comment in the code of complex.c which says: /* * These enables should be set to reflect to majority of the * database. If modt geometry is not textured, then texture * should be disabled. However, you then need to change the * FLIGHT-format file reader. (pfflt.c) */ In my database, none of my flight format models are textured. What performance increase could I get by making this modification? Has anybody done this? I have not meddled in the workings of pfflt.c. Does this require a lot of work, or just a change to a pfEnable call? Thanks Mike Williams LORAL Defense Systems mwilliam@ldsa.com From guest Thu Feb 10 08:39:43 1994 Message-Id: <9402101639.AA22708@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Feb 1994 11:40:07 -0500 To: info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: DEM, DLG data and Performer Status: O Has anyone written a converter/loader for DEM data or DLG data from the USGS? I am fairly new to the data and to performer so I don't know exactly what would be required or even if it is possible to directly load DEM data into performer. If not, is anyone familiar with programs for the SGI that allow you to view and explore the DEM data? Explorer might be a possibility, but I don't know very much about Explorer either. Any ideas or suggestions? Thanks, John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From guest Thu Feb 10 11:35:55 1994 Date: Thu, 10 Feb 94 16:55:47 GMT From: arnaud@thomson-dsi.fr (AST ) Message-Id: <9402101655.AA04385@thodsic.cergy.thomson-dsi.fr> To: info-performer@sgi.sgi.com Subject: 3D Studio Status: O Hello, > Are there any plans to do a 3DS (from Autodesk) loader for Performer ... It is possible to get from Autodesk a 3DS toolkit (include files + libraries). (Autodesk will ask you to sign a confidential agreement first ! ). This toolkit provides C function calls to create 3DS files. There is unfortunately no API for reading 3DS files. This would be of little use, but there is a hack: the documentation that comes with the toolkit describes how a 3DS binary file is structured and how information is stored. You can therefore write your own routines to extract the information you need and convert it to Performer geosets. If there is a easier way, please let us know... ---------------------------- Christophe Delepine arnaud@cergy.thomson-dsi.fr THOMSON-CSF PARIS ---------------------------- From aschaffe Sat Feb 12 06:21:59 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9402120621.ZM17689@holodeck.asd.sgi.com> Resent-Date: Sat, 12 Feb 1994 06:21:59 -0800 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) Resent-To: info-performer-dist Message-Id: <199402121410.PAA05836@sgi_nils.cmr.no> X-Authentication-Warning: sgi_nils.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: sgi_nils.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Subject: pfDelete.... Date: Sat, 12 Feb 1994 15:10:50 +0100 From: Nils Thune Status: O Part of my scene consist of a pfGeode with a gset. The vertices, colors and normals in the gset has been allocated with pfMalloc(..., NULL); and added to the gset with pfGSetAttr(...); When I call pfDelete(myGeode); will it deallocate the gset itself and all the memory used by the user supplied vertices, colors and normals (allocated by pfMalloc(...), and hence should have a ref count)? Or, do I have to add a pfDeleteFunc to gset which then should delete verices, etc.? - 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 Mon Feb 14 11:20:57 1994 Date: Mon, 14 Feb 1994 09:28:48 -0800 (PST) From: Michael Macedonia Subject: performer crash on crimson To: info-performer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Having problems running an app using performer 1.0 on a Crimson RE. It crashes every time. Runs fine on our challenge machines, Indigos, etc. Question: are there any known problems running performer on Crimson's ? Thanks, Mike Macedonia From guest Mon Feb 14 20:54:06 1994 Return-Path: Date: Tue, 15 Feb 94 13:35:06 +0900 From: wry@dimwit.dst.nk-exa.co.jp (Masahiko Yamanaka) Message-Id: <9402150435.AA00991@dimwit.dst.nk-exa.co.jp> To: info-performer%sgi.sgi.com@sgitokyo.nsg.sgi.com Subject: MultiChannel in singlePipe Status: O I am using 2 pfChannels. One is main channel, another is sub channel( toggles show/hide, a part of the window ). As I use following, pfChanDrawFunc( mainChannel, mainDrawChanCB ); pfChanDrawFunc( subChannel, subDrawChanCB ); then rendering is occured as following( slow ). 1. draw main 2. swapbuffers 3. draw sub 4. swapbuffers I would like to do this as following( fast ). 1. draw main 2. draw sub 3. swapbuffers If I don't use pfChanDrawFunc( mainChannel, mainDrawChanCB ), I can get fast one. But, many processes must be done in mainChannel, because subChannel may disappear. How can I do this well? I'm using IRIX4.0.5/CrimsonVGX with Performer1.0. Thanks. -- Masahiko Yamanaka From guest Tue Feb 15 03:05:09 1994 Date: Tue, 15 Feb 94 13:04:07 +0200 From: rany@bvr.co.il (Ran Yakir) Message-Id: <9402151104.AA18814@rea1.bvr.co.il> To: info-performer@sgi.sgi.com Status: O I = Installed, R = Removed Name Version Description I performer_eoe 717115117 IRIS Performer Execution Environment I performer_eoe.sw 1006000142 Performer Execution Software I performer_eoe.sw.data 1006000142 Performer Demo Databases I performer_eoe.sw.demo 1006000142 Performer Demos I performer_eoe.sw.performer 1006000142 Performer Runtime Shared Libraries __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Tue Feb 15 01:53:23 1994 From: "Ran Yakir" Message-Id: <9402151152.ZM9341@fred.bvr.co.il> Date: Tue, 15 Feb 1994 11:52:13 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: pfChanFOV Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi I'm using a beta release of Performer 1.2. It seems that pfChanFOV (chan, horiz, vert), always sets the vertical fov to comply with the horizontal fov and the dimensions of the viewport. According to the man page, this should not be the case if I specify both the horizontal and the vertical fov. The automatic setting of the vertical fov should happen only if it is defined as -1.0. Is this a bug, or a still undocumented feature ? bye Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From aschaffe Tue Feb 15 04:20:07 1994 From: aschaffe (Allan Schaffer) Message-Id: <9402150404.ZM27438@holodeck.asd.sgi.com> Date: Tue, 15 Feb 1994 04:04:25 -0800 In-Reply-To: Michael Macedonia "performer crash on crimson" (Feb 14, 9:28am) References: X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: Michael Macedonia Subject: Re: performer crash on crimson Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 14, 9:28am, Michael Macedonia wrote: > > Having problems running an app using performer 1.0 on a Crimson RE. > It crashes every time. Runs fine on our challenge machines, Indigos, etc. > > Question: are there any known problems running performer on Crimson's ? There aren't any general incompatibilities with Crimsons. Being a Crimson RE, I assume you're running IRIX 4.0.5G or H. Do you get any error or warning messages? (in the shell, console window, or /usr/adm/SYSLOG) There are a few bugs that could cause core dumps in 1.0, (pfFlatten on a zero-length pfGeoSet, intersections with pfSwitches that were "off", and intersections with non-indexed quads). The FAQ list hasn't been updated for a while, but it does contain a list of all the bugs I knew of when it was put together. Also, the libgl on each of the Indigo-series machines is wildly different than the libgl for RE, so you should verify that you are compiling with the shared libraries. (both performer and libgl). Or, try compiling on the Crimson. I couldn't quite infer from your message whether the crash was the application or the entire graphics pipe -- if the latter, a test case to the hotline would be the fastest way to get bugs filed & track it down. If the application is crashing, a stack trace from dbx would be the way to go. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Feb 17 02:11:45 1994 Message-Id: <9402171011.AA05241@sgi.sgi.com> Date: Thu, 17 Feb 94 05:11:42 EST From: M904662P@ISOBB3.PWFL.COM To: info-performer@sgi.sgi.com Subject: Commercial & Military Aircraft Models Status: O From: Marcus Rothstein Deutsche Aerospace (Dasa), Munich, GERMANY Phone: 011-49-89-607-28312 FAX: 011-49-89-607-22491 ----------------------------------------------------------------------- Subject: Commercial & Military Aircraft Models We are interested in receiving catalogs, listings, prices, and availability for many commercial and military aircraft models. The models should have multiple levels-of-detail and have separate customer modifiable texture for various airlines. Can anyone who has a wide variety of off-the-shelf models available, please respond directly by: Mail, Fax, or E-Mail ? Aircraft desired range from Boeing, Airbus, McD-Douglas large commercial liners, to mid-size jets, commuters, private, executive, and military fighter, transport, and others etc. All international makes and models. Helicopters too. Perhaps someone knows of a library of models? Thanks ! Marcus Mail Address: Dasa, Aircraft Div.; Dept LME51, Bldg 70N; 81663 Munich Germany Internet Address: rothstmd@pwfl.com ----------------------------------------------------------------------- From aschaffe Thu Feb 17 03:40:18 1994 From: aschaffe (Allan Schaffer) Message-Id: <9402170340.ZM8342@holodeck.asd.sgi.com> Date: Thu, 17 Feb 1994 03:40:08 -0800 In-Reply-To: M904662P@ISOBB3.PWFL.COM "Commercial & Military Aircraft Models" (Feb 17, 5:11am) References: <9402171011.AA05241@sgi.sgi.com> X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: M904662P@ISOBB3.PWFL.COM Subject: Re: Commercial & Military Aircraft Models Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 17, 5:11am, M904662P@ISOBB3.PWFL.COM wrote: > > We are interested in receiving catalogs, listings, prices, and > availability for many commercial and military aircraft models. The > models should have multiple levels-of-detail and have separate > customer modifiable texture for various airlines. Can anyone who has > a wide variety of off-the-shelf models available, please respond > directly by: Mail, Fax, or E-Mail ? Aircraft desired range from > Boeing, Airbus, McD-Douglas large commercial liners, to mid-size > jets, commuters, private, executive, and military fighter, transport, > and others etc. All international makes and models. Helicopters too. > Perhaps someone knows of a library of models? One vendor that I'm aware of is Viewpoint Datalabs in Orem, Utah (USA). According to their catalog you can reach them at 1-800-DATASET, or from outside the US at (801) 224-2222. Note: Please don't interpret this as an endorsement of Viewpoint over other vendors. If anyone has pointers to other vendors I'd be happy to collect a list for the FAQ. Also, Performer 1.2 will include a large ( > 300 Mb) set of models from various vendors & popular databases in an optionally-loaded subsystem. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Feb 17 05:06:36 1994 Message-Id: <9402171306.AA15239@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Feb 1994 08:06:28 -0500 To: M904662P@ISOBB3.PWFL.COM, info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: Re: Commercial & Military Aircraft Models Status: O >From: Marcus Rothstein Deutsche Aerospace (Dasa), Munich, GERMANY >Phone: 011-49-89-607-28312 FAX: 011-49-89-607-22491 >----------------------------------------------------------------------- >Subject: Commercial & Military Aircraft Models > >We are interested in receiving catalogs, listings, prices, and availability >for many commercial and military aircraft models. The models should have >multiple levels-of-detail and have separate customer modifiable texture for >various airlines. Can anyone who has a wide variety of off-the-shelf models >available, please respond directly by: Mail, Fax, or E-Mail ? Aircraft desired >range from Boeing, Airbus, McD-Douglas large commercial liners, to mid-size >jets, commuters, private, executive, and military fighter, transport, and >others etc. All international makes and models. Helicopters too. Perhaps >someone knows of a library of models? > > Thanks ! > Marcus > Mail Address: Dasa, Aircraft Div.; Dept LME51, Bldg 70N; 81663 Munich Germany > Internet Address: rothstmd@pwfl.com >----------------------------------------------------------------------- Try Viewpoint DataLabs in Orem, Utah, USA. I counted over 100 airplane/spacecraft models and I didn't bother to count how many helicopters. Unfortunately, they are polygon data only, no texture, but it is a start. Their address and phone number is Viewpoint DataLabs 870 West Center Orem, UT 84057, USA 1-800-DATASET in the US (801) 224-2222 FAX (801) 224-2272 They have a catalog (I am looking at the Volume II Dataset Catalog). They offer all of their models in more than 52 different formats and do custom work also. I haven't used any of their models, but I have seen them used in lots of different projects. John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From guest Thu Feb 17 07:06:14 1994 Date: Thu, 17 Feb 94 08:32:49 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9402171332.AA02011@ldsa.com> To: info-performer@sgi.sgi.com Status: O Has anybody done any work in developing a way to load DTED elevation into Performer? I have elevation tiles which are very similar to DTED which I need to load. John Templeton at SGI thought that it was very likely that this work would have been done already. If anyone has done this, I would be interested in seeing how it was done. Along with this, I need to model a lighthouse type rotating light. I am using Performer 1.0 on an Indigo2 Extreme, so I don't have the pfLightSource from the 1.2 beta version. I have not been hiving much luck in modeling local light sources. Again, I would appreciate any advice on how this may best be accomplished. Thanks Mike Williams mwilliam@ldsa.com From guest Thu Feb 17 05:50:14 1994 Date: Thu, 17 Feb 94 05:49:58 -0800 From: ib@ivan (Ivan Bach) Message-Id: <9402171349.AA20959@ivan.asd.sgi.com> To: M904662P@ISOBB3.PWFL.COM, info-performer@sgi.sgi.com Subject: Re: Commercial & Military Aircraft Models Status: O You can get all kinds of 3D models in various formats from: avalon.chinalake.navy.mil (129.131.31.11) by using anonymous ftp. That is apparently the main ftp host for 3D models (objects) on Internet. Ivan Bach, ib@sgi.com From guest Thu Feb 17 06:44:02 1994 From: "Craig Phillips" Message-Id: <9402170824.ZM21760@binky.paradigmsim.com> Date: Thu, 17 Feb 1994 08:24:20 -0600 In-Reply-To: M904662P@ISOBB3.PWFL.COM "Commercial & Military Aircraft Models" (Feb 17, 5:11am) References: <9402171011.AA05241@sgi.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: M904662P@ISOBB3.PWFL.COM Subject: Re: Commercial & Military Aircraft Models Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Feb 17, 5:11am, M904662P@ISOBB3.PWFL.COM wrote: > Subject: Commercial & Military Aircraft Models > From: Marcus Rothstein Deutsche Aerospace (Dasa), Munich, GERMANY > Phone: 011-49-89-607-28312 FAX: 011-49-89-607-22491 > ----------------------------------------------------------------------- > Subject: Commercial & Military Aircraft Models > > We are interested in receiving catalogs, listings, prices, and availability > for many commercial and military aircraft models. The models should have > multiple levels-of-detail and have separate customer modifiable texture for > various airlines. Can anyone who has a wide variety of off-the-shelf models > available, please respond directly by: Mail, Fax, or E-Mail ? Aircraft desired > range from Boeing, Airbus, McD-Douglas large commercial liners, to mid-size > jets, commuters, private, executive, and military fighter, transport, and > others etc. All international makes and models. Helicopters too. Perhaps > someone knows of a library of models? > Paradigm Simulation Inc. has an extensive set of military and commercial aircraft models. We also have a large set of ground vehicle models. All of these models are in Multigen Flight format and have 3-5 levels of detail and are fully textured. Most are in use in various simulators around the world. Contact Mike Smoot at 214-960-2301. -- __________________________________________________ Craig Phillips Paradigm Simulation Inc. 15280 Addison Rd. Dallas, Texas 75248 craig@paradigmsim.com 214-960-2301 __________________________________________________ From guest Thu Feb 17 14:44:16 1994 Date: Thu, 17 Feb 94 14:43:49 PST From: penafiel@guild.rdd.lmsc.lockheed.com (Hugo Penafiel) Message-Id: <9402172243.AA12773@guild.rdd.lmsc.lockheed.com> To: mwilliam@ldsa.com, info-performer@sgi.sgi.com Subject: DTED loader Status: O The only two companies I know that have a DTED to MultiGen Flight Format converter are Software Systems Inc. in San Jose, CA and Coryphaeus Software in Los Gatos, CA. I have an address and phone number for Coryphaeus: 985 University Ave., Suite 31 Los Gatos, CA 95030 Phone: (408) 395-4537 Fax: (408) 395-6351 Good luck! Hugo Penafiel Phone: (415) 424-2913 e-mail: penafiel@guild.rdd.lmsc.lockheed.com Research & Development Division Lockheed Missiles & Space Co. Palo Alto, CA From guest Thu Feb 17 23:48:33 1994 From: Robert Webb Message-Id: <199402180748.AA14301@godzilla.cgl.citri.edu.au> Subject: Performer questions To: info-performer@sgi.sgi.com Date: Fri, 18 Feb 1994 18:48:21 +1100 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2181 Status: O Howdy all, I have a few Performer questions for anyone who feels like helping out: - The Performer documentation we have describes a function pfGlobalGState(), but this function does not seem to actually exist (and there is no prototype for it in the header file). How do I set up global pfGeoState defaults without it? - In one of our applications at least, the culling does not work properly. Objects suddenly vanish before they leave the viewing frustrum. Any ideas why this could be? We are not changing any of the GeoSets or other data in the hierarchy after it has been initially set up. - I've read the pfLight man page and I'm still not sure how to position lights properly. It says that for lights like the sun, which have a fixed position in the world, pfLightOn() should be called every frame with only the viewing transformation on the matrix stack. I understand the concept, but how do I actually do it? Performer does all the drawing and transformations for you so do I need some sort of call-back to call pfLightOn() at the right moment? If I set up lights in a pfGeoState with: pfGStateAttr(gstate, PFSTATE_LIGHTS, lights); and associate this with a pfGeoSet, then is that the same as using pfLightOn() with the modelling transformations for that GeoSet on the stack? That is, will the lights then move with the object like lights on a car? Or does this simply use the lights but not affect their position? Do you still need to call pfLightOn()? Again I would like to use pfGlobalGState() to define global non-moving lights, but this is unavailable. - Ultimately it would be nice if pfGeoStates could be attached to any node, and inherited by children. A pfGroup which holds all the various geometry nodes for an object could then define materials etc. for all its children, without each pfGeoSet having to do this itself to override the global state. Does every little pfGeoSet really need its own pfGeoState? If so, is this efficient provided consecutive children use the same pfGeoState? Many thanks to anyone who answers any of these questions. -- Rob. (webb@godzilla.cgl.citri.edu.au) From guest Fri Feb 18 02:01:00 1994 Message-Id: <9402181003.AA23617@Crazypete.AI.SRI.COM> To: info-performer@sgi.sgi.com Subject: Clouds Date: Fri, 18 Feb 1994 02:03:04 -0800 From: Stephen Lau Status: O I would like to get a copy of the "clouds" texture that's used in Performer town as an SGI image if possible. The data that comes in /usr/demos/data/town is not in SGI image format. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "No, no, not Orwellian, HUXLEY! SRI International | Brave New World." 333 Ravenswood Ave., Menlo Park, CA. 94025| - George Coates, "Box Conspiracy: (415) 859-2925 (415) 326-6200| An Interactive Sho" ------------------------------------------------------------------------------- From guest Fri Feb 18 05:03:55 1994 Date: Fri, 18 Feb 94 13:03:02 GMT Message-Id: <223.9402181303@prsun11z.prl.philips.co.uk> To: info-performer@sgi.sgi.com Subject: 3D studio to IRIS Performer ? Status: O Hi there! I want to read 3D studio format files into IRIS Performer. Does anyone now what's the best way of doing that? Has anyone tried it already? Please send your comments to: ukrsefe@prl.philips.co.uk Thanx! Dr. Vassilis Seferidis From holodeck.asd.sgi.com!guest Fri Feb 18 10:10:51 1994 remote from uunet 10:10:51 -0500 for uunet.uu.net!multigen!marcus id AA21749; Fri, 18 Feb 94 06:44:24 -0800 06:38:31 -0800 for /usr/lib/sendmail info-performer-dist id AA16502; Fri, 18 Feb 94 06:38:30 -0800 for info-performer@holodeck.asd.sgi.com id AA15279; Fri, 18 Feb 94 06:38:29 -0800 for info-performer@giraffe.asd.sgi.com id AA21158; Fri, 18 Feb 94 06:38:15 -0800 To: sgi.com!info-performer Subject: Loadflt Callback And Pfnodes Date: Fri, 18 Feb 94 15:37:56 CET From: "Infobyte S.R.L." Message-Id: <9402181537.aa19654@ax433.mclink.it> Status: O Hi all, I am "playing" with Performer1.2a81.irix5 beta and I have experienced a strange behavior: I am using the callback functions with LoadFlt routine. At loading time (in the callback function), I print the addresses of the Performer nodes and their names that are (by default) the same of MultiGen ones. When, after in the application, I print the same addresses (from the pfHit structure after a collision I can obtain the Geodes), they are different for the objects. I am sure that the nodes are the right ones because I know the polygons of the objects and because if I print the adresses and names of the Parents of the nodes, they are the right ones. Further when I try to find the addresses of the objects by name with pfFind, it doesn't work for them (NULL return values), but it works fine for the parent groups or lods. It seems that the objects' addresses are in some way changed and their names deleted, while groups' and lods' are not. Is it possible or is there anything else I have to do (or not to do!). Thank you in advance for any help. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Fri Feb 18 06:38:30 1994 To: info-performer@sgi.sgi.com Subject: Loadflt Callback And Pfnodes Date: Fri, 18 Feb 94 15:37:56 CET From: "Infobyte S.R.L." Message-Id: <9402181537.aa19654@ax433.mclink.it> Status: O Hi all, I am "playing" with Performer1.2a81.irix5 beta and I have experienced a strange behavior: I am using the callback functions with LoadFlt routine. At loading time (in the callback function), I print the addresses of the Performer nodes and their names that are (by default) the same of MultiGen ones. When, after in the application, I print the same addresses (from the pfHit structure after a collision I can obtain the Geodes), they are different for the objects. I am sure that the nodes are the right ones because I know the polygons of the objects and because if I print the adresses and names of the Parents of the nodes, they are the right ones. Further when I try to find the addresses of the objects by name with pfFind, it doesn't work for them (NULL return values), but it works fine for the parent groups or lods. It seems that the objects' addresses are in some way changed and their names deleted, while groups' and lods' are not. Is it possible or is there anything else I have to do (or not to do!). Thank you in advance for any help. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Fri Feb 18 09:09:52 1994 Date: Fri, 18 Feb 94 09:10:04 -0800 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9402181710.AA16892@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: RE: Performer questions Status: O On Fri, 18 Feb 1994 18:48:21 +1100 (EDT) Robert Webb writes: >- In one of our applications at least, the culling does not work properly. > Objects suddenly vanish before they leave the viewing frustrum. Any ideas > why this could be? We are not changing any of the GeoSets or other data in > the hierarchy after it has been initially set up. I assume you are using Performer 1.0 because we had the same problem. Ours occurred when we scaled a pfDCS with pfDCSScale. This was useful for instancing our data set. A once-defined box from a procedure for creating pfGeoSets could be scaled to the particular task. Some of our boxes vanished before the edge of our frustum. We tested and found that the problem got worse with more scaling. On Fri, 16 Jul 93 18:41:18 -0700 Jim Helman writes: > There is a culling bug for scaled DCSes > which was fixed in Release 1.1. 1.1 only > was released for IRIX 5.0. Our work-around was to scale the data-points as the pfGeoSet was created. However, in the example coloredbox.c all points are statically defined. Therefore the points must be dynamically allocated: static pfGeoSet *MakePalmGSet( float scale, pfGeoState *gstate) { void *arena; int i; pfVec3 *scaled_scoords; pfGeoSet *gset; static pfVec3 scoords[] = {{-2.00f,-.50f, 3.75f }, { 2.00f,-.50f, 3.75f }, { 2.00f, .50f, 3.75f }, {-2.00f, .50f, 3.75f }, {-1.25f,-.75f, 0.00f }, { 1.75f,-.75f, 0.00f }, { 1.75f, .75f, 0.00f }, {-1.25f, .75f, 0.00f }, { 2.00f,-.68f, 1.00f }, { 2.00f, .68f, 1.00f }}; static ushort svindex[] = {0, 1, 2, 3, /* front */ 0, 3, 7, 4, /* left */ 4, 7, 6, 5, /* back */ 1, 8, 9, 2, /* right */ 8, 5, 6, 9, /* right/bottom */ 3, 2, 6, 7, /* top */ 0, 4, 5, 1}; /* bottom */ static pfVec3 snorms[] = {{ 0.000f, 0.000f,-1.000f}, { 0.981f, 0.000f, 0.196f}, { 0.000f, 0.000f, 1.000f}, {-1.000f, 0.000f, 0.000f}, {-0.707f, 0.000f, 0.707f}, { 0.000f,-0.998f,-0.067f}, { 0.000f, 0.998f,-0.067f}}; static ushort snindex[] = {0, 1, 2, 3, 4, 5, 6}; static ushort scindex[] = {20, 20, 20, 20, 20, 20, 10, 0, 0, 10, 10, 0, 20, 5, 15, 20, 5, 0, 10, 15, 20, 20, 10, 10, 20, 0, 0, 20}; arena = pfGetSharedArena(); scaled_scoords = (pfVec3 *)pfMalloc( sizeof( pfVec3[8] ), arena ); for( i = 0; i < 8; i++ ) PFSCALE_VEC3( scaled_scoords[i], scale, scoords[i] ); gset = pfNewGSet( arena ); pfGSetCtabMode( gset, PF_ON ); pfGSetAttr( gset, PFGS_COORD3, PFGS_PER_VERTEX, scaled_scoords, svindex ); pfGSetAttr( gset, PFGS_NORMAL3, PFGS_PER_PRIM, snorms, snindex ); pfGSetAttr( gset, PFGS_COLOR4, PFGS_PER_VERTEX, NULL, scindex ); pfGSetPrimType( gset, PFGS_QUADS ); pfGSetNumPrims( gset, 7 ); pfGSetGState( gset, gstate ); return( gset ); } Hope this is useful. Of course 1.2 (hopefully) comes out in March and all of this will be obsolete. :^) From guest Sat Feb 19 16:14:26 1994 Date: Sat, 19 Feb 94 19:14:23 -0500 From: hildebra@indy.vsl.ist.ucf.edu (Andrew Hildebrand ) Message-Id: <9402200014.AA19975@indy.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: Projected Texture Cc: hildebra@indy.vsl.ist.ucf.edu Status: O I was wondering how you use projected textureing, I saw the demo on the ONYX and I saw the screen shots in the brochure. I noticed that the ONYX demo was very small, about 49K. Can you release the code for the demo or does someone have code for Projected Texture, I was particularly interested in the Spotlight screen shot, I would like to implement something like that I my project. THANKS ______________________________________________________________________________ Andrew Hildebrand The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) hildebra@vsl.ist.ucf.edu _______________________________________________________________________________ From guest Sun Feb 20 03:53:10 1994 From: "Ran Yakir" Message-Id: <9402201351.ZM3950@fred.bvr.co.il> Date: Sun, 20 Feb 1994 13:51:43 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Zbuffer bug Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi There is a known Z buffer bug in Reality Engine machines, that causes the zclear() command to clear the Z buffer to 0x7fffff00, even when getgdesc(GD_ZMAX) or getgconfig(GC_ZMAX) or getgconfig(GC_MS_ZMAX) ays that the Z max value is 0x7f800000. lsetdepth() has no effect on that too. Now, it seems that Performer does the same thing, i.e. clear the Z buffer to 0x7fffff00 regardless of anything. This could be OK if Performer would lsetdepth() to the same value. Right now it doesn't and an inconsistency occures if you try to interpret Z buffer data. Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Sun Feb 20 06:25:31 1994 From: "Ran Yakir" Message-Id: <9402201624.ZM4127@fred.bvr.co.il> Date: Sun, 20 Feb 1994 16:24:18 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Zbuffer bug Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi There is a known Z buffer bug in Reality Engine machines, that causes the zclear() command to clear the Z buffer to 0x7fffff00, even when getgdesc(GD_ZMAX) or getgconfig(GC_ZMAX) or getgconfig(GC_MS_ZMAX) ays that the Z max value is 0x7f800000. lsetdepth() has no effect on that too. Now, it seems that Performer does the same thing, i.e. clear the Z buffer to 0x7fffff00 regardless of anything. This could be OK if Performer would lsetdepth() to the same value. Right now it doesn't and an inconsistency occures if you try to interpret Z buffer data. Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Sun Feb 20 15:30:17 1994 From: Robert Webb Message-Id: <199402202329.AA18526@godzilla.cgl.citri.edu.au> Subject: Re: Performer questions To: info-performer@sgi.sgi.com Date: Mon, 21 Feb 1994 10:29:50 +1100 (EDT) In-Reply-To: <9402181710.AA16892@niesten.arc.nasa.gov> from "William Briggs" at Feb 18, 94 09:10:04 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1359 Status: O > On Fri, 18 Feb 1994 18:48:21 +1100 (EDT) > Robert Webb writes: > > >- In one of our applications at least, the culling does not work properly. > > Objects suddenly vanish before they leave the viewing frustrum. Any ideas > > why this could be? We are not changing any of the GeoSets or other data in > > the hierarchy after it has been initially set up. > > I assume you are using Performer 1.0 because we had the same problem. > Ours occurred when we scaled a pfDCS with pfDCSScale. This was useful > for instancing our data set. A once-defined box from a procedure for > creating pfGeoSets could be scaled to the particular task. Some of our > boxes vanished before the edge of our frustum. We tested and found that > the problem got worse with more scaling. > > On Fri, 16 Jul 93 18:41:18 -0700 > Jim Helman writes: > > > There is a culling bug for scaled DCSes > > which was fixed in Release 1.1. 1.1 only > > was released for IRIX 5.0. Thanks for the advice, but we aren't using any pfDCS nodes at all! Only pfSCS nodes. We are using Performer 1.0 though. Is there an easy way to show the bounding boxes in performer? Or does anyone have code to do this? Maybe the boxes somehow aren't being created correctly, but this seems unlikely. -- Rob. (webb@godzilla.cgl.citri.edu.au) From guest Mon Feb 21 02:31:25 1994 Message-Id: <9402211031.AA01045@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Re: Performer questions In-Reply-To: Your message of "Mon, 21 Feb 94 10:29:50 +1100." <199402202329.AA18526@godzilla.cgl.citri.edu.au> Date: Mon, 21 Feb 94 02:31:19 -0800 From: Jim Helman Status: O > > On Fri, 16 Jul 93 18:41:18 -0700 > > Jim Helman writes: > > > > > There is a culling bug for scaled DCSes > > > which was fixed in Release 1.1. 1.1 only > > > was released for IRIX 5.0. > > Thanks for the advice, but we aren't using any pfDCS nodes at all! > Only pfSCS nodes. pfSCSes were affected as well, but for performance, are usually pfFlattened out of the scene graph by run time. Generally, it's best to avoid run-time scales, especially non-uniform ones, becuase they require rescaling or renormalization of normals in the gfx pipe. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Feb 22 09:33:04 1994 From: Bernd Froehlich Message-Id: <9402221633.AA09760@viswiz.gmd.de> Subject: Transparency To: info-performer@sgi.sgi.com Date: Tue, 22 Feb 94 18:18:09 MET Status: O Hello, how is transparency realized in Performer? In GL one has to render the opaque polygons first, then the transparent ones in decreasing order of distance from the eyepoint. Sorting is usually too expensive, so just drawing the opaque polygons first and the transparent ones last is ok for most cases. Is this supported in Performer and how? Thanks --Bernd bernd@viswiz.gmd.de From guest Tue Feb 22 10:36:31 1994 Message-Id: <9402221835.AA17909@surreal.asd.sgi.com> To: Bernd Froehlich Cc: info-performer@sgi.sgi.com Subject: Re: Transparency In-Reply-To: Your message of "Tue, 22 Feb 94 18:18:09 +0700." <9402221633.AA09760@viswiz.gmd.de> Date: Tue, 22 Feb 94 10:35:04 -0800 From: Jim Helman Status: O By default, Performer draws all transparent geosets and billboards (which are usually transparent) last. The rendering order is less important when using multisample transparency (msalpha == screendoor) than when using blendfunction. But with blended alpha, you pick up the color of the last thing drawn behind the partially transparent object, which is often not the correct backdrop. Fortunately, msalpha is our default on Reality Engine. The downside is fewer alpha levels. Note that node draw callbacks disable the draw-last feature since the geometry in the subgraph rooted at that node must be drawn within the scope of its pre/post draw callbacks. If anyone has a need for better sorting, e.g. someone needs lots of blended alpha billboards, they should contact us. We have ways. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From: Bernd Froehlich Subject: Transparency To: info-performer@sgi.sgi.com Date: Tue, 22 Feb 94 18:18:09 MET Hello, how is transparency realized in Performer? In GL one has to render the opaque polygons first, then the transparent ones in decreasing order of distance from the eyepoint. Sorting is usually too expensive, so just drawing the opaque polygons first and the transparent ones last is ok for most cases. Is this supported in Performer and how? Thanks --Bernd bernd@viswiz.gmd.de From guest Wed Feb 23 03:36:30 1994 Date: Wed, 23 Feb 94 13:35:26 +0200 From: rany@bvr.co.il (Ran Yakir) Message-Id: <9402231135.AA01002@rea1.bvr.co.il> To: info-performer@sgi.sgi.com Subject: draw callbacks bug in performer 1.2 Status: O Hi I'm using Performer 1.2 beta, and experiencing the following problem : When assigning a post draw callback for a node, without assigning a pre draw callback (sending NULL), the post draw callback is called at the beginning of the pfDraw, regardless of everything, and before the actual drawing of that node take place. When assigning both post draw and pre draw callbacks, everything works fine. Are you aware of that ? I can compose a small example if needed. Thanks Ran Yakir __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From mclink.it!MC9258 Wed Feb 23 06:25:47 1994 remote from uunet To: multigen!paul Subject: Loadflt & Callback Date: Wed, 23 Feb 94 12:25:30 CET From: "Infobyte S.R.L." Message-Id: <9402231225.aa15991@ax433.mclink.it> Status: O Hi Paul, it works. Disabling cleanTree the nodes don't disappear and can be obtained as parents of the intersected objects (they are transformed in Performer groups), i.e. pfNode *node; pfQueryHits(hits[0][0], PFQHIT_NODE, &node) printf ( "%s", pfGetNodeName ( pfGetParent(node, 0) ) ); And enabling cleanTree, the callback with CB_CLEANNODE detects that the nodes are effectively deleted by that function. Thank you. Three more questions: 1) How much performance is lost, disabling cleanTree? 2) I have noticed that, in my case, MultiGen objects are deleted, but MultiGen groups are not. Is this a general rule, so I can work with groups if I don't want an "object" deleted, or I have to verify every time with CB_CLEANNODE? 3) In the README.SS file is written that with the CB_CLEANNODE "the application can take the appropriate actions". Which are these appropriate actions? Is there a way to know which is the new address of the node? Thank you again. Massimo Cuomo - Infobyte - mc9258@mclink.it ========================================= MAILBOX Msg# 62445, 22/02/94 21:10 [4095] Da: Paul@multigenuunet.uu.net A : MC9258 Infobyte S.R.L. ----------------------------------------- Oggetto: Re: FWD>Loadflt Callback And From ammi.mclink.it!relay2.uu.net!uunet.uu.net!multigen!paul Tue Feb 22 21:08:44 1994 remote from ax433 CET 15:06:08 -0500 id AA01128; Tue, 22 Feb 1994 12:06:11 PST Message-Id: <00581.2844763571.1128@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: Infobyte S.R.L. From: Paul To: "Infobyte S.R.L." Date: Tue, 22 Feb 1994 10:13:23 PST Subject: Re: FWD>Loadflt Callback And Reply to: RE>FWD>Loadflt Callback And Pfnode Dear Massimo, My name is Paul Mlyniec. I have been maintaining the Flight format loader for some time. I would guess that your problem stems from cleanTree removing the nodes of interest. You can disable the call to cleanTree with a call to LoadFltMode() to test this hypothesis. (See README.SS in /usr/src/Performer/src/lib/libpfflt). Also note the CB_CLEANNODE callback in README.SS. Feel free to call me if you are still having problems. My phone number is (408) 261-4123. Please let me know how this turns out in any case, so that I can pass along the info to others. Thanks. Paul Mlyniec Software Systems 1884 The Alameda San Jose, CA 95126 (408) 261-4123 multigen!paul@uunet.UU.NET -------------------------------------- Date: 2/18/94 9:16 AM To: Paul From: Marcus From guest Wed Feb 23 09:44:53 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9402231744.AA03320@tubes.asd.sgi.com> Subject: Re: draw callbacks bug in performer 1.2 To: guest (Ran Yakir) Date: Wed, 23 Feb 94 9:44:38 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9402231135.AA01002@rea1.bvr.co.il>; from "Ran Yakir" at Feb 23, 94 1:35 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi > > I'm using Performer 1.2 beta, and experiencing the following problem : > When assigning a post draw callback for a node, without assigning a > pre draw callback (sending NULL), the post draw callback is called at the > beginning of the pfDraw, regardless of everything, and before the actual > drawing of that node take place. > When assigning both post draw and pre draw callbacks, everything works fine. > Are you aware of that ? > I can compose a small example if needed. > Which beta do you have? I believe this bug has been fixed in the latest beta which is 94. Sorting was only disabled if you had a preDraw callback. A simple workaround is to assign a dummy preDraw callback or to install the newest beta. From guest Wed Feb 23 16:21:31 1994 Message-Id: <00581.2844865374.1132@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 23 Feb 1994 16:05:18 PST Subject: Re: Loadflt & Callback Status: O Reply to: RE>Loadflt & Callback Dear Massimo, Thanks for getting back to me with the good news. I'll post the results for the general public now. As for your followup questions: 1) The cost of disabling cleanTree is not great. Traversal of additional pfNodes is the price you pay and this is not so bad. 2) It is true that MultiGen objects are generally deleted. This is because they are converted to pfGroups mostly to preserve their names in the scene graph. Certain hierarchies can cause groups to disappear as well, so I would recommend using the CB_CLEANNODE callback for protection. You also have the option of obtaining the source to modify the behavior of cleanTree. For instance, you could tag pfGroups that correspond to objects so that cleanTree leaves them alone. Incidentally, future revisions of the loader will probably allow the application to veto the deletion of pfNodes by cleanTree. 3) "Appropriate action" generally means that the application [can] no longer count on the existence of the soon-to-be-deleted node. Unfortunately, the node has already been unlinked from the scene graph when you are called with a CB_CLEANNODE. It is to late to change this for the current release of the loader, but again, you could obtain the source and reverse the order of the unlink and callback calls. Good Luck, Paul Mlyniec Software Systems -------------------------------------- Date: 2/23/94 7:55 AM To: Paul From: Infobyte S.R.L. From guest Fri Feb 25 08:56:25 1994 From: Renee Strong Message-Id: <9402251656.AA06101@pat.mdc.com> Subject: bounding boxes To: info-performer@sgi.sgi.com Date: Fri, 25 Feb 94 10:56:13 CST X-Mailer: ELM [version 2.3 PL11] Status: O I have performer 1.0 running on a personal IRIS. If I understand the documentation right, using pfNodeBBox with the pfBox NULL and the matrix NULL should have performer create a bounding box for me. I am getting back all zeros in the pfBox structure. I am trying to get performer to create a bounding box around a pfGeode. The pfGeode is not attached to a pfDCS or anything else for that matter. What am I doing wrong??? pfGeode *geode; pfBox *bbox = NULL; geode = loadModel(); if (!geode) return(NULL); pfNodeBBox(geode, bbox, NULL, PFN_BMODE_STATIC); cout << "bbox->min:"<min[0]<min[1]<min[2]<<"\n"; cout << "bbox->max:"<max[0]<max[1]<max[2]<<"\n"; Thanks Renee Strong renee@pat.mdc.com From giraffe.asd.sgi.com!sgi.sgi.com!enterprise.ctaeng.com!bwana.mss.ctaeng.com!buckley Fri Feb 25 16:41:37 1994 Date: Fri, 25 Feb 94 16:01:15 -0700 From: buckley@bwana.mss.ctaeng.com ("Bwana" Bob Buckley) Message-Id: <9402252301.AA26517@bwana.mss.ctaeng.com> To: info-performer-dist Subject: Subscribe Status: O subscribe =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd., Suite #200 Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 buckley@bwana.mss.ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Sun Feb 27 20:23:50 1994 From: fraser@BanffCentre.AB.CA (Glen Fraser) Message-Id: <9402280412.AA19045@moose.BanffCentre.AB.CA> Subject: Texture matrix transformations To: info-performer@sgi.sgi.com Date: Sun, 27 Feb 1994 21:12:38 -0700 (MST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 657 Status: O I am trying to apply textures using different texture transformation matrices. Is there some way I can link the texture transformation matrix to the pfGeoState, so that the MTEXTURE matrix is modified automatically on a per-texture basis? Thanks, Glen. ------------------------------------------------------------------ | Glen D. Fraser | fraser@banffcentre.ab.ca | | Work: (403)762-6669 | | | Virtual Reality Developer | "Let it well be known, | | The Banff Centre for the Arts | These opinions are my own." | ------------------------------------------------------------------ From guest Sun Feb 27 23:39:12 1994 Message-Id: <9402280738.AA16587@surreal.asd.sgi.com> To: fraser@banffcentre.ab.ca (Glen Fraser) Cc: info-performer@sgi.sgi.com Subject: Re: Texture matrix transformations In-Reply-To: Your message of "Sun, 27 Feb 94 21:12:38 MST." <9402280412.AA19045@moose.BanffCentre.AB.CA> Date: Sun, 27 Feb 94 23:38:50 -0800 From: Jim Helman Status: O I am trying to apply textures using different texture transformation matrices. Is there some way I can link the texture transformation matrix to the pfGeoState, so that the MTEXTURE matrix is modified automatically on a per-texture basis? Nope. You'll need to use a pre-draw callbacks on the pfGeodes to change the texture matrix for the included pfGeoSets (best to restore the matrix in the pfGeode's post-draw callback). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151