From aschaffe Wed Oct 6 04:40:36 1993 Date: Wed, 6 Oct 93 04:14:18 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9310061114.AA05442@holodeck.asd.sgi.com> To: info-performer Subject: Mailing List Status: ORS [ Administrative note: A move of the list server machine had prevented us from activating the list until now, 10/06/93. Thank you to everyone for your patience. Mail may still be sluggish, but the list is now re-activated. - Allan] This email is to acknowledge that your request to be added to the IRIS Performer mailing list has been processed. Thank you for subscribing! We're glad to add you to the list. POSTING INSTRUCTIONS: When you post, your email will be immediately forwarded to everyone on the mailing list. To post, send your message to: info-performer@sgi.com 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 GENERAL GUIDELINES: We've intended this list to be both technical and non-technical (leaning towards technical) and to be an unmoderated, free-form discussion of IRIS Performer. It must be very clear that this list is not an official support channel. Think of it much in the same way you would a newsgroup -- questions are asked, most get answered publically, some are taken off-line into private email conversations, and of course, some aren't answered. A few things that can be best brought up by Q&A: Q: Is this list archived anywhere? A: Yes, all articles posted will be saved. A retrieval method will be made available soon. Q: Can/Should I post code to the list? A: Use your good judgement. If it's short, sure. If it's long, maybe. If it spans multiple files with 100K of test data, please don't. Q: Can/Should I report bugs to the list? A: You are encouraged to report bugs to your support provider, but feel free to investigate bugs with the subscribers of the list. Q: When will I receive a FAQ? A: Very, very soon. This list is new enough to form in many different ways; if you have questions or comments, please send mail to the list administrator. ---- Allan Schaffer x3-2160 Silicon Graphics aschaffe@sgi.com From aschaffe Wed Oct 6 13:44:39 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310061344.ZM7455@holodeck.asd.sgi.com> Resent-Date: Wed, 6 Oct 1993 13:44:38 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer From: giraffe.asd.sgi.com!rock.csd.sgi.com!oni.sgi.com!eurohub.neu.sgi.com!oslo.sgi.com!roald.oslo.sgi.com!roald (Roald Lygre) Message-Id: <9310061355.ZM14039@roald.oslo.sgi.com> Date: Wed, 6 Oct 1993 13:55:57 +0100 X-Mailer: Z-Mail (2.1.0 10/1/92) To: info-performer@sgi.sgi.com Subject: Performer 1.2 Status: O Hi everyone, just a quick question: A customer says that he has read about Performer 1.2 being available, and that he needs an upgrade. I have no info (availability, features, beta versions) on Performer 1.2 , do you? Roald -- ------------------------------------------------- - Roald Lygre - - Email: roald@oslo.sgi.com - - Tlf: +47 22 73 05 70 - ------------------------------------------------- From aschaffe Wed Oct 6 13:59:59 1993 From: aschaffe (Allan Schaffer) Message-Id: <9310061359.ZM7541@holodeck.asd.sgi.com> Date: Wed, 6 Oct 1993 13:59:59 -0700 In-Reply-To: giraffe.asd.sgi.com!rock.csd.sgi.com!oni.sgi.com!eurohub.neu.sgi.com!oslo.sgi.com!roald.oslo.sgi.com!roald (Roald Lygre) "Performer 1.2" (Oct 6, 1:55pm) References: <9310061355.ZM14039@roald.oslo.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer Subject: Re: Performer 1.2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 6, 1:55pm, Roald Lygre wrote: > Hi everyone, > > just a quick question: > > A customer says that he has read about Performer 1.2 being available, > and that he needs an upgrade. I have no info (availability, features, > beta versions) on Performer 1.2 , do you? > > Roald A Beta version of Performer 1.2 (alpha 55) is available for SGI internal folks right now to use for testing, porting, etc. I'll post installation instructions to the internal part of this list. Approx. 25 beta sites have already been chosen and have had the beta for the last month or so. There aren't any plans to add more sites to the beta list. Once I have an opportunity I'll post some info on 1.2 features. The actual release date for Performer 1.2 hasn't been set yet, but it would likely be around the end of the year. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From 00A4269@msgate.emis.hac.com Wed Oct 6 15:28:59 1993 Date: Wed, 6 Oct 93 15:28:50 PDT From: 00A4269@msgate.emis.hac.com Message-Id: <9310062228.AA22374@hac2arpa.hac.com> Subject: Flight format V. 12 Status: OR From: Miyagishima, Daryl K Date: Wed, Oct 6, 1993 3:26 PM Subject: Flight format V. 12 To: info-performer Hi everyone, Is there a version of the pfflt library out there that is compatible with version 12.0 of MultiGen. I am currently using Performer 1.0 and it is only compatible with version 11.0 of MultiGen. I am looking for compatibility in reading and dealing with textures. Thanks! Daryl Miyagishima Hughes Research Labs From aschaffe Wed Oct 6 15:39:56 1993 From: aschaffe (Allan Schaffer) Message-Id: <9310061539.ZM7947@holodeck.asd.sgi.com> Date: Wed, 6 Oct 1993 15:39:53 -0700 In-Reply-To: russo@rudedog.ait.nrl.navy.mil (Kevin Russo) "Wireframe PFGS_QUADS" (Oct 6, 6:20pm) References: <9310062220.AA13021@rudedog.ait.nrl.navy.mil> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: russo@rudedog.ait.nrl.navy.mil (Kevin Russo) Subject: Re: Wireframe PFGS_QUADS Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 6, 6:20pm, Kevin Russo wrote: > I've noticed when looking at models loaded by LoadSgo in the complex.c > demo or in perfly.c, that the quads have a stray line from one vertex to > some far away place when displayed in wireframe mode. I've verfied > that my sgo models don't contain any bogus verts/norms. In fact, the > problem is easy to see with a single quad in an sgo file. > > Is this just a bug in the internal Performer draw routine for > PFGS_QUADS primitives? Triangles, lines and flat shaded quads look ok. > > I'm using Performer 1.0 on an Indigo R3000 GR2-XS24/Z with Irix 4.0.5F. Yep, this is a bug in 1.0 and 1.1. If I remember correctly, it only happens on EXPRESS Graphics platforms (XS, XS24, ELAN, etc) with wireframe quads. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From aschaffe Wed Oct 6 16:09:10 1993 From: aschaffe (Allan Schaffer) Message-Id: <9310061609.ZM8082@holodeck.asd.sgi.com> Date: Wed, 6 Oct 1993 16:09:09 -0700 In-Reply-To: 00A4269@msgate.emis.hac.com "Flight format V. 12" (Oct 6, 3:28pm) References: <9310062228.AA22374@hac2arpa.hac.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: 00A4269@msgate.emis.hac.com Subject: Re: Flight format V. 12 Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 6, 3:28pm, 00A4269@msgate.emis.hac.com wrote: > > Is there a version of the pfflt library out there that is compatible with > version 12.0 of MultiGen. I am currently using Performer 1.0 and it is only > compatible with version 11.0 of MultiGen. I am looking for compatibility in > reading and dealing with textures. Thanks! > > Daryl Miyagishima > Hughes Research Labs A MultiGen 12 version of LoadFlt() is/will be included with Performer 1.2, but for those of you who need it now, it's my understanding that you can get it from Software Systems (the makers of MultiGen). I'd wager that a few people on the list have already done this, and can comment further.. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From aschaffe Wed Oct 6 22:02:19 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310062202.ZM9082@holodeck.asd.sgi.com> Resent-Date: Wed, 6 Oct 1993 22:02:19 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer From: "Michael Jones" Message-Id: <9310062159.ZM10207@babar.asd.sgi.com> Date: Wed, 6 Oct 1993 21:59:04 -0700 In-Reply-To: aschaffe@holodeck (Allan Schaffer) "Re: Flight format V. 12" (Oct 6, 4:09pm) References: <9310062228.AA22374@hac2arpa.hac.com> <9310061609.ZM8082@holodeck.asd.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: aschaffe (Allan Schaffer) Subject: Re: Flight format V. 12 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O For those looking for a version 12 loader right now, the contact at Software Systems is: Mr. Norm Miller Software Systems 1884 The Alameda San Jose, CA 95126 P: (408) 247-4326 F: (408) 247-4329 multigen!norm@uunet.UU.NET -- 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 giraffe.asd.sgi.com!sgi.sgi.com!uunet.UU.NET!rayssd!swlrgk.msd.ray.com!swl!shj Thu Oct 7 06:33:36 1993 From: "Stephen Joyce {75069}" Message-Id: <9310071216.AA04707@swlrgk> To: 00A4269@msgate.emis.hac.com, aschaffe Subject: Re: Flight format V. 12 Cc: info-performer Status: O Yes - I've gotten from Software Systems the v12 loader. However, we had problems installing it until we got the source code for it and recompiled it ourselves. In order to do this we had to sign their non-disclosure agreement. From renee@pat.mdc.com Thu Oct 7 08:13:33 1993 From: Renee Strong Message-Id: <9310071513.AA22729@pat.mdc.com> Subject: swaptmesh in performer To: info-performer@sgi.sgi.com Date: Thu, 7 Oct 93 10:13:19 CDT X-Mailer: ELM [version 2.3 PL11] Status: O Has anyone written a little converter to change trimeshes using swaptmesh to trimeshes with out the swapping? Thanks, Renee Strong renee@pat.mdc.com From mtj@babar Thu Oct 7 08:26:33 1993 From: "Michael Jones" Message-Id: <9310070826.ZM10669@babar.asd.sgi.com> Date: Thu, 7 Oct 1993 08:26:25 -0700 In-Reply-To: Renee Strong "swaptmesh in performer" (Oct 7, 10:13am) References: <9310071513.AA22729@pat.mdc.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: Renee Strong , info-performer@sgi.sgi.com Subject: Re: swaptmesh in performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 7, 10:13am, Renee Strong wrote: > Subject: swaptmesh in performer :Has anyone written a little converter to change trimeshes using swaptmesh :to trimeshes with out the swapping? The idea here is to simply start a new strip at each swap. I should have done this with the SGO loader. Here's the swap t-mesh: Mesh v1 v2 v3 v4 v5 swap v6 v7 v8 swap v9 v10 ... Here's the multiple triangle strips (ready for a pfGeoSet): Strip v1 v2 v3 v4 v5 Strip v3 v5 v6 v7 v8 Strip v6 v9 v10 ... My logic is that each "v n SWAP" is replaced with "v n STRIP v n-2" and that's all there is to it. It decreases the "vertex efficiency" by one vertex per swap compared to the original, but will run as fast or faster in most cases snd is the only solution in OpenGL since swap-tmeshes are history. I should have done this. I'll file a bug against the SGO loader to add this feature. -- 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 micha@apple.com Thu Oct 7 08:52:57 1993 for info-performer@sgi.com Date: Thu, 7 Oct 93 08:52:45 -0700 From: Michael Hoch Message-Id: <9310071552.AA21329@apple.com> To: info-performer@sgi.sgi.com Subject: Info about performer Status: O Hi there, sorry to bother you with this simple question, but I am on the mailing list just a few days and looking for general information about performer (What it is, it's functionality, performance, where to get it etc.). Thanks for a short reply. Mike From russo@rudedog.ait.nrl.navy.mil Thu Oct 7 09:55:43 1993 Date: Thu, 7 Oct 93 12:55:37 -0400 From: russo@rudedog.ait.nrl.navy.mil (Kevin Russo) Message-Id: <9310071655.AA13915@rudedog.ait.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: Stars Status: O Is it better to implement stars in the night sky (or as seen from Earth orbit) as Geosets of PFGS_POINTS or as pfLightPoint nodes? Kevin Russo Naval Research Lab From jrohlf@tubes Thu Oct 7 10:26:51 1993 Date: Thu, 7 Oct 93 10:26:40 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310071726.AA00506@tubes.asd.sgi.com> To: Renee Strong , info-performer@sgi.sgi.com Subject: Re: swaptmesh in performer Status: O The triangle mesher in the 1.2 utility library generates meshes without swaptmesh. Probably the easiest thing to do is decompose all your swap meshes into independent triangles and feed them to a pfuBuilder with pfuAddTri and then later call pfuMakeGSets to generate stripped pfGeoSets. Send mail to cct for more details. From jrohlf@tubes Thu Oct 7 10:31:01 1993 Date: Thu, 7 Oct 93 10:30:42 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310071730.AA00545@tubes.asd.sgi.com> To: russo@rudedog.ait.nrl.navy.mil (Kevin Russo), info-performer@sgi.sgi.com Subject: Re: Stars Status: O >Is it better to implement stars in the night sky (or as seen from >Earth orbit) as Geosets of PFGS_POINTS or as pfLightPoint nodes? pfLightPoints are probably easiest and should be comparable in performance to pfGeoSets. From giraffe.asd.sgi.com!sgi.sgi.com!uunet.UU.NET!rayssd!swlgbd.msd.ray.com!shj Thu Oct 7 12:43:12 1993 Date: Thu, 7 Oct 93 14:50:04 -0400 From: shj@swlgbd.msd.ray.com (Stephen Joyce {75069}) Message-Id: <9310071850.AA01966@swlgbd.msd.ray.com> Apparently-To: info-performer@sgi.sgi.com Status: O Performer question: I'm having trouble using a switch node. In the constructor of a class it is created like this: sw = pfNewSwitch(); dcs1 = pfNewDCS(); pfNodeName(dcs1,"FIRSTMISSILE"); dcs2 = pfNewDCS(); missile1 = LoadFlt("M3DD00065.flt"); missile2 = LoadFlt("kaPOW.flt"); printf("loaded both 65 and kapow files. \n"); pfAddChild(dcs1, missile1); pfAddChild(dcs2, missile2); pfAddChild(sw,dcs2); pfAddChild(sw,dcs1); pfAddChild(this->dcs[0],sw); long index, temp2; pfNode *temp1; index = 0; temp1 = pfGetChild(this->dcs[0], index); temp2 = pfRemoveChild(this->dcs[0], temp1); However, it crashes at run-time, with this error in the culling process. I'm not sure why it works occasionally. Process 1905 (Stealth) Segmentation fault [cull__8pfSwitchFlP8pfCuller, :0xe432b64] *[cull__8pfSwitchFlP8pfCuller, 0xe432b64] lw v0,0(t6) (dbx) where > 0 cull__8pfSwitchFlP8pfCuller(0x145959d0, 0x6, 0x14222e50, 0x3e48c8c9, 0x0, 0x1432b5e0) [0xe432b64] 1 cull__5pfSCSFlP8pfCuller(0x145959d0, 0x6, 0x14222e50, 0x3e48c8c9, 0x29, 0x438130) [0xe431b54] 2 cull__7pfGroupFlP8pfCuller(0x145959d0, 0x6, 0x14222e50, 0x3e48c8c9, 0x0, 0x3edededf) [0xe41612c] 3 cull__7pfGroupFlP8pfCuller(0x145959d0, 0x6, 0x14222e50, 0x3e48c8c9, 0x4, 0x0) [0xe41612c] Thanks, Steve Joyce From renee@pat.mdc.com Thu Oct 7 11:57:21 1993 From: Renee Strong Message-Id: <9310071857.AA24741@pat.mdc.com> Subject: cameras and lights To: info-performer@sgi.sgi.com Date: Thu, 7 Oct 93 13:57:13 CDT X-Mailer: ELM [version 2.3 PL11] Status: O Our analysts need to attach cameras and lights to models. I'd like to make cameras (I guess that should be pfChannels) and lights children of pfDCS nodes and have the position and direction come from the pfDCS node. Is this possible? Right now I can't even get a light to turn on with pfLightOn. It just core dumps. It also core dumps when I try to attach a light to a pfDCS. Thanks, Renee Strong renee@pat.mdc.com From jrohlf@tubes Thu Oct 7 12:12:21 1993 Date: Thu, 7 Oct 93 12:12:12 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310071912.AA01249@tubes.asd.sgi.com> To: Renee Strong , info-performer@sgi.sgi.com Subject: Re: cameras and lights Status: O >Our analysts need to attach cameras and lights to models. I'd like to make >cameras (I guess that should be pfChannels) and lights children of pfDCS >nodes and have the position and direction come from the pfDCS node. A pfLightSource node will inherit the position and direction of a pfDCS node. A pfChannel is not a node so you cannot add it to a pfDCS. You must set the pfChannel view matrix with pfChanViewMat() at the same time you call pfDCSMat(). From darken@enews.nrl.navy.mil Thu Oct 7 13:33:31 1993 Date: Thu, 7 Oct 93 16:30:45 -0400 From: darken@enews.nrl.navy.mil (Rudy Darken) Message-Id: <9310072030.AA03621@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: pfDCS question Status: O How do pfDCS calls affect each other? For example: pfDCS *dcs; pfDCSMat (dcs, some_matrix); pfDCSRot (dcs, h, p, r); If I have some uniform transformation to do (represented as some_matrix) and then want to apply some rotation or translation afterwards, does the rotation call overwrite any part of the matrix? How about the reverse case? pfDCSRot (dcs, h, p, r); pfDCSMat (dcs, some_matrix); I'm getting some strange results in porting some gl code to Performer. They use multmatrix calls either preceded or followed by rot calls. I'm not sure if my method is working. Thanks. Rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From darken@enews.nrl.navy.mil Thu Oct 7 13:42:33 1993 Date: Thu, 7 Oct 93 16:39:57 -0400 From: darken@enews.nrl.navy.mil (Rudy Darken) Message-Id: <9310072039.AA03859@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: pfDCS question Status: O How do pfDCS calls affect each other? For example: pfDCS *dcs; pfDCSMat (dcs, some_matrix); pfDCSRot (dcs, h, p, r); If I have some uniform transformation to do (represented as some_matrix) and then want to apply some rotation or translation afterwards, does the rotation call overwrite any part of the matrix? How about the reverse case? pfDCSRot (dcs, h, p, r); pfDCSMat (dcs, some_matrix); I'm getting some strange results in porting some gl code to Performer. They use multmatrix calls either preceded or followed by rot calls. I'm not sure if my method is working. Thanks. Rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From darken@enews.nrl.navy.mil Thu Oct 7 14:04:36 1993 Date: Thu, 7 Oct 93 17:01:47 -0400 From: darken@enews.nrl.navy.mil (Rudy Darken) Message-Id: <9310072101.AA04242@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: pfDCS question Status: O How do pfDCS calls affect each other? For example: pfDCS *dcs; pfDCSMat (dcs, some_matrix); pfDCSRot (dcs, h, p, r); If I have some uniform transformation to do (represented as some_matrix) and then want to apply some rotation or translation afterwards, does the rotation call overwrite any part of the matrix? How about the reverse case? pfDCSRot (dcs, h, p, r); pfDCSMat (dcs, some_matrix); I'm getting some strange results in porting some gl code to Performer. They use multmatrix calls either preceded or followed by rot calls. I'm not sure if my method is working. Thanks. Rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From bwebb@gelac.lasc.lockheed.com Thu Oct 7 14:47:31 1993 Date: Thu, 7 Oct 93 17:50:00 -0400 From: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Message-Id: <9310072150.AA01435@ gizmo.lasc.lockheed.com> To: info-performer@sgi.sgi.com Subject: Looking for Multi Channel Example Status: O I'm interested in seeing an example of working Performer code which uses multiple channels and multiple pipes from a single program. Typical usage would be an out-the-window display using both pipes on a SkyWriter. Please email to the address below. Thanx in advance. -- Barry W. Webb Lockheed Aeronautical Systems Company Email: bwebb@gizmo.lasc.lockheed.com Marietta, Georgia 30063-0670 Vmail: (404) 494-6952 Fax: 6989 From aschaffe Thu Oct 7 17:51:58 1993 Date: Thu, 7 Oct 93 17:51:58 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9310080051.AA12366@holodeck.asd.sgi.com> To: info-performer Subject: about mail bounces Status: OR A few of you are undoubtedly seeing some bounced mail when you send things to the info-performer list. This is the natural :-) breaking-in period of any new mailing list, as we slowly discover how many people gave me a dead-end address. These will gradually be cleared up. In the meantime, if you get a bounce please forward it to me (not the list). Your posts -are- going through, even when you receive a bounce. The bounces represent failures in the forwarding. So, you need only send them once. Enjoy, Allan ---- Allan Schaffer x3-2160 Silicon Graphics aschaffe@sgi.com From aschaffe Thu Oct 7 18:30:23 1993 From: aschaffe (Allan Schaffer) Message-Id: <9310071830.ZM12676@holodeck.asd.sgi.com> Date: Thu, 7 Oct 1993 18:30:08 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Info about performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 7, 8:52am, Michael Hoch wrote: > > sorry to bother you with this simple question, but I am on > the mailing list just a few days and looking for general > information about performer (What it is, it's functionality, > performance, where to get it etc.). Ah -- these are questions that will be answered in an excellent manner in the much-promised-but-still-unfinished Performer FAQ. But, no reason to keep you waiting for a part that's already written, so here's a tidbit. Allan -2- What is IRIS Performer? IRIS Performer is a software development environment that supports programmers implementing high performance graphics applications on Silicon Graphics products. It offers both high level facilities for visual simulation and virtual reality tasks and an application-neutral high-performance hardware-oriented graphics toolkit. The outer application specific layer of IRIS Performer implements the tasks needed by visual simulation applications: it performs culling so that only potentially visable geometry is sent to the graphics hardware; it controls multiple display channels; it provides fast intersection tests with simulation databases; and most importantly, it orchestrates all of this in parallel with rendering on multiple processor IRIS systems. The lower-level rendering portion of IRIS Performer is designed for maximum performance: it's efficient data structures reflect the details of CPU, cache, and memory system architectures; it's tuned rendering loops convert the system CPU into an optimized data movement engine; and it's optimized state management system optimizes hardware utilization. IRIS Performer provides a high-performance portability path across the Silicon Graphics product line. The low level library is implemented as a hardware-specific shared library, so applications based on IRIS Performer can achieve peak performance on graphics systems from Elan to RealityEngine2 without changes or recompilation. The product includes a programmer's guide and printed man pages, as well as on-line man pages, test and demonstration programs, and complete real-time visual simulation applications. These applications are provided in source form as an examples of how to build real-time simulation systems using IRIS Performer. Also included are several databases in FLIGHT and Wavefront "OBJ" format and source code for database readers that can load them. -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From sehyo@netcom.com Thu Oct 7 18:41:29 1993 From: sehyo@netcom.com (Sehyo Chang) Message-Id: <9310080141.AA07621@netcom3.netcom.com> Subject: Performer API To: info-performer@sgi.sgi.com (Performer Mailing List) Date: Thu, 7 Oct 93 18:41:46 PDT X-Mailer: ELM [version 2.3 PL11] Status: O I am interesting in interface to Performer from non-C application. Is this will be easy to accomplish it? thanks From jimh@surreal Fri Oct 8 00:21:05 1993 Message-Id: <9310080720.AA22941@surreal.asd.sgi.com> To: sehyo@netcom.com (Sehyo Chang) Cc: info-performer@sgi.sgi.com (Performer Mailing List) Subject: Re: Performer API In-Reply-To: Your message of "Thu, 07 Oct 93 18:41:46 PDT." <9310080141.AA07621@netcom3.netcom.com> Date: Fri, 08 Oct 93 00:20:58 -0700 From: Jim Helman Status: O While we only provide C bindings, customers have used Performer from Scheme and Ada. It's mainly a matter of going through the tedious task of creating foreign function wrappers for every Performer routine you want to call from your language and creating data structures (e.g. pfSegment, pfSegSet) which match the exposed C structures used in Performer's C API. If your language is f77, mkf2c(1) can generate the wrappers for you. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From rrecker@world.std.com Fri Oct 8 07:28:07 1993 Date: Fri, 8 Oct 1993 10:26:46 -0400 From: rrecker@world.std.com (Rod Recker) Message-Id: <199310081426.AA07185@world.std.com> To: info-performer@sgi.sgi.com Subject: Add me to mailing list Status: OR I would like to be added to the mailing list. I would also like information on pricing and some info on how to write a program that reads a 3D dataset for use in Performer. -Rod Recker From renee@pat.mdc.com Fri Oct 8 09:04:08 1993 From: Renee Strong Message-Id: <9310081603.AA00160@pat.mdc.com> Subject: stupid mistakes To: info-performer@sgi.sgi.com Date: Fri, 8 Oct 93 11:03:52 CDT X-Mailer: ELM [version 2.3 PL11] Status: O I'm just writing this in case there's any other new developers out there, so you don't make the same mistake I did.... You need to open the pipe and do the pfInitGfx before you can add lights! I was using the simple.c code as a template and reading in my tree where simple.c loaded in the data. I needed to put my loader AFTER the pipe stuff. Renee renee@pat.mdc.com From moore@wrc.xerox.com Fri Oct 8 09:25:28 1993 id AA12640; Fri, 8 Oct 93 12:25:02 EDT Message-Id: <9310081625.AA12640@gargar.wrc.xerox.com> To: info-performer@sgi.sgi.com (Performer Mailing List) Cc: sehyo@netcom.com (Sehyo Chang) Subject: Re: Performer API In-Reply-To: Your message of "Fri, 08 Oct 93 00:20:58 PDT." <9310080720.AA22941@surreal.asd.sgi.com> Date: Fri, 8 Oct 1993 09:25:00 PDT From: "Lee C. Moore" Status: O Re: languages to access the Performer API Althought it is pretty obvious, I will mention that it is easy to write C++ applications that access Performer's API. As I understand it, there is an irony here because Performer is actually written in C++ not C. Lee Moore From darken@enews.nrl.navy.mil Fri Oct 8 09:48:22 1993 Date: Fri, 8 Oct 93 12:45:50 -0400 From: darken@enews.nrl.navy.mil (Rudy Darken) Message-Id: <9310081645.AA07144@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: Performer API Status: O Speaking of Performer and C++, why doesn't SGI release the C++ bindings as well as the C? Would this be of interest to many customers? It certainly would to us. rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From jrohlf@tubes Fri Oct 8 10:09:17 1993 Date: Fri, 8 Oct 93 10:09:08 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310081709.AA03771@tubes.asd.sgi.com> To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com Subject: Re: Performer API Status: O >Speaking of Performer and C++, why doesn't SGI release >the C++ bindings as well as the C? Providing clean C++ bindings is far more difficult than providing clean C bindings and is not simply a matter of shipping .h files. It is even harder to provide extensibility through subclassing because you must rigorously define all interfaces. The initial Performer release schedule was ridiculously short for such a large software project. If we had concentrated on a nice C++ interface then you would probably have just recently received your Performer 1.0 CD in the mail. As is often the case, a conspiracy of schedules dictated the product. We have received more interest in C++ bindings than we originally thought so we will probably do it in the future. Actually, it is probably best that we wait because we can let the product mature for a while at which time it will be easier to produce a rigorous and stable C++ API. From reedwhit@skips.dseg.ti.com Fri Oct 8 14:28:03 1993 Date: Fri, 8 Oct 93 16:26:58 CDT From: reedwhit@skips.dseg.ti.com (Reed Whittington) Message-Id: <9310082126.AA22246@skips.dseg.ti.com> To: info-performer@sgi.sgi.com Subject: Best HUD in Perfomer Status: O I'm looking for the most efficient way to implement HUD symbology on top of a performer visual. I have tried drawing to the overlay plane in a post draw call back. This tends to task the graphics pipe more than would be expected. Even drawing every 10th frame creates a big spike. I have considered putting the symbology in its own pfChannel. Would this be recommended? What have others tried? It seems the Performer Channel Stats are efficiently implemented. How were the ChanStats done? --Reed From marrou@indy.vsl.ist.ucf.edu Fri Oct 8 15:22:39 1993 Date: Fri, 8 Oct 93 18:22:41 -0400 From: marrou@indy.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9310082222.AA23794@indy.vsl.ist.ucf.edu> To: "Lee C. Moore" , info-performer@sgi.sgi.com (Performer Mailing List) Subject: Re: Performer API Cc: sehyo@netcom.com (Sehyo Chang) Status: O >Althought it is pretty obvious, I will mention that it is >easy to write C++ applications that access Performer's API. Some aspects is a little more difficult than you might lead someone to believe. I have an object oriented visual and dynamics system and my only problem is the function callback mechanisms; specifically, pfInitPipe() and pfChanDrawFunc() in multiprocessing modes. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From srf@rose Fri Oct 8 15:23:03 1993 From: srf@rose (Sharon Fischler) Message-Id: <9310081522.ZM19134@rose.asd.sgi.com> Date: Fri, 8 Oct 1993 15:22:50 -0700 In-Reply-To: reedwhit@skips.dseg.ti.com (Reed Whittington) "Best HUD in Perfomer" (Oct 8, 4:26pm) References: <9310082126.AA22246@skips.dseg.ti.com> X-Mailer: Z-Mail-SGI (2.1.1 08dec92) To: reedwhit@skips.dseg.ti.com (Reed Whittington), info-performer@sgi.sgi.com Subject: Re: Best HUD in Perfomer Status: O +>---- On Oct 8, 4:26pm, Reed Whittington wrote: > Subject: Best HUD in Perfomer -> -> -> ->I'm looking for the most efficient way to implement HUD symbology on ->top of a performer visual. I have tried drawing to the overlay plane ->in a post draw call back. This tends to task the graphics pipe more ->than would be expected. Even drawing every 10th frame creates a big ->spike. I have considered putting the symbology in its own pfChannel. Draw your static info in the overlay planes and ONLY redraw it when the window receives a REDRAW event (moved, resized, etc.). Changing between drawing to the overlays and drawing to regular bitplanes takes a big hit. For things that need to be updated real-time, you can set zfunction(ZF_ALWAYS); zwritemask(0x0); draw stuff zfunction(ZF_LEQUAL); zwritemask(0xffffffff); If you have a whole lot of stuff to draw, then it might faster to just turn off zbuffer but I would think that most HUDs aren't that dense. you also want to disable fog BEFORE you change the projection matrix (ortho2). srf. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From wgerhard@afit.af.mil Sat Oct 9 11:08:11 1993 Date: Sat, 9 Oct 1993 14:08:00 -0400 From: William E Gerhard Message-Id: <199310091808.AA00347@stealth.afit.af.mil> To: info-performer@sgi.sgi.com Subject: HUD's in performer Status: O I have been working on a distributed interactive flight simulator here at AFIT and I used GL calls in a draw call back. The call back is setup to be called after our aircraft model is drawn. All the vertices in the bgnline();...endline(); calls are defined in our aircraft model space. We use a Polhemeus Fastrack with this thing, so as an added bonus, the HUD changes perspective with the rest of the simulation if the pilot moves his head. The text on the HUD was a little more difficult, but I ended making a vector based font class which works well. There is not much of a performance hit with this scheme if as many of the vertices as possible are defined as static. Bill Gerhard wgerhard@afit.af.mil From giraffe.asd.sgi.com!sgi.sgi.com!rocket.sanders.lockheed.com!rocket.sanders.com!metivier Mon Oct 11 08:10:13 1993 Date: Mon, 11 Oct 93 11:06:21 EDT From: metivier@rocket.sanders.com (Todd Metivier) Message-Id: <9310111506.AA01258@rocket.sanders.lockheed.com> To: info-performer@sgi.sgi.com Subject: pfDCS Status: O I need to be able to scale a pfDCS on the fly by different amounts in x, y, and z. The pfDCSScale() routine scales each axis by the same amount. Any suggestions? Thanks, Todd From marrou@melange.vsl.ist.ucf.edu Mon Oct 11 09:09:59 1993 Date: Mon, 11 Oct 93 12:11:00 -0400 From: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9310111611.AA23192@melange.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: the new pfMQueryHit() Status: O Does the pfMQueryHit() in v1.2 (Beta) return world coordinates for the PFQHIT_POINT vector? If not, where is the transformation? Also, is the PFQHIT_NORM vector normalized? So far, these new intersection routines seem a lot easier to implement, but the man pages are horrible. pfSegsIsectNode() doesn't even exist in our copy! :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From frobinso@world.nad.northrop.com Mon Oct 11 11:06:48 1993 Message-Id: <9310111811.AA25912@world.nad.northrop.com> To: info-performer@sgi.sgi.com Subject: What are those *.flt.tlf files? Date: Mon, 11 Oct 93 11:11:33 MDT From: frobinso@world.nad.northrop.com Status: O In /usr/demos/data/town/pfvillage , are files ending in .flt.tlf. Are these converted Multigen flight format files? If so , converted into what? How do I convert them back into .flt? And why is the example source included with Iris Performer not reflective of the binary in /usr/demos/perfly? - -- -------------------------------------------------------------------------- - Fletcher Karl Robinson | Phone : 310 332 0489 - - Computer Engineer Specialist | - - Department T213/85 | Fax : 310 332 5962 - - Aircraft Division | - - Northrop Corporation | Email : - - One Northrop Avenue | - - Hawthorne , California 90250 3277 | frobinso@world.nad.northrop.com - -------------------------------------------------------------------------- From jimh@surreal Mon Oct 11 10:50:19 1993 Message-Id: <9310111750.AA22134@surreal.asd.sgi.com> To: metivier@rocket.sanders.com (Todd Metivier) Cc: info-performer@sgi.sgi.com Subject: Re: pfDCS In-Reply-To: Your message of "Mon, 11 Oct 93 11:06:21 EDT." <9310111506.AA01258@rocket.sanders.lockheed.com> Date: Mon, 11 Oct 93 10:50:11 -0700 From: Jim Helman Status: OR You can set the matrix directly (pfMakeScaleMat, pfDCSMat), however non-uniform scales are slow because normals must be renormalized in the graphics pipe. Also, there is at least one bug affecting non-orthogonal transformations: bounding cylinders in intersection requests. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From frobinso@world.nad.northrop.com Mon Oct 11 10:50:56 1993 Date: Mon, 11 Oct 93 10:55:43 PDT From: Fletcher Robinson Message-Id: <9310111755.AA25836@world.nad.northrop.com> To: info-performer@sgi.sgi.com Subject: What are those *.flt.tlf files? Status: O In /usr/demos/data/town/pfvillage , are files ending in .flt.tlf. Are these converted Multigen flight format files? If so , converted into what? How do I convert them back into .flt? And why is the example source included with Iris Performer not reflective of the binary in /usr/demos/perfly? -- -------------------------------------------------------------------------- - Fletcher Karl Robinson | Phone : 310 332 0489 - - Computer Engineer Specialist | - - Department T213/85 | Fax : 310 332 5962 - - Aircraft Division | - - Northrop Corporation | Email : - - One Northrop Avenue | - - Hawthorne , California 90250 3277 | frobinso@world.nad.northrop.com - -------------------------------------------------------------------------- From jimh@surreal Mon Oct 11 11:12:37 1993 Message-Id: <9310111812.AA22325@surreal.asd.sgi.com> To: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) Cc: info-performer@sgi.sgi.com Subject: Re: the new pfMQueryHit() In-Reply-To: Your message of "Mon, 11 Oct 93 12:11:00 EDT." <9310111611.AA23192@melange.vsl.ist.ucf.edu> Date: Mon, 11 Oct 93 11:12:26 -0700 From: Jim Helman Status: O Date: Mon, 11 Oct 93 12:11:00 -0400 From: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) To: info-performer@sgi.sgi.com Subject: the new pfMQueryHit() Does the pfMQueryHit() in v1.2 (Beta) return world coordinates for the PFQHIT_POINT vector? If not, where is the transformation? Also, is the PFQHIT_NORM vector normalized? As with the now defunct pfIsect structure, the point is in local coordinates. You *would* be able to get the transformation both in discriminator callbacks and upon return of pfSegsIsectNode, except for a bug in the beta (alpha 53), which has since been fixed. The normal is normalized. So far, these new intersection routines seem a lot easier to implement Good. but the man pages are horrible. What would you like to see more detail on? pfSegsIsectNode() doesn't even exist in our copy! :) Then something went wrong with your inst. I just double checked both the Irix4 (/usr/catman/p_man/cat3/Performer_pf/pfSegsIsectNode.z) and Irix5 (/usr/share/catman/p_man/cat3/Performer_pf/pfSegsIsectNode.z) distributions. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From mtj@babar Mon Oct 11 11:12:41 1993 From: "Michael Jones" Message-Id: <9310111112.ZM19682@babar.asd.sgi.com> Date: Mon, 11 Oct 1993 11:12:30 -0700 In-Reply-To: Fletcher Robinson "What are those *.flt.tlf files?" (Oct 11, 10:55am) References: <9310111755.AA25836@world.nad.northrop.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: Fletcher Robinson , info-performer@sgi.sgi.com Subject: Re: What are those *.flt.tlf files? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 11, 10:55am, Fletcher Robinson wrote: > Subject: What are those *.flt.tlf files? :In /usr/demos/data/town/pfvillage , are files ending in .flt.tlf. Are :these converted Multigen flight format files? If so , converted into :what? How do I convert them back into .flt? And why is the example source :included with Iris Performer not reflective of the binary in :/usr/demos/perfly? Let's understand this whole issue once and for all. The "Performer Town" and "Performer Village" databases were built for us under a "non-distribution" agreement that we have respected. That's why the files are encrypted in the demo directory. It's also explains the difference in the perfly programs. Both of the companies involved in the development of these sample data bases, Paradigm Simulation of Dallas Texas and Software Systems of San Jose California have agreed that distributing the databases in their editable form is now fine. We are removing the "Mobil" and "7-11" logos from the database now. When we are done, we'll have a very nice database that will include all of the textures, terrain, and feature data. This will be included in the next release of IRIS Performer, which will be version 1.2. -- 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 haabn@nye.nscee.edu Mon Oct 11 12:48:32 1993 id AA27665; Mon, 11 Oct 93 12:33:15 PDT Message-Id: <9310111933.AA27665@nscee.edu> To: info-performer@rock.csd.sgi.com Date: Mon, 11 Oct 93 12:33:14 -0700 From: haabn@nye.nscee.edu Status: O unsubscribe From marrou@melange.vsl.ist.ucf.edu Mon Oct 11 12:56:43 1993 Date: Mon, 11 Oct 93 15:57:43 -0400 From: marrou@melange.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9310111957.AA24081@melange.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: obtaining frame rate Status: O How do I obtain the actual, achieved frame rate of the system? pfGetFrameRate() returns the system frame rate set in pfFrameRate(), so that is not the answer. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From ngo@interval.com Mon Oct 11 12:22:26 1993 Message-Id: <9310111922.AA07606@interval.interval.com> Date: Mon, 11 Oct 1993 12:24:24 -0800 To: info-performer@sgi.sgi.com From: ngo@interval.com (Tom Ngo) Subject: How to remove oneself from the mailing list Status: OR *** 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 abramsh@erau.db.erau.edu Mon Oct 11 14:07:27 1993 Message-Id: From: abramsh@erau.db.erau.edu (Howard Abrams) Subject: Re: obtaining frame rate To: info-performer@sgi.sgi.com Date: Mon, 11 Oct 93 16:57:16 EDT In-Reply-To: <9310111957.AA24081@melange.vsl.ist.ucf.edu>; from "Lance Marrou" at Oct 11, 93 3:57 pm X-Mailer: ELM [version 2.3 PL11] Status: OR > > How do I obtain the actual, achieved frame rate of the system? > pfGetFrameRate() returns the system frame rate set in pfFrameRate(), > so that is not the answer. > One answer could be to calculate the time it took to go though the loop. ie. Actual_FPS = 1 / Change_in_time. where to get the time is a different story. I tried using pfGetTime()(?) but it often returned strange results. --- Howard Abrams (_/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\_) (| .. |) (| abramsh@erau.db.erau.edu .. - Real Men See 60Hz - |) (| .. |) (\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/) From mtj@babar Mon Oct 11 14:37:03 1993 From: "Michael Jones" Message-Id: <9310111436.ZM23087@babar.asd.sgi.com> Date: Mon, 11 Oct 1993 14:36:49 -0700 In-Reply-To: abramsh@erau.db.erau.edu (Howard Abrams) "Re: obtaining frame rate" (Oct 11, 4:57pm) References: X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: abramsh@erau.db.erau.edu (Howard Abrams), info-performer@sgi.sgi.com Subject: Re: obtaining frame rate Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 11, 4:57pm, Howard Abrams wrote: > Subject: Re: obtaining frame rate ... I tried using pfGetTime()(?) but it often returned strange results. Was this on an IO2 system? You'd know if "hinv|grep IO2" says something. Otherwise, you have an unexpected bug. Please say more. -- 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 jimh@surreal Mon Oct 11 14:42:04 1993 Message-Id: <9310112141.AA22980@surreal.asd.sgi.com> To: abramsh@erau.db.erau.edu (Howard Abrams) Cc: info-performer@sgi.sgi.com Subject: Re: obtaining frame rate In-Reply-To: Your message of "Mon, 11 Oct 93 16:57:16 EDT." Date: Mon, 11 Oct 93 14:41:57 -0700 From: Jim Helman Status: O where to get the time is a different story. I tried using pfGetTime()(?) but it often returned strange results. There was a bug in 1.0 (fixed in 1.1) which caused pfGetTime() to occasionally return bad values (off by 4000+ seconds!!!) on machines without a fast counter, e.g. PowerSeries/IO2. But if you've seen bad time values on an Indigo, Indigo2, PI/35, PowerSeries/IO3, Crimson, Onyx running any version of Performer or on an Indy running the 1.2 beta, speak up. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From renee@pat.mdc.com Mon Oct 11 14:56:49 1993 From: Renee Strong Message-Id: <9310112156.AA10892@pat.mdc.com> Subject: heirarchy display To: info-performer@sgi.sgi.com Date: Mon, 11 Oct 93 16:56:36 CDT X-Mailer: ELM [version 2.3 PL11] Status: O Does any one have a 2D graphical heirarchy display for performer? I'd like to be able to pass in the root node and get a little display of what the tree looks like. Renee renee@pat.mdc.com From aschaffe Mon Oct 11 21:35:41 1993 Date: Mon, 11 Oct 93 21:35:41 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9310120435.AA21044@holodeck.asd.sgi.com> To: info-performer Subject: READ THIS Administrivia: Reducing info-performer volume Status: OR What a weekend. I think I'll start this by repeating what may become a mantra: * Do -not- send administrative requests to info-performer. That is an alias that reaches almost 300 people! Send Administrative requests to: info-performer-request@sgi.com or just straight to me. aschaffe@sgi.com Now on to business: I'm pondering ways to reduce the volume messages posted to this list. There are several possibilities: a) start a newsgroup b) send the list in a weekly "digest" format c) "moderate" the list d) two lists e) something else A newsgroup is a long-term solution but not what we need at the moment. Also, the intent of the list is a bit different. Sending the list in "weekly digest" format would require a lot of work to maintain. :-) And, it would also induce up to a week of latency between a question and it's actual posting. I don't think this is the best solution. A good short-term solution would be for me to moderate the list. This would mean that messages would still be mailed to info- performer, but would have to be "approved" before getting sent out to the subscribers. One advantage of this is that the only "real" messages would get through. "please add me" or "please remove me" would get caught and taken care of. The last idea would be to have two lists -- one for people with questions and for general discussion about Performer; the other for people who are interested in "announcements" only. I like this idea. So, I'm currently leaning towards both: - creating a moderated, announcements-and-information-only list (info-performer-announce) and - moderating the discussion/Q&A list (info-performer) I'll interpret general silence as tacit agreement. I welcome your comments.. Allan ---- Allan Schaffer x3-2160 Silicon Graphics aschaffe@sgi.com From aschaffe Mon Oct 11 22:23:51 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310112223.ZM21241@holodeck.asd.sgi.com> Resent-Date: Mon, 11 Oct 1993 22:23:50 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Mon, 11 Oct 93 22:22:49 -0700 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9310120522.AA22330@bessie.cs.nps.navy.mil> To: info-performer Subject: Re: READ THIS Administrivia: Reducing info-performer volume Status: O While I agree that the volume needs to be reduced, how much of the the traffic was start-up traffic? Should the list go a couple of weeks to reach steady state? My other concern is the moderation of the list. Is the moderator going to answer the mail that does not make it to the main list? After all, if they didn't feel worth while, they would not have sent it. Dave Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From aschaffe Mon Oct 11 23:31:32 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310112331.ZM21500@holodeck.asd.sgi.com> Resent-Date: Mon, 11 Oct 1993 23:31:32 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Tue, 12 Oct 93 14:30:16+080 From: tim@iss.nus.sg (Tim Poston) Message-Id: <9310120630.AA14428@bochap.iss.nus.sg> To: info-performer, pratt@bessie.cs.nps.navy.mil Subject: Re: READ THIS Administrivia: Reducing info-performer volume Cc: tim@iss.nus.sg Status: O >> While I agree that the volume needs to be reduced, how much of the the >> traffic was start-up traffic? Should the list go a couple of weeks to >> reach steady state? Steady state on the present basis would exclude a lot more people who dropped it, on the grounds of the unmanaged volume. A lot more useful stuff would come through on the suggested managed basis, without choking our mail readers. In the long term, I'm certainly hoping for a newsgroup, where my threading tools etc. work. (What I have doesn't work on a digest, which is another objection to that besides the delayed turn-around.) In the short term, Allan Schaffer's current leaning sounds to me like the best fix. Within the mailing context, could the list get itself set as the From: heading? With the true originator as From:, as at present, the subject line doesn't always tell me this is a Performer related item, which is more significant in scanning my incoming mail than the person (usually unknown to me) who posted the item. Tim ___________________________________________________________________ Tim Poston Institute of Systems Science, Nat. Univ. of Singapore sig = +--- (time is positive) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From aschaffe Wed Oct 13 18:49:31 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310131849.ZM4990@holodeck.asd.sgi.com> Resent-Date: Wed, 13 Oct 1993 18:49:30 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Wed, 13 Oct 1993 11:01:55 +0100 (PDT) From: Tin Le Subject: Re: READ THIS Administrivia: Reducing info-performer volume To: info-performer In-Reply-To: <9310120435.AA21044@holodeck.asd.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Personally, I prefer newsgroup, digest, moderated mailing list in that order. The Usenet 'rules' is that a mailing list has to be going for a while and has 'enough' members to merit a CFD on creating a newsgroup to replace it. Since info-performer is still young, I suggest let it grow a little first before doing anything about a newsgroup. The initial deluge of mail from the list bothered me at first, but then I realized that it is a new and people are still getting used to the way it is administered. Hopefully this will settle down soon. As a suggestion, Allan Schaffer may want to look at using one of the mailing list software that make administrating mailing list easier on him. Some suggestions are LISTSERV, MajorDomo. Both are fairly easy to setup and pretty much run themself once setup (people can add and remove themselves from the list, etc.). Cheers, Tin Le ---- Tin Le tin@Saigon.COM Moderator of comp.binaries.ms-windows Submissions: cbmsw@Saigon.COM Requests: cbmsw-request@Saigon.COM CBMSW Archive at wuarchive.wustl.edu:/usenet/comp.binaries.ms-windows From aschaffe Wed Oct 13 19:42:20 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310131942.ZM5184@holodeck.asd.sgi.com> Resent-Date: Wed, 13 Oct 1993 19:42:20 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Wed, 13 Oct 93 16:50:00 -0700 From: cindy@langrenus.arc.nasa.gov (Cindy Ferguson) Message-Id: <9310132350.AA28987@langrenus.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: question on intersections and different hardware Status: O I have a question about intersection traversals in performer 1.0. The code I have developed works fine on my VGXT and my Indigo XS24. However on my regular simple little Indigo, I get nothing. The code still runs -- it just returns the wrong results of always intersecting nothing. Does anyone know a work-around for this? Thanks, Cindy From aschaffe Wed Oct 13 19:42:49 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310131942.ZM5187@holodeck.asd.sgi.com> Resent-Date: Wed, 13 Oct 1993 19:42:48 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Wed, 13 Oct 93 19:59:03 EDT From: jfr@cae.ca (Jean-Francois Richard 2275) Message-Id: <9310132359.AA07500@cae.ca> To: info-performer@sgi.sgi.com Subject: Performer: Using very large databases Status: O Hello to everybody out there in PerformerLand. I am currently developing a Performer-based program to display very large visual databases (too large to be loaded all at once). My current solution is to divide the DB in a number of small tiles and load those tiles as required by the current viewpoint. The problem is that doing that in the main loop (or in the APP process when using a multi-processing approach) creates ugly CPU and I/O peaks whenever tiles are loaded and deleted. I need a smooth update rate and can't afford to have these peaks. I was planning on creating a forked process that would run at a low priority and would load the tiles for the main process, attempting to "look ahead" to figure out what was going to be needed soon. Unfortunately, it seems that you cannot make Performer calls from processes not started by Performer itself, which makes it impossible to create or delete pfNodes from a forked process. I'm stuck. This looks to me like it should be a fairly common problem for people with large amounts of data to display. Can anybody out there think of anything to get around this problem? -------------------------------------------------------------- J.F. Richard, jfr@cae.ca CAE Electronics Montreal -------------------------------------------------------------- From aschaffe Thu Oct 14 13:31:47 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141331.ZM6892@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 13:31:46 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Return-Path: Message-Id: <9310140553.AA04705@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Cc: hasimoto@iml.mkhar.sharp.co.jp Subject: pfDCSScaleXYZ Date: Thu, 14 Oct 1993 14:53:08 +0900 From: Takeshi Hashimoto Status: O I want pfDCSScaleXYZ too. So I wrote this code. Does it make any troubles? void pfDCSScaleXYZ(pfDCS *dcs,float argx,float argy,float argz) { int i; pfMatrix m; pfGetDCSMatrix(dcs,m); for (i = 0;i < 3 ;i++) pfNormalizeVec3(m[i]); PFSCALE_VEC3(m[0],argx,m[0]); PFSCALE_VEC3(m[1],argy,m[1]); PFSCALE_VEC3(m[2],argz,m[2]); pfDCSMatrix(dcs,m); } ------- hasimoto@iml.mkhar.sharp.co.jp ------- From guest Thu Oct 28 08:45:56 1993 Message-Id: <199310141428.AA01328@artemis.cmr.no> To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: X under Performer 1.2 Date: Thu, 14 Oct 93 16:28:26 +0200 From: Nils Thune Status: O From aschaffe Thu Oct 14 13:41:50 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141341.ZM6918@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 13:41:49 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Thu, 14 Oct 93 11:16:05 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310141816.AA13655@tubes.asd.sgi.com> To: jfr@cae.ca (Jean-Francois Richard 2275), info-performer@sgi.sgi.com Subject: Re: Performer: Using very large databases Status: O >I am currently developing a Performer-based program to display >very large visual databases (too large to be loaded all at once). >My current solution is to divide the DB in a number of small tiles >and load those tiles as required by the current viewpoint. > >The problem is that doing that in the main loop (or in the APP >process when using a multi-processing approach) creates ugly CPU >and I/O peaks whenever tiles are loaded and deleted. I need a smooth >update rate and can't afford to have these peaks. > >I was planning on creating a forked process that would run at a low >priority and would load the tiles for the main process, attempting to >"look ahead" to figure out what was going to be needed soon. >Unfortunately, it seems that you cannot make Performer calls from >processes not started by Performer itself, which makes it impossible >to create or delete pfNodes from a forked process. You can make libpr but not libpf calls from the database loading process. libpf calls modify a global structure that can be a source of contention if multiple processes make libpf calls in parallel. Another option is to use a lock to guarantee that the database and application processes do not make libpf calls at the same time. What I suggest is: 1. Load the file from disk into main memory in the database process. 2. Use a lock around each libpf call or group of calls. ussetlock(libpfLock); pfAddChild(a, b); usunsetlock(libpfLock); If you are using the .flt loader then you will need to get and modify the source code. I realize this is painful but rest assured that we are aware of this problem and consider it a high priority. From aschaffe Thu Oct 14 13:42:35 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141342.ZM6922@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 13:42:35 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Message-Id: <9310141821.AA07757@surreal.asd.sgi.com> To: cindy@langrenus.arc.nasa.gov (Cindy Ferguson) Cc: info-performer@sgi.sgi.com Subject: Re: question on intersections and different hardware In-Reply-To: Your message of "Wed, 13 Oct 93 16:50:00 PDT." <9310132350.AA28987@langrenus.arc.nasa.gov> Date: Thu, 14 Oct 93 11:21:04 -0700 From: Jim Helman Status: O Intersections are not dependent on graphics (or CPU type for that matter), so the Indigo XS24 <-> Indigo Entry difference shouldn't matter. The only thing that comes to mind is that if there were an uninitialized stack variable, you could see an OS version dependency, since earlier versions of the OS zeroed more pages of the stack on startup. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Thu Oct 14 13:44:36 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141344.ZM6928@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 13:44:35 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist From: Renee Strong Message-Id: <9310141953.AA26007@pat.mdc.com> Subject: Mixing X and Performer To: info-performer@sgi.sgi.com Date: Thu, 14 Oct 93 14:53:24 CDT X-Mailer: ELM [version 2.3 PL11] Status: O What do I have to do to mix X and Performer. I have documentation on doing GL and X. Is there documentation on Performer and X? Thanks, Renee Strong renee@pat.mdc.com From aschaffe Thu Oct 14 14:48:15 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141448.ZM7786@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 14:48:15 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Message-Id: <9310142145.AA08098@surreal.asd.sgi.com> To: Takeshi Hashimoto Cc: info-performer@sgi.sgi.com Subject: Re: pfDCSScaleXYZ In-Reply-To: Your message of "Thu, 14 Oct 93 14:53:08 +0900." <9310140553.AA04705@bach.iml.mkhar.sharp.co.jp> Date: Thu, 14 Oct 93 14:45:29 -0700 From: Jim Helman Status: O > I want pfDCSScaleXYZ too. > So I wrote this code. Does it make any troubles? Looks OK. If you will be doing lots of these (and I do mean lots), it might be more efficient to retain the desired rotation, scale and translations separately and combine them into the DCS matrix, thereby avoiding the pfSqrt in pfNormalizeVec3. Rotations are comparatively expensive as well because of the pfSinCos. As a reminder: there are (at least) two issues with non-uniform scales. 1) They slow down the rendering of lighted geometry because normals must be renormalized in the graphics pipe. 2) In Performer 1.0/1.1, bounding cylinders around segments in intersection traversals (pfSegsIsectNode, pfChanPick) will not be transformed properly. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aschaffe Thu Oct 14 18:04:57 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141804.ZM8680@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 18:04:57 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Thu, 14 Oct 93 19:06:41 EDT From: jfr@cae.ca (Jean-Francois Richard 2275) Message-Id: <9310142306.AA20583@cae.ca> To: info-performer@sgi.sgi.com, jrohlf@tubes Subject: One more question on parallel loading with Performer Status: O ----- > >Date: Thu, 14 Oct 93 11:16:05 -0700 >From: jrohlf@tubes.asd.sgi.com (John Rohlf) >Subject: Re: Performer: Using very large databases > > >You can make libpr but not libpf calls from the database >loading process. libpf calls modify a global structure that can >be a source of contention if multiple processes make libpf calls >in parallel. Another option is to use a lock to guarantee that the >database and application processes do not make libpf calls at the >same time. > >What I suggest is: > >1. Load the file from disk into main memory in the database process. >2. Use a lock around each libpf call or group of calls. > > ussetlock(libpfLock); > pfAddChild(a, b); > usunsetlock(libpfLock); > >If you are using the .flt loader then you will need to get and >modify the source code. > >I realize this is painful but rest assured that we are aware of this >problem and consider it a high priority. > > Thanks for the tip, John. This should be good enough for now... once I figure out how to initialize my database process in order to access the shared arena. I am currently using the following utterly useless piece of code to test out the parallel processing approach (I haven't put in the suggested lock calls yet): ... static void *arena; ... main() { ... pfInit( ); arena = pfGetSharedArena( ); pfMultiprocess( PFMP_DEFAULT ); pfConfig( ); if( !fork() ) fvd_loader( ); ... } fvd_loader( void ) { char *buf; buf = pfMalloc( 1000, arena ); for( ; ; ); } The forked process hangs in pfMalloc() (no, it doesn't get stuck in the for loop -- I checked with dbx). I tried replacing pfMalloc() with amalloc() (should that work?) and got the same result. I tried moving the fork() around, as suggested by Lance R. Marrou, and got the same result or worse. I figure I'm probably missing something that should be obvious. Any idea what it is? By the way, will an improved solution to the parallel loading problem make it into the Release version of 1.2, or is it just on a long wish list? ---------------------------------------------------------------------- J.F. Richard, jfr@cae.ca CAE Electronics ---------------------------------------------------------------------- From aschaffe Thu Oct 14 18:07:14 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141807.ZM8693@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 18:07:14 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist From: "Stephen Joyce {75069}" Message-Id: <9310142316.AA19020@swlrgk> To: info-performer@sgi.sgi.com Status: O Does anyone know how to look at MultiGen flight files with materials from material palettes while in Performer. Our models don't show the materials when using perfly 1.0 or perfly 1.1. From aschaffe Thu Oct 14 18:29:41 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310141829.ZM8833@holodeck.asd.sgi.com> Resent-Date: Thu, 14 Oct 1993 18:29:41 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Thu, 14 Oct 93 18:14:12 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310150114.AA18355@tubes.asd.sgi.com> To: "Stephen Joyce {75069}" , info-performer@sgi.sgi.com Subject: materials Status: O > Does anyone know how to look at MultiGen flight files >with materials from material palettes while in Performer. > >Our models don't show the materials when using perfly 1.0 >or perfly 1.1. The .flt converter provided in 1.0 and 1.1 used lmcolor() mode for optimal performance. However this meant that multigen materials were not rendered faithfully. If you want exact correspondence between Performer and multigen materials then call Software Systems and ask for their new loader. From aschaffe Fri Oct 15 12:31:38 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310151231.ZM10560@holodeck.asd.sgi.com> Resent-Date: Fri, 15 Oct 1993 12:31:38 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Fri, 15 Oct 93 09:45:09 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310151645.AA16665@netcom2.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: Performer: Using very large databases Status: O My question is slightly different from Jean-Francois', though I think it's related. It's probably more of a question due to my ignorance of using shared memory in the Unix environment than it is a Performer question. Is it possible for a separate process to create a shared memory arena, malloc and create data arrays into that memory, then have the app/cull/draw processes of my Performer application access tha data in those arrays without copying the data? The first process would be created and running before the Performer app starts. Lew Hitchner Xtensory, Inc. Scotts Valley, CA From aschaffe Mon Oct 18 13:24:10 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310181324.ZM7012@holodeck.asd.sgi.com> Resent-Date: Mon, 18 Oct 1993 13:24:09 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist From: "Richard Mercille" Message-Id: <9310181704.ZM27923@loukoum.neu.sgi.com> Date: Mon, 18 Oct 1993 17:04:02 +0100 X-Mailer: Z-Mail-SGI (3.0B.106 6oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Q? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi All, Some questions concerning Performer: 1) In an application we want to display one model (made with MultiGen) stored as an individual database tree with different attributes (LOD, switched Nodes,etc.). The number of repetitions can vary from frame to frame. We are looking for a method to display this model in the following way without duplicating portions of the scene database: 1. change the attributes for a model 2. send it through the culling 3. repeat steps 1 and 2 to display this model several times in one frame 4. expect one single Display List in the drawing procedure We want to do it this way, because we think that changes in the scene database, like removing, adding or cloning, are very time consuming. Do you see a chance to achieve this? 2) Do you know a way to determine the screen extent of certain objects like the 'old' scrbox routine on VGXT. Is there any new GL or Performer routine that does the same? 3) Is there a method in Performer to mark a model in the cull Callback to recognize it during the draw process? 4) Is there a function that reports the free space in the texture memory? Thanks in advance. Regards, Richard -------------------------------------------- Richard Mercille SGI - European Graphics Lab Switzerland From aschaffe Tue Oct 19 16:01:21 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310191601.ZM12031@holodeck.asd.sgi.com> Resent-Date: Tue, 19 Oct 1993 16:01:21 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist From: patrick@mercury.hongkong.sgi.com (patrick) Message-Id: <9310181025.ZM26320@mercury.hongkong.sgi.com> Date: Mon, 18 Oct 1993 10:25:26 -0700 X-Mailer: Z-Mail (2.1.0 10/1/92) To: info-performer@sgi.sgi.com Subject: Date Walk Through by using Performer Status: O I have a customer want to create large amount of data, did analysis, build model. All theses may be done by Explorer. Then they would like to do data walk through. According to people in SGI Corporate, it was suggested to use Explorer together with Performer. Is there any existing interface code between Explorer and Performer ? Any body has this kind of experience ? Anyone can provide some commet on this ? Is it a good method ? Regard, Patrick TSANG p.s. Please e-mail to the following address "patrick@hongkong.sgi.com" From aschaffe Tue Oct 19 16:00:17 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310191600.ZM12023@holodeck.asd.sgi.com> Resent-Date: Tue, 19 Oct 1993 16:00:16 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist From: "Yves DEMANGE" Message-Id: <9310191331.ZM14258@sgiaix.aix.sgi.com> Date: Tue, 19 Oct 1993 13:31:04 +0100 X-Mailer: Z-Mail-SGI (3.0B.106 6oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Using data from inventor Cc: deum@sgiaix.aix.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi,all As i use an explorer map to build terrain from data, (bathymetric data with sonar image mapped on it) I would use an inventor Loader to build performer application simpliest. questions are : If a such kind exists (Yes/No) or will exists (When ?), is there a possibility do have a terrain implemented on more than one geometry node. Thanks a lot for your availability, Yves From aschaffe Wed Oct 20 00:08:58 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310200008.ZM14207@holodeck.asd.sgi.com> Resent-Date: Wed, 20 Oct 1993 00:08:57 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) Resent-To: info-performer-dist Date: Tue, 19 Oct 93 12:03:07 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310191903.AA27360@tubes.asd.sgi.com> To: hitchner@netcom.com (Lew Hitchner), info-performer@sgi.sgi.com Subject: Re: Performer: Using very large databases Status: O >Is it possible for a separate process to create a shared memory arena, >malloc and create data arrays into that memory, then have the >app/cull/draw processes of my Performer application access tha data in >those arrays without copying the data? The first process would be >created and running before the Performer app starts. This should work if you map the shared memory at the same virtual address space in all processes. Note that you should map the shared memory into the performer process before pfConfig. The best thing to do is whip up a simple test case and experiment. From mtj@babar Tue Oct 19 16:04:11 1993 From: "Michael Jones" Message-Id: <9310191604.ZM23807@babar.asd.sgi.com> Date: Tue, 19 Oct 1993 16:04:08 -0700 In-Reply-To: "Yves DEMANGE" "Using data from inventor" (Oct 19, 1:31pm) References: <9310191331.ZM14258@sgiaix.aix.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: "Yves DEMANGE" , info-performer@sgi.sgi.com, info-performer-dist, aschaffe (Allan Schaffer) Subject: Re: Using data from inventor Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 19, 1:31pm, "Yves DEMANGE" wrote: > Subject: Using data from inventor :As i use an explorer map to build terrain from data, :(bathymetric data with sonar image mapped on it) :I would use an inventor Loader to build performer :application simpliest. : :questions are : : :If a such kind exists (Yes/No) or will exists (When ?), :is there a possibility do have a terrain implemented :on more than one geometry node. The first pass of the new Inventor loader for IRIS Performer has been written and will ship with the upcoming 1.2 release of IRIS Performer. -- 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 mtj@babar Tue Oct 19 16:06:44 1993 From: "Michael Jones" Message-Id: <9310191606.ZM23832@babar.asd.sgi.com> Date: Tue, 19 Oct 1993 16:06:41 -0700 In-Reply-To: patrick@mercury.hongkong.sgi.com (patrick) "Date Walk Through by using Performer" (Oct 18, 10:25am) References: <9310181025.ZM26320@mercury.hongkong.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: patrick@mercury.hongkong.sgi.com (patrick), info-performer@sgi.sgi.com, info-performer-dist, aschaffe (Allan Schaffer) Subject: Re: Date Walk Through by using Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 18, 10:25am, patrick wrote: > Subject: Date Walk Through by using Performer :I have a customer want to create large amount of data, did analysis, build model. :All theses may be done by Explorer. :Then they would like to do data walk through. :According to people in SGI Corporate, it was suggested to use Explorer together :with Performer. Is there any existing interface code between Explorer and :Performer ? Any body has this kind of experience ? Anyone can provide some :commet on this ? Is it a good method ? This will be possible using the new Inventor file reader for the upcoming 1.2 release of IRIS Performer. You could also write a module to write out the data in a format that you understand and write the corresponding loader for performer. This is a simple task for easy-to-parse formats. -- 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 Tue Oct 19 21:41:07 1993 Date: Tue, 19 Oct 93 21:41:39 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310200441.AA26534@netcom5.netcom.com> To: info-performer@sgi.sgi.com Subject: problems with my colors! Status: O I've recently ported my application from Performer 1.0 to 1.2, but my new version has all the wrong colors!!! Both my sky color and the front material colors of my trimesh strips in my geo sets are coming out wrong. I am using an EarthSky that has mode = PFES_FAST and color set with PFES_CLEAR. For my trimesh polygons in my geo sets I'm using indexing into a ColorTable. What happens are a few strange things. 1. the sky color initially is displayed correctly with the color I set in pfESkyColor the first frame but changes to another color as soon as the call to pfClearChan happens in the next frame (I have my own channel draw callback so need to call pfClearChan myself). The sky color displayed is one of the colors in my ColorTable, not the color set in the pfEarthSky. 2. the sky color changes as the view position changes (both for xyz and hpr) and the colors it changes to are those in my ColorTable. 3. the sky intensity changes when the light direction changes My code is essentially unchanged from release 1.0 other than the changes required to conform to new API (I ran the port1.2 script on it). The code worked fine in release 1.0. If anyone has an idea what's happening, please let me know. I also have some weird problems with the colors that come out on my geo set triangles, but it's a lot harder to explain that in an email msg. Probably the color problems are all due to the same cause, so if I can get my sky colors right, there's hope I'll fix my geo set polygon colors as well. Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Wed Oct 20 07:22:37 1993 Date: Wed, 20 Oct 93 10:21:59 -0400 From: darken@enews.nrl.navy.mil (Rudy Darken) Message-Id: <9310201421.AA16857@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: pfNodeTravFuncs question Status: O I'm having a problem getting a performer object to respond correctly to its pre and post callbacks. My objective is to have this object be drawn depending on some boolean value. Actually, I think my problem is more with pfNodeTravMask than pfNodeTravFuncs. Here's what it looks like: { pfGeode *obj; pfNodeTravFuncs (obj, PFTRAV_DRAW, PreObjCallback, PostObjCallback); } long PreObjCallback (pfTraverser *trav, void *data) { if (!obj_on) { pfNodeTravMask (obj, PFTRAV_DRAW, 0x0, PFTRAV_SELF, PF_SET); return PFTRAV_PRUNE; } else { pfNodeTravMask (obj, PFTRAV_DRAW, 0xffffffff, PFTRAV_SELF, PF_SET); return PFTRAV_CONT; } } long PostObjCallback (pfTraverser *trav, void *data) { return PFTRAV_CONT; } Two questions: First, when I replace obj with trav in the callbacks, it core dumps. Shouldn't they be the same? Also, do I have to do anything in the post callback? What is the purpose of the return value? What happens now is that the boolean flag is initially false and even when it changes to true, the object is never drawn. Thanks for any assistance. rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From guest Wed Oct 20 07:40:14 1993 Date: Wed, 20 Oct 93 10:41:05 -0400 From: marrou@raider.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9310201441.AA26638@raider.vsl.ist.ucf.edu> To: hitchner@netcom.com (Lew Hitchner), info-performer@sgi.sgi.com Subject: Re: problems with my colors! Status: O Lew, I had the same problem. I was using pfLights (note the keyword _was_), but when I switched to a pfLightSource, everything worked fine. If you take out all references to pfLights and add a line like: pfAddChild(scene,pfNewLSource(shared_arena)); It may work correctly. It did for me. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From guest Wed Oct 20 07:50:25 1993 Date: Wed, 20 Oct 93 07:51:17 -0700 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9310201451.AA01712@bessie.cs.nps.navy.mil> To: jrohlf@tubes (John Rohlf), info-performer@sgi.sgi.com, hitchner@netcom.com (Lew Hitchner) Subject: Re: Performer: Using very large databases Status: O >Is it possible for a separate process to create a shared memory arena, >malloc and create data arrays into that memory, then have the >app/cull/draw processes of my Performer application access tha data in >those arrays without copying the data? The first process would be >created and running before the Performer app starts. We tried this problem of inter-process arenas here a while back. The problem that we ran into was that unless we had two programs the same size (code and data) or created a very large dummy arena in the smaller one, we would get a message saying the address was in use. It is possible to do it. Take a look at "usgetinfo" and "usputinfo" man pages. Dave Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Wed Oct 20 09:30:25 1993 Date: Wed, 20 Oct 93 09:30:16 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310201630.AA00874@tubes.asd.sgi.com> To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com Subject: Re: pfNodeTravFuncs question Status: O >I'm having a problem getting a performer object to respond >correctly to its pre and post callbacks. My objective is >to have this object be drawn depending on some boolean >value. Actually, I think my problem is more with >pfNodeTravMask than pfNodeTravFuncs. Here's what it >looks like: > >{ >pfGeode *obj; > >pfNodeTravFuncs (obj, PFTRAV_DRAW, PreObjCallback, PostObjCallback); >} > > >long >PreObjCallback (pfTraverser *trav, void *data) >{ > if (!obj_on) > { > pfNodeTravMask (obj, PFTRAV_DRAW, 0x0, PFTRAV_SELF, PF_SET); > return PFTRAV_PRUNE; > } > else > { > pfNodeTravMask (obj, PFTRAV_DRAW, 0xffffffff, PFTRAV_SELF, PF_SET); > return PFTRAV_CONT; > } >} > >long >PostObjCallback (pfTraverser *trav, void *data) >{ > return PFTRAV_CONT; >} > >Two questions: First, when I replace obj with trav in the callbacks, >it core dumps. Shouldn't they be the same? >Also, do I have to do anything in the post callback? What is the >purpose of the return value? >What happens now is that the boolean flag is initially false and >even when it changes to true, the object is never drawn. We kind of lie when we say the draw is a traversal. What really happens is that the cull traverses the node hierarchy and flattens it into a very efficient linear display list which the draw "traverses". So in the draw process there isn't really a concept of a node hierarchy. Consequently, draw callbacks are primarily for tweaking GL. If you just want to "turn off" a node then you should do so further upstream, say in the cull or even the app process. If the boolean is available in the application, then just call pfNodeTravMask there. Otherwise you can use a cull callback to prune the traversal: pfNodeTravFuncs (obj, PFTRAV_CULL, PreCullObjCallback, NULL); long PreCullObjCallback (pfTraverser *trav, void *data) { if (!obj_on) return PFTRAV_PRUNE; else return PFTRAV_CONT; } >Two questions: First, when I replace obj with trav in the callbacks, >it core dumps. Shouldn't they be the same? 'obj' is a node while 'trav' is a pfTraverser. These are totally different beasts. Instead of 'obj' you should use pfGetTravNode(trav) which returns the node that owns the callback. >Also, do I have to do anything in the post callback? No. This may be NULL. >What is the purpose of the return value? To prune, terminate or continue traversal. >What happens now is that the boolean flag is initially false and >even when it changes to true, the object is never drawn. When multiprocessing the flag may not be visible to all processes and may always stay false. From guest Wed Oct 20 09:50:33 1993 Date: Wed, 20 Oct 93 12:52:17 -0400 From: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Message-Id: <9310201652.AA20832@ gizmo.lasc.lockheed.com> To: info-performer@sgi.sgi.com Subject: Multipipe Problem Status: O I have a multipipe application which runs on a SkyWriter under Irix 4.0.5 and Performer 1.0. When recompiled on an Onyx under 5.1.1 and Performer 1.1 it core dumps when multiple pipes are used. Dbx reports the following: Process died at pc 0x47b71c of signal : Bus error [using memory image in core] (dbx) where > 0 pfFree(0x9c9341, 0x9c9328, 0xa88618, 0x9c9341, 0x50005) ["../../../lib/libpr/mall.c":206, 0x47b718] 1 pfDelDList(0x9c9341, 0x9c9328, 0xa88618, 0x9c9341, 0x1004984c) ["../../../lib/libpr/dlist.c":79, 0x4928ec] 2 doCull()(0x9c9341, 0x9c9328, 0xa88618, 0x9c9341, 0x10017c90) ["../../../lib/libpf/pfProcess.C":1232, 0x449ddc] 3 mpCull()(0x9c9341, 0x9c9328, 0xa88618, 0x9c9341, 0x40140000) ["../../../lib/libpf/pfProcess.C":1191, 0x449b38] 4 pfConfig(0x9c9341, 0x9c9328, 0xa88618, 0x9c9341, 0x427580) ["../../../lib/libpf/pfProcess.C":817, 0x448520] 5 main(0x1, 0x7fffaf40, 0xa88618, 0x9c9341, 0x10017c90) ["main.c":387, 0x428b34] and I sometimes see the following on the command line: Performer Fatal (4):pfFree() pointer 0x9c9350 not from pfMalloc Any pointers? Thanx in advance. Barry W. Webb Department 73-6M, Zone 0670 Phone: 4-6952 Fax: 4-6989 From guest Wed Oct 20 11:40:58 1993 Date: Wed, 20 Oct 93 11:40:51 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310201840.AA03586@tubes.asd.sgi.com> To: bwebb@gelac.lasc.lockheed.com (Barry W. Webb), info-performer@sgi.sgi.com Subject: Re: Multipipe Problem Status: O This is the infamous 1.1 multipipe bug. aschaffe knows the workaround. From aschaffe Wed Oct 20 13:43:16 1993 From: aschaffe (Allan Schaffer) Message-Id: <9310201343.ZM15729@holodeck.asd.sgi.com> Date: Wed, 20 Oct 1993 13:43:15 -0700 In-Reply-To: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) "Multipipe Problem" (Oct 20, 12:52pm) References: <9310201652.AA20832@ gizmo.lasc.lockheed.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Subject: Re: Multipipe Problem Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 20, 12:52pm, Barry W. Webb wrote: > I have a multipipe application which runs on a SkyWriter under > Irix 4.0.5 and Performer 1.0. When recompiled on an Onyx under > 5.1.1 and Performer 1.1 it core dumps when multiple pipes are > used. > [...] > and I sometimes see the following on the command line: > > Performer Fatal (4):pfFree() pointer 0x9c9350 not from pfMalloc John Rohlf writes: > This is the infamous 1.1 multipipe bug. aschaffe knows the workaround. Indeed I do. There is a bug in the 1.1 multipipe code. The symptom is a core dump and the error you saw above. The workaround is to do the following after you've created a channel with pfNewChan: ((long**)chan)[3] = NULL; Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Oct 20 22:55:31 1993 Message-Id: <9310210555.AA02558@surreal.asd.sgi.com> To: darken@enews.nrl.navy.mil (Rudy Darken) Cc: info-performer@sgi.sgi.com Subject: Re: pfDCS question In-Reply-To: Your message of "Thu, 07 Oct 93 17:01:47 EDT." <9310072101.AA04242@enews.nrl.navy.mil> Date: Wed, 20 Oct 93 22:55:24 -0700 From: Jim Helman Status: O > How do pfDCS calls affect each other? For example: > > pfDCS *dcs; > > pfDCSMat (dcs, some_matrix); > pfDCSRot (dcs, h, p, r); > > How about the reverse case? > > pfDCSRot (dcs, h, p, r); > pfDCSMat (dcs, some_matrix); I'm not sure if anyone answered this. The principal is one of replacement rather than concatentation. pfDCSMat "replaces" the entire 4x4 matrix. pfDCSRot replaces the rotational component of the matrix, preserving the existing scale or translation. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Oct 21 04:09:44 1993 From: smarc@girl.paris.sgi.com (Marc SIMON Presales support) Message-Id: <9310211109.ZM11639@girl.paris.sgi.com> Date: Thu, 21 Oct 1993 11:09:28 +0100 X-Mailer: Z-Mail-SGI (2.1.0 10/1/92) To: info-performer@sgi.sgi.com Subject: Projected Texture Status: O Hi all, I'm wondering is there a way to play with projected texture in Performer ? I haven't find a way to genarate texture coordinates (s,t,r,q) as texgen() does in GL ... But maybe there is another way to do it , or maybe with Perf 1.2 ??? Thanks Marc Marc SIMON smarc@paris.sgi.com From guest Wed Oct 20 17:17:41 1993 From: ignazio@zorro.melbourne.sgi.com (Ignazio Ranno) Message-Id: <9310211023.ZM19438@zorro.melbourne.sgi.com> Date: Thu, 21 Oct 1993 10:23:24 -0500 X-Mailer: Z-Mail (2.1.0 10/1/92) To: info-performer@sgi.sgi.com Subject: Billboards Status: O I am trying to work out how to use Billboards. However the Manuals seem to briefly touch on the topic and I can't seem to find any examples which use billboards. If anyone has any info or example code that may help I would greatly appreciate it . -- ________ l l Ignazio Ranno l l Systems Engineer ___l_______l___ Silicon Graphics Pty Ltd /// __ __ \\\ Melbourne Australia -\\\ o o ///- E-mail ignazio@melbourne.sgi.com \\\ U /// Phone 61-3-8828211 \\\ uuu /// \\\ \ / /// \\\\\//// l l l l l l l l WW WW From guest Thu Oct 21 09:23:15 1993 Date: Thu, 21 Oct 93 09:23:06 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310211623.AA08947@tubes.asd.sgi.com> To: Jim Helman , darken@enews.nrl.navy.mil (Rudy Darken) Subject: Re: pfDCS question Cc: info-performer@sgi.sgi.com Status: O >> How do pfDCS calls affect each other? For example: >> >> pfDCS *dcs; >> >> pfDCSMat (dcs, some_matrix); >> pfDCSRot (dcs, h, p, r); >> >> How about the reverse case? >> >> pfDCSRot (dcs, h, p, r); >> pfDCSMat (dcs, some_matrix); > >I'm not sure if anyone answered this. The principal is >one of replacement rather than concatentation. pfDCSMat >"replaces" the entire 4x4 matrix. pfDCSRot replaces the >rotational component of the matrix, preserving the >existing scale or translation. > Also, the resulting DCS matrix is: M = S * R * T i.e. - first you scale, then rotate, then translate From guest Thu Oct 21 09:30:03 1993 Date: Thu, 21 Oct 93 09:29:50 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310211629.AA08963@tubes.asd.sgi.com> To: smarc@girl.paris.sgi.com (Marc SIMON Presales support), info-performer@sgi.sgi.com Subject: Re: Projected Texture Status: O >Hi all, > >I'm wondering is there a way to play with projected texture in Performer ? > >I haven't find a way to genarate texture coordinates (s,t,r,q) as texgen() >does in GL ... > >But maybe there is another way to do it , or maybe with Perf 1.2 ??? > We don't directly support projected textures but it's easy to mix the required GL code with Performer. I have a Performer demo which uses both spotlights and shadows which I will eventually clean up and ship sometime. In the future (possibly 1.3) we will directly support projected lights and shadows. From guest Thu Oct 21 10:19:32 1993 Date: Thu, 21 Oct 93 10:19:25 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310211719.AA09058@tubes.asd.sgi.com> To: hitchner@netcom.com (Lew Hitchner), info-performer@sgi.sgi.com Subject: Re: problems with my colors! Status: O >I've recently ported my application from Performer 1.0 to 1.2, but my >new version has all the wrong colors!!! Both my sky color and the >front material colors of my trimesh strips in my geo sets are coming >out wrong. I am using an EarthSky that has mode = PFES_FAST and color >set with PFES_CLEAR. For my trimesh polygons in my geo sets I'm using >indexing into a ColorTable. > >What happens are a few strange things. >1. the sky color initially is displayed correctly with the color I set > in pfESkyColor the first frame but changes to another color as soon > as the call to pfClearChan happens in the next frame (I have my own > channel draw callback so need to call pfClearChan myself). The sky > color displayed is one of the colors in my ColorTable, not the color > set in the pfEarthSky. >2. the sky color changes as the view position changes (both for xyz and > hpr) and the colors it changes to are those in my ColorTable. >3. the sky intensity changes when the light direction changes This is almost certainly a problem with lmcolor mode and probably a bug in Performer. I can't see any obvious problems with the code so I need a simple test case or at least a gldebug trace. From guest Thu Oct 21 20:06:06 1993 Message-Id: <9310220305.AA06314@sakai.nsg.sgi.com> To: info-performer@sgi.sgi.com Subject: How was the sample perfly changed from 1.0 to 2.0? Date: Fri, 22 Oct 93 12:05:57 +0900 From: sakai@sakai.nsg.sgi.com Status: O Hi, I'm tesing the Performer 1.2bata now. But, "perfly" did not work as same as on ver 1.0. I found some differences of the sample codes of 1.0 and 2.0. Will the MR version of 1.2 be same as this bata? If so, Will the performer programing guide be revised? I want it if it is possible to get now. Dose anyone know about this? Regards, Hideki... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Hideki Sakai Software support. Nihon Silicon Graphics K.K Mail stop : TK-325 (Tokyo Japan) Email : sakai@nsg.sgi.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From guest Fri Oct 22 02:58:09 1993 From: pierre@cathy.rennes.sgi.com (pierre VERCRUYSSE) Message-Id: <9310220431.ZM1006@cathy.rennes.sgi.com> Date: Fri, 22 Oct 1993 04:31:29 -0700 X-Mailer: Z-Mail-SGI (2.1.0 10/1/92) To: info-performer@sgi.sgi.com Subject: Howperformer error Status: O Tus anybody can tell me whereis the error I compile and i run with performer 1.0 on a indigo2 XZ 4.0.5H no problem I run it on 440 RE and i have this kind of message : Performer Notice (2): <<<<<<<< Loading file rev1a.flt >>>>>>> Performer Notice (2): Performer Notice (2): <<<<<<<< End file rev1a.flt >>>>>>> GL: X request = 1, X error code = 14 ERROR #93 Error in communication with window server: ERR_WMANIPC with the compile : cc -xansi RevTest.c -o RevTest /usr/src/Performer/lib/libpfflt.a -lpf -lpr -limage -lmpc -lgl_s -lX11_s -lm -lfpe -lC -g In Advance thanks for your help pierre@rennes.sgi.com From guest Fri Oct 22 09:16:51 1993 Date: Fri, 22 Oct 93 09:17:25 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310221617.AA12022@netcom4.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: How was the sample perfly changed from 1.0 to 2.0? Status: O I second the request for the Programming Guide. Where is it? There is a huge amount of documentation missing for 1.2, such as API additions inadvertently left out of the Release Notes (e.g., pfLightSource), nearly everything in the pfutil library. Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Fri Oct 22 08:25:28 1993 From: millard@hawkeye.newport.sgi.com (Ed Millard) Message-Id: <9310221524.AA12473@hawkeye.newport.sgi.com> Subject: Re: Howperformer error To: pierre@cathy.rennes.sgi.com (pierre VERCRUYSSE) Date: Fri, 22 Oct 1993 08:24:43 -0800 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9310220431.ZM1006@cathy.rennes.sgi.com> from "pierre VERCRUYSSE" at Oct 22, 93 04:31:29 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1341 Status: O > > Tus anybody can tell me whereis the error > > I compile and i run with performer 1.0 on a indigo2 XZ 4.0.5H no problem > > I run it on 440 RE and i have this kind of message : > > > Performer Notice (2): <<<<<<<< Loading file rev1a.flt >>>>>>> > > Performer Notice (2): > > Performer Notice (2): <<<<<<<< End file rev1a.flt >>>>>>> > > GL: X request = 1, X error code = 14 > ERROR #93 Error in communication with window server: ERR_WMANIPC > > with the compile : > cc -xansi RevTest.c -o RevTest /usr/src/Performer/lib/libpfflt.a -lpf -lpr > -limage -lmpc -lgl_s -lX11_s -lm -lfpe -lC -g > > In Advance thanks for your help > > pierre@rennes.sgi.com > The is an X11 error on an XCreateWindow call. The error is: #define BadIDChoice 14 /* choice not in range or already used */ Maybe a problem with the visual ID although its hard to say without seeing the code. The range of visual choices are very different between Indigo and RE. ============================================================================= Ed Millard | 18201 Von Karman Avenue Member Technical Staff | Suite 100 Developer's Support Group | Irvine, CA 92715 millard@sgi.com | (714) 756-5975 ============================================================================= From guest Fri Oct 22 09:57:21 1993 From: "Michael Jones" Message-Id: <9310220957.ZM12024@babar.asd.sgi.com> Date: Fri, 22 Oct 1993 09:57:12 -0700 In-Reply-To: hitchner@netcom.com (Lew Hitchner) "Re: How was the sample perfly changed from 1.0 to 2.0?" (Oct 22, 9:17am) References: <9310221617.AA12022@netcom4.netcom.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: hitchner@netcom.com (Lew Hitchner), info-performer@sgi.sgi.com Subject: Re: How was the sample perfly changed from 1.0 to 2.0? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 22, 9:17am, Lew Hitchner wrote: > Subject: Re: How was the sample perfly changed from 1.0 to 2.0? :I second the request for the Programming Guide. Where is it? It's in development. :There is a huge amount of documentation missing for 1.2, such as :API additions inadvertently left out of the Release Notes (e.g., :pfLightSource), nearly everything in the pfutil library. The documentation that these pre-release beta testers are seeking is the IRIS Performer Programming Guide. Obviously, this guide will be shipping with IRIS Performer 1.2, and we are working to make it very thorough and comprehensive. It's encouraging that the beta-testers have had so much success with only the extended man-pages. The code-samples and detailed advice that's been added to them seems to have made a big improvement. I hope that the expanded Programming Guide improves equally. -- 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 Oct 22 10:17:05 1993 id AA02148; Fri, 22 Oct 93 13:16:53 EDT Message-Id: <9310221717.AA03609@sultan> To: info-performer@sgi.sgi.com Cc: grsmith@cvbnet Subject: Please add grsmith@cvbnet.cv.com to the mailing list. Reply-To: dpy@sultan.CV.COM Date: Fri, 22 Oct 93 13:17:23 EDT From: David Youatt Status: O Thanks. -- David Youatt, dpy@sgi.com, (508) 562-4800 SGI Consultant, dpy@sultan.cv.COM for local mail From guest Fri Oct 22 11:09:53 1993 Date: Fri, 22 Oct 93 11:10:47 -0700 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9310221810.AA00736@bessie.cs.nps.navy.mil> To: pierre@cathy.rennes.sgi.com (pierre VERCRUYSSE), info-performer@sgi.sgi.com Subject: Re: Howperformer error Status: O Compile with the shared libs: -lpf_s and -lpr_s vice -lpf -lpr The graphics is different between the two machines Dave Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Mon Oct 25 09:44:15 1993 Message-Id: <9310251644.AA24573@sgi.sgi.com> Date: 25 Oct 93 12:42:00 EST From: "Robert Reif" Subject: Divide by zero errors in psSegsIsectNode To: "info-performer" Status: O I am having a problem with floating point exceptions (Performer Info (101): FP division by zero) occasionally when using pfSegsIsectNode with multiple segments. isect = pfSegsIsectNode(scene, segment, NUM_SEG, PFTRAV_IS_PRIM | PFTRAV_IS_NORM | PFTRAV_IS_CULL_BACK, 0xffffffff, NULL, result, NULL); When run in CASEVision I get the following message: pfSegIsectBox() ["geomath.c":1500, 0xe00df28] The problem only occurs when the segments are near something to intersect. HW/SW V35 elan OS 4.0.5A IDO 4.0.1 C++ 2.1.1 Performer 1.0 Robert Reif reif@ntsc-rd.navy.mil From guest Mon Oct 25 12:11:59 1993 Message-Id: <9310251911.AA02486@surreal.asd.sgi.com> To: "Robert Reif" Cc: "info-performer" Subject: Re: Divide by zero errors in psSegsIsectNode In-Reply-To: Your message of "25 Oct 93 12:42:00 EST." <9310251644.AA24573@sgi.sgi.com> Date: Mon, 25 Oct 93 12:11:44 -0700 From: Jim Helman Status: O In 1.0 (fixed in 1.1), pfSegIsectBox had a bug in the choice of projections which could cause a divide by zero for a segment which lies along the +Y axis in the local coordinate system. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Oct 25 12:50:34 1993 Date: Mon, 25 Oct 1993 15:50:25 -0400 From: William E Gerhard Message-Id: <199310251950.AA08936@stealth.afit.af.mil> To: info-performer@sgi.sgi.com Subject: load.obj in performer 1.2 Cc: akunz@afit.af.mil Status: O I am working with the beta version of pf1.2 and am using the LoadObj function (I have models in wavefront format that I'm trying to read into a Performer tree structure) -- I have been working with Dee Downs here (local SGI) and passed along some information to him. I am having some specific problems. I can get my models to load ok, but when they load they lose all color, materials, and any textures that might have been built into it. Also, my system hangs. I am doing a virtual environment with satellites orbiting the earth. Usually, with multigen flight models, they "whiz" around happily in orbit. I have not heard anything back from Dee and one of my fellow students suggested I ask you for your insight into what might be causing these things to happen. Any info you can pass along about the LoadObj, please do so. I will certainly appreciate it. Andrea Kunz akunz@afit.af.mil \ From aschaffe Wed Oct 27 18:40:47 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9310271840.ZM26613@holodeck.asd.sgi.com> Resent-Date: Wed, 27 Oct 1993 18:40:46 -0700 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) Resent-To: info-performer-dist From: Craig McNaughton Message-Id: <199310271338.AA12356@godzilla.cgl.citri.edu.au> Subject: pfFlatten problems? To: info-performer@sgi.sgi.com Date: Wed, 27 Oct 1993 23:38:10 +1100 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2235 Status: O Hi, I've had a simple application using Performer 1.0 up and running for a while, and on a whim I decided to call pfFlatten() on the scene graph to try and improve performance (there's a lot of SCS transforms in the scene...) Problem is : core dump. dbx stack trace is : (dbx) where > 0 pfXformPt3(dst = (nil), v = (nil), m = 0x7fffb57c) ["../../../lib/libpr/linmath.c":396, 0x4454d4] 1 pfGeode::flatten(pfTraverser*)(this = 0x143f54c0, trav = 0x7fffc564) ["../../../lib/libpf/pfGeode.C":580, 0x4372c4] 2 pfSCS::flatten(pfTraverser*)(this = 0x143f53b0, trav = 0x7fffc564) ["../../../lib/libpf/pfSCS.C":370, 0x42c794] 3 pfSCS::flatten(pfTraverser*)(this = 0x143f53b0, trav = 0x7fffc564) ["../../../lib/libpf/pfSCS.C":370, 0x42c794] 4 pfSCS::flatten(pfTraverser*)(this = 0x143f53b0, trav = 0x7fffc564) ["../../../lib/libpf/pfSCS.C":370, 0x42c794] 5 pfGroup::flatten(pfTraverser*)(this = 0x14334910, trav = 0x7fffc564) ["../../../lib/libpf/pfGroup.C":459, 0x4261bc] 6 pfNode::flatten()(this = 0x14334910) ["../../../lib/libpf/pfNode.C":885, 0x442f4c] 7 pfFlatten(node = 0x14334910) ["../../../lib/libpf/cNode.C":248, 0x40be74] 8 main(argc = 2, argv = 0x7fffc764) ["/usr2/cgl/craig/src/soft/AYUFF/perf_test/simple.c":66, 0x400400] It would seem that the transform of the geometry data is being passed a null pointer for a vertex. I know that there are Geode nodes in the graph that have zero child geosets, and there may well be geosets with 0 tristrips in them (and hence no vertex data or length data present). The scene renders quite happily, so I pretty sure the scene graph is consistent... Will pfFlatten() handle these null geosets and geodes well, or is that the cause of the problem? I know, they really shouldn't be there, but I'm reading my own file format, and there are still a few 'stub' routines for unimplemented geometry.. Thanx for any help.. Craig -- Craig McNaughton | If you want to call me baby (go ahead now) craig@godzilla.cgl.citri.edu.au | If you want to tell me maybe (go ahead now) Advanced Computer Graphics Centre | If you wanna buy me flowers (go ahead now) RMIT, Melbourne, Australia | If you want to talk for hours (go ahead now) From guest Wed Oct 27 19:18:39 1993 Message-Id: <9310280218.AA20504@surreal.asd.sgi.com> To: Craig McNaughton Cc: info-performer@sgi.sgi.com Subject: Re: pfFlatten problems? In-Reply-To: Your message of "Wed, 27 Oct 93 23:38:10 +1100." <199310271338.AA12356@godzilla.cgl.citri.edu.au> Date: Wed, 27 Oct 93 19:18:30 -0700 From: Jim Helman Status: O A geode with no children is legal, but a geoset with a non-zero numVerts and no vertex array is illegal (you lied to Performer when you said there were a non-zero number of vertices). This combination is definitely the cause of your core dump in pfFlatten(). I'd take the null geosets out of the scene graph. 1.2 will have some debug/print traversals to help pick up this sort of thing. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Oct 27 19:56:22 1993 Message-Id: <9310280256.AA20620@surreal.asd.sgi.com> To: Craig McNaughton Cc: info-performer@sgi.sgi.com Subject: Re: pfFlatten problems? In-Reply-To: Your message of "Wed, 27 Oct 93 19:18:30 PDT." <9310280218.AA20504@surreal.asd.sgi.com> Date: Wed, 27 Oct 93 19:56:14 -0700 From: Jim Helman Status: O I lied. Turns out there was a bug in 1.0/1.1 which prevents zero length geosets from being flattened. I also wouldn't try zero length geosets in billboards. The fix went in a few months ago and will appear in 1.2. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From aaron@skips.dseg.ti.com Wed Oct 27 22:12:43 1993 Date: Wed, 27 Oct 93 23:31:00 CDT From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9310280431.AA06835@skips.dseg.ti.com> To: info-performer-dist Subject: How to get some simple statistics Status: O I am using Beta 1.2 Performer and I'm trying to get some statistics output every couple of seconds. I basically want: (1) Number of triangles (2) Framerate (3) CPU load in samples of 2 seconds. I have been working to get this working for a very long time, and I have run into wall after wall. I can poll for the number of triangles as done in pguide/libpf/progs/stats.c but this only works when I have the gfx statistics being printed. I then tried to enable all of the StatsClasses myself (just to get the number of triangles). So I looked in perfly/gui.c and got the stat_values[] for the "Gfx" and tried to pfStatsClass(stats,PFFSTATS_ENPFTIMES|PFSTATS_ENGFX| PFFSTATS_ENDB|PFFSTATS_ENCULL|PFSTATSHW_ENCPU,PFSTATS_ON); but that didn't seem to do the trick. I still couldn't get the number of triangles without turning on the Gfx statistics print feature. (Much less anything else). I haven't been able to pfQueryStats on anything except the PFQSTATS_GFX_GEOM_TRIS and as said, they only come in when I go to Gfx stats drawing from the GUI. So how can I get the 3 above statistics on a period of 2 seconds? (As in how do I modify Perfly to let me do this?) Thanks, Aaron Hightower ----------------------------------------------------------------------------- Aaron Hightower :: Texas Instruments aaron@dseg.ti.com Visualization and Simulation Technology Development (214)575-6759 (w) Here he comes, here comes speed racer (214)517-9245 (h) From guest Wed Oct 27 21:50:48 1993 Date: Thu, 28 Oct 93 00:50:18 -0400 From: steve@pith.umecfr.maine.edu (Stephen Shaler) Message-Id: <9310280450.AA11446@pith.umecfr.maine.edu> To: info-performer@sgi.sgi.com Subject: Applicability of Performer for Log Sawing Visualization Status: O I wish to develop an application in which a log can be realistically visualized in 3-D and then sawn (sectioned) along some arbitrary plane (typically along the length). We have developed a data base which defines the periphery of the log exterior, the pith of the log (approximately the center at any x-section), knots within the log, and other assorted significant characteristics such as mineral stain. There are approximately 800,000 vertices which in a typical log. In order to have a realistic visualization, I would plan on being able to apply textures which correspond to sound wood, knots, stain, etc. My questions then are [1] can this be done (I assume so), [2] is Performer the best software approach to do this or would some commercial solid modeler work better. I assume Performer would be cheaper and it seems to me that in most cases an application package just never seems to be able to quite do what you want. Also, is this a doable project for a reasonably proficient programmer (say a 2 yr. MS student) or would I be better off hiring a full-time programmer to get it done in half the time. I would appreciate any feedback or perspective on these general questions. I will be writing a proposal shortly (due in 2 weeks) and want to be realistic in what can be done. Thanks for your time. Stephen Shaler Associate Professor of Wood Science Forest Products Laboratory University of Maine steve@pith.umecfr.maine.edu Stephen Shaler Forest Products Laboratory University of Maine steve@pith.umecfr.maine.edu From aschaffe Wed Oct 27 22:30:21 1993 Date: Wed, 27 Oct 93 22:30:21 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9310280530.AA27530@holodeck.asd.sgi.com> To: info-performer Subject: Administrivia, FAQ, etc. Status: O Hello Subscribers, I've finished what I will call version 0.9 of the Performer FAQ list. It's a preliminary version, and as a gift you can all have an early copy. I will send it in the next message. If you have comments, corrections, or questions about the FAQ, please send them directly to me. I'm sure it contains some errors, and finding them is an exercise for alert readers. Also, the bug section of the FAQ is somewhat terse at the moment. I'll be filling it in considerably as time goes on. A little list administrivia. The size of the mailing list has stabilized at ~250 subscribers, and volume has stabilized at ~15-20 messages per week. This is pretty good to see, since the main problem in the beginning was signal/noise. Also, a new forwarding scheme (courtesy of Jim Helman) has eliminated much of the bounced mail. Happy hacking, Allan ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From aschaffe Wed Oct 27 22:33:36 1993 Date: Wed, 27 Oct 93 22:33:36 -0700 From: aschaffe (Allan Schaffer) Message-Id: <9310280533.AA27576@holodeck.asd.sgi.com> To: info-performer Subject: IRIS Performer Frequently Asked Questions Status: O Archive-name: sgi/faq/performer SGI performer Frequently Asked Questions (FAQ) Topics covered in this FAQ: -------------------------- -1- How can I quickly find the question I want in this FAQ? -2- What is IRIS Performer? -3- Where can I get more technical information about IRIS Performer? -4- Where can I get more product information about IRIS Performer? -5- What are the released versions of IRIS Performer? -6- Is there a IRIS Performer file format? -7- What database file formats can IRIS Performer read? -8- Is there an IRIS Inventor file reader for IRIS Performer? -9- What are the .tlf files used by the Performer Town and Village? -10- What are the minimum requirements for using IRIS Performer? -11- How do I make GL calls from within a IRIS Performer program? -12- How do I overlay graphics on top of my Performer scene? -13- What is the difference between phases FREE, FLOAT, and LOCK? -14- Which rendering primitives does IRIS Performer support? -15- How do I do triangle meshes in Performer? -16- pfInit(): mmap failed for /dev/zero -17- IRIX 5.x Bug in Performer Town or Village demos -18- 1.0 Doc Bug in pfMakePolarSeg() man page -19- 1.0 Doc Bug in pfDispList() man page -20- 1.0 Doc Bug in PFPG (simple.c) -21- 1.0 Bug in pfGetTime() -22- 1.0 Bug in pfNodeBBox() -23- 1.0 Bug in pfInitGfx() with Z-buffer on RealityEngine -24- 1.0 Bug in libpfflt combineLODs() -25- 1.0 Bug with two-sided material and pfMtlColorMode() -26- 1.0 Bug in pfFilePath() -27- 1.0 Bug in pfGetCurGState() -28- 1.0 Bug in pfGetCurState() -29- 1.0 Bug with cloned scenes -30- 1.0 Bug intersections in collide.c -31- 1.0 Bug with flattened pfLightPoints -32- 1.0 Bug intersections with pfSequences -33- 1.0 Bug intersections with non-indexed quads -34- 1.0/1.1 Bug intersections with pfSwitch'es -35- 1.0/1.1 Bug with pfTexture() -36- 1.0/1.1 Bug with pfAntiAlias() -37- 1.0/1.1 Bug with pfFlatten() -38- 1.0/1.1 Bug with pfSequences -39- 1.0/1.1 Bug with zero-length pfGeoSets -40- 1.0/1.1 Bug with pfClosestPtOnPlane() -41- 1.0/1.1 Bug on ELAN/XS with wireframe PFGS_QUADS -42- 1.1 Bug with FP underflow -43- 1.1 Bug with Multipipe Onyx -44- Credits ---------------------------------------------------------------------- Subject: -1- How can I quickly find the question I want in this FAQ? Date: 27 May 93 00:00:01 EST - This FAQ follows the RFC1153 recommendations for message digests and thus can be viewed easily with newsreaders that understand message digests. - Each question has a Subject: line, so you can easily step through the answers with rn's ^G command. - Each question is marked with a "dash number dash" so that you can find any answer with a simple search pattern. - Questions marked with a '+' are new this posting; those marked with a '!' have significant new content since the last edition. ------------------------------ Subject: -2- What is IRIS Performer? Date: 06 Oct 93 00:00:01 EST IRIS Performer is a software development environment that supports programmers implementing high performance graphics applications on Silicon Graphics products. It offers both high level facilities for visual simulation and virtual reality tasks and an application-neutral high-performance hardware-oriented graphics toolkit. The outer application specific layer of IRIS Performer implements the tasks needed by visual simulation applications: it performs culling so that only potentially visable geometry is sent to the graphics hardware; it controls multiple display channels; it provides fast intersection tests with simulation databases; and most importantly, it orchestrates all of this in parallel with rendering on multiple processor IRIS systems. The lower-level rendering portion of IRIS Performer is designed for maximum performance: its efficient data structures reflect the details of CPU, cache, and memory system architectures; its tuned rendering loops convert the system CPU into an optimized data movement engine; and its optimized state management system optimizes hardware utilization. IRIS Performer provides a high-performance portability path across the Silicon Graphics product line. The low level library is implemented as a hardware-specific shared library, so applications based on IRIS Performer can achieve peak performance on graphics systems from Elan to RealityEngine2 without changes or recompilation. The product includes a programmer's guide and printed man pages, as well as on-line man pages, test and demonstration programs, and complete real-time visual simulation applications. These applications are provided in source form as an examples of how to build real-time simulation systems using IRIS Performer. Also included are several databases in FLIGHT and Wavefront "OBJ" format and source code for database readers that can load them. ------------------------------ Subject: -3- Where can I get more technical information about IRIS Performer? Date: 06 Oct 93 00:00:01 EST One method is to join the IRIS Performer mailing list. The list is intended to be an unmoderated, free-form discussion of IRIS Performer with issues both technical and non-technical; and to provide feedback to Silicon Graphics about the product. Much like the comp.sys.sgi.* newsgroups, it is not an official support channel but is monitored by several interested SGI employees familiar with the toolkit. To become a subscriber to the IRIS Performer mailing list you must send email to: info-performer-request@sgi.com New subscribers are added "by hand". Once your request is processed you will recieve submission/posting instructions, some guidelines, and a current copy of the Performer Frequently-Asked-Questions (FAQ) list. ------------------------------ Subject: -4- Where can I get more product information about IRIS Performer? Date: 06 June 93 00:00:01 EST For product information about IRIS Performer or SGI Visual Simulation issues contact John Burwell (johnnyb@asd.sgi.com). To learn about SGI Virtual Reality solutions contact Joshua Mogal (415) 390-1460 (mogal@asd.sgi.com). To just give in and buy a copy ($495 US) call SGI Express at 1-800-800-7441, or to have both a demonstration and a presentation call your local SGI sales office. ------------------------------ Subject: -5- What are the released versions of IRIS Performer? Date: 06 Oct 93 00:00:01 EST IRIS Performer 1.0: For machines running IRIX 4.x only IRIS Performer 1.1: For machines running IRIX 5.x only IRIS Performer 1.2 is currently in an early stage of beta testing. It will run on machines running either IRIX 4.x or IRIX 5.x ------------------------------ Subject: -6- Is there a IRIS Performer file format? Date: 26 Oct 93 00:00:01 EST Not at this time. Currently, IRIS Performer has functionality to load other vendors' database files at run time. ------------------------------ Subject: -7- What database file formats can IRIS Performer read? Date: 26 Oct 93 00:00:01 EST IRIS Performer 1.0 and 1.1 include database loaders for MultiGen v11 "flt", SGI "bin", and SGI "obj" formats. IRIS Performer 1.2 will include loading utilities and file loaders for additional file formats, including Coryphaeus "dwb", MultiGen v12 "flt", AutoCAD "dxf", and Wavefront "obj". You can get a MultiGen 12 version of LoadFlt() for Performer 1.0 and 1.1 by contacting Norm Miller at Software Systems, the makers of MultiGen. Mr. Norm Miller Software Systems 1884 The Alameda San Jose, CA 95126 P: (408) 247-4326 F: (408) 247-4329 multigen!norm@uunet.UU.NET ------------------------------ Subject: -8- Is there an IRIS Inventor file reader for IRIS Performer? Date: 26 Oct 93 00:00:01 EST Not at this time. An IRIS Inventor file reader is a planned feature for Performer 1.2. ------------------------------ Subject: -9- What are the .tlf files used by the Performer Town and Village? Date: 26 Oct 93 00:00:01 EST They are encrypted .flt files of the Town and Village database. Only the "demo" version of perfly can read these files. Unencrypted versions of the Town and Village databases are planned to be included in Performer 1.2. ------------------------------ Subject: -10- What are the minimum requirements for using IRIS Performer? Date: 06 June 93 00:00:01 EST IRIS Performer requires IRIX 4.0.5 or later. Because IRIX 4.0.5F added several new Graphics Library (GL) calls to support RealityEngine features, any application that uses GL routines or tokens found only in 4.0.5F and later, will not run properly under 4.0.5C and earlier releases. ------------------------------ Subject: -11- How do I make GL calls from within a IRIS Performer program? Date: 26 Oct 93 00:00:01 EST GL calls can only be made from a process that has a GL context. In multi-process Performer applications only the draw process has GL context, so you must make your GL calls in a function called in the draw process. The pipe initialization callback, draw function callback, and node draw callbacks are all executed in the draw process. In an application that only will ever run single-process, GL calls can be made from anywhere in the program. To set up a pipe initialization callback, see the pfInitPipe() man page. To set up a draw function callback, see the pfChanDrawFunc() man page. To set up a node draw callback, see the pfNodeTravFuncs() man page. ------------------------------ Subject: -12- How do I overlay graphics on top of my Performer scene? Date: 06 Oct 93 00:00:01 EST Typically this is done to implement a heads-up display (HUD). In the draw function callback, the basic algorithm is: save state with pfPushState() load default state with pfBasicState(), as needed disable textures, fog, & lighting, as needed save & clear projection matrix ortho2() save & clear modelling matrix draw() restore modelling matrix restore projection matrix restore state with pfPopState() Or, you can draw your static info in the overlay planes and only redraw it when the window receives a REDRAW event (moved, resized, etc.). Changing between drawing to the overlays and drawing to regular bitplanes takes a big hit. For things that need to be updated real-time, draw() would consist of: zfunction(ZF_ALWAYS); zwritemask(0x0); draw HUD stuff zfunction(ZF_LEQUAL); zwritemask(0xffffffff); ------------------------------ Subject: -13- What is the difference between phases FREE, FLOAT, and LOCK? Date: 26 Oct 93 00:00:01 EST PFPHASE_FREE_RUN wakes the application and draw processes up on the next video field boundary after the draw finishes. i.e. it's Performer's version of the usual run as-fast-as-I-can or as-slow-as-I-must mode that most simple graphics programs use. PFPHASE_FLOAT wakes the application up only on frame boundaries, i.e. time = n*(1/frame_rate). However, the draw process "floats" with respect to the frame rate and wakes up on the next possible field boundary and then does a swapbuffers() when it's done, regardless of whether it finished drawing in time for the desired frame rate. Hence you see every frame that's drawn to the backbuffer, but it may not appear at exactly the time for which it was planned. If you never frame extend, it behaves like PFPHASE_FIXED. Latency is variable. PFPHASE_LOCK wakes the application and draw up only on frame boundaries and only swaps on frame boundaries. The advantage is that each new image always appears at precisely the time for which it was rendered. The disadvantage is that if the draw runs even slightly over a frame time, you skip that entire frame and are stuck with an outdated picture for a frame. Latency is fixed. For more information see the pfPhase() man page or section 7.1.2 of the PFPG. ------------------------------ Subject: -14- Which rendering primitives does IRIS Performer support? Date: 06 Oct 93 00:00:01 EST Points (PFGS_POINTS), Independent line segments (PFGS_LINES), connected line strips (PFGS_LINESTRIPS), Independent Triangles (PFGS_TRIS), Connected triangle strips (PFGS_TRISTRIPS), Independent quadrilaterals (PFGS_QUADS). ------------------------------ Subject: -15- How do I do triangle meshes in Performer? Date: 06 Oct 93 00:00:01 EST You must change your triangle meshes to triangle strips by hand. In Performer 1.2, pfuMeshGSet (from libpfutil) will do this for you. ------------------------------ Subject: -16- pfInit(): mmap failed for /dev/zero Date: 26 Oct 93 00:00:01 EST This means that you tried to run a Performer 1.0 application (such as a 4.x version of perfly) on a machine running IRIX 5.x. Virtual memory management is different in IRIX 5.x. In order for your program to work properly you must: % setenv PFTMPDIR /usr/tmp ------------------------------ Subject: -17- IRIX 5.x Bug in Performer Town or Village demos Date: 26 Oct 93 00:00:01 EST It was reported that perfly would cause an Onyx RE or VTX running IRIX 5.0 to hang. This was fixed in 5.0.1. In 5.0.1, perfly would generate floating point exceptions due to a bug in the font manager library (libfm). This was fixed in 5.1. ------------------------------ Subject: -18- 1.0 Doc Bug in pfMakePolarSeg() man page Date: 26 Oct 93 00:00:01 EST The man page for pfMakePolarSeg contradicts itself with respect to the meaning of azimuth and elevation. The correct paragraph should be: pfMakePolarSeg sets dst to the segment which starts at pos and has length length and points in the direction specified by azi and elev. azi specifies the azimuth (or heading), which is the angle which the projection of the segment in the X-Y plane makes with the +Y axis. elev specifies the elevation (or pitch), the angle with respect to the X-Y plane. The positive Y axis is azi=0 and elev=0. Azimuth follows the right hand rule about the +Z azis, e.g. - +90 degrees is the -X axis. Similarly, elevation follows the right hand rule about the X axis, e.g. - +90 degrees is the +Z axis. Note that in IRIS Performer 1.0, an azi and elev of 0.0 is equivalent to the +X axis while in 1.1, this has been changed to the +Y axis. ------------------------------ Subject: -19- 1.0 Doc Bug in pfDispList() man page Date: 26 Oct 93 00:00:01 EST The pfDispList man page says the size argument is in bytes; it should say words. ------------------------------ Subject: -20- 1.0 Doc Bug in PFPG (simple.c) Date: 26 Oct 93 00:00:01 EST The program simple.c in the IRIS Performer Programming Guide (PFPG) does not bind a light and draws a black image on Elan systems. The corrected version, which creates and binds a light in the pipe initialization callback, is in /usr/src/Performer/src/pguide ------------------------------ Subject: -21- 1.0 Bug in pfGetTime() Date: 26 Oct 93 00:00:01 EST In 1.0, pfGetTime() would occasionally return bad values (off by 4000+ seconds) on Indigo2 and machines without a fast counter, e.g. PowerSeries/IO2. There was no workaround. ------------------------------ Subject: -22- 1.0 Bug in pfNodeBBox() Date: 26 Oct 93 00:00:01 EST pfNodeBBox did not set the bounding box of a node. A symptom was that the bounding boxes of the node would not change when modifying a parent pfDCS. The workaround was to OR the value 0x0010 into the mode, e.g.- pfNodeBBox(node, &bbox, PFN_BMODE_STATIC | 0x0010); ------------------------------ Subject: -23- 1.0 Bug in pfInitGfx() with Z-buffer on RealityEngine Date: 26 Oct 93 00:00:01 EST pfInitGfx on RealityEngines would call lsetdepth(0x0, 0x0), essentially disabling zbuffering. The workaround was to call lsetdepth explicitly after pfInitGfx, in the pipe initialization callback. ------------------------------ Subject: -24- 1.0 Bug in libpfflt combineLODs() Date: 26 Oct 93 00:00:01 EST combineLODs() 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. ------------------------------ Subject: -25- 1.0 Bug with two-sided material and pfMtlColorMode() Date: 26 Oct 93 00:00:01 EST 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. ------------------------------ Subject: -26- 1.0 Bug in pfFilePath() Date: 26 Oct 93 00:00:01 EST pfFilePath would exit with a FATAL error if it was called twice. ------------------------------ Subject: -27- 1.0 Bug in pfGetCurGState() Date: 26 Oct 93 00:00:01 EST pfGetCurGState returned a pfGeoState which was the top of the state stack rather than the most recently applied pfGeoState. ------------------------------ Subject: -28- 1.0 Bug in pfGetCurState() Date: 26 Oct 93 00:00:01 EST pfGetCurState returned a pfGeoState which was the top of the state stack rather than the current pfState. ------------------------------ Subject: -29- 1.0 Bug with cloned scenes Date: 26 Oct 93 00:00:01 EST pfClone()'ed scenes were not properly cleaned and did not properly propagate updates. In particular, cloned pfSequences did not work. ------------------------------ Subject: -30- 1.0 Bug intersections in collide.c Date: 26 Oct 93 00:00:01 EST collide.c was shipped with a hardwired intersection mode which turned off intersection caching, substantially reducing intersection performance. ------------------------------ Subject: -31- 1.0 Bug with flattened pfLightPoints Date: 26 Oct 93 00:00:01 EST pfFlatten()'ed pfLightPoints were broken for multiprocessing modes when the application and cull processes were separate. ------------------------------ Subject: -32- 1.0 Bug intersections with pfSequences Date: 26 Oct 93 00:00:01 EST Intersections with pfSequences could sometimes turn them off (PFSEQ_STOP). ------------------------------ Subject: -33- 1.0 Bug intersections with non-indexed quads Date: 26 Oct 93 00:00:01 EST Intersection caching for non-indexed quads was broken and could case a core dump when intersection with pfGeoSets of this type. ------------------------------ Subject: -34- 1.0/1.1 Bug intersections with pfSwitch'es Date: 26 Oct 93 00:00:01 EST Intersections with pfSwitch'es whose value is PFSWITCH_OFF could cause a core dump. ------------------------------ Subject: -35- 1.0/1.1 Bug with pfTexture() Date: 26 Oct 93 00:00:01 EST On RealityEngine systems, EXTERNAL format was ignored. ------------------------------ Subject: -36- 1.0/1.1 Bug with pfAntiAlias() Date: 26 Oct 93 00:00:01 EST On RealityEngine systems, pfAntialias(PFAA_OFF) did not turn off multisampling. ------------------------------ Subject: -37- 1.0/1.1 Bug with pfFlatten() Date: 26 Oct 93 00:00:01 EST pfFlatten did not dirty bounding spheres of flattened nodes so they had improper bounds and would not cull correctly. ------------------------------ Subject: -38- 1.0/1.1 Bug with pfSequences Date: 26 Oct 93 00:00:01 EST pfSequences: PFSEQ_RESUME ignored children's display times and drew subsequent children for 1 frame only. ------------------------------ Subject: -39- 1.0/1.1 Bug with zero-length pfGeoSets Date: 26 Oct 93 00:00:01 EST pfGeoSets with primitive counts of zero caused core dumps in pfFlatten() and elsewhere. ------------------------------ Subject: -40- 1.0/1.1 Bug with pfClosestPtOnPlane() Date: 26 Oct 93 00:00:01 EST pfClosestPtOnPlane returned wrong result. Also, the man page had the wrong prototype. ------------------------------ Subject: -41- 1.0/1.1 Bug on ELAN/XS with wireframe PFGS_QUADS Date: 26 Oct 93 00:00:01 EST On EXPRESS Graphics platforms (XS, XS24, ELAN, etc), wireframe quads have a stray line from one vertex to "infinity" when displayed in wireframe mode. ------------------------------ Subject: -42- 1.1 Bug with FP underflow Date: 26 Oct 93 00:00:01 EST The cull process could encounter an FP underflow that could periodically affect cull performance. ------------------------------ Subject: -43- 1.1 Bug with Multipipe Onyx Date: 26 Oct 93 00:00:01 EST There is a bug in the 1.1 multipipe code. The symptom is a core dump and an error like: Performer Fatal (4):pfFree() pointer 0x9c9350 not from pfMalloc The workaround is to do the following after you've created a channel with pfNewChan: ((long**)chan)[3] = NULL; ------------------------------ Subject: -44- Credits Date: 27 Oct 93 00:00:01 EST The Performer FAQ is compiled by: Allan Schaffer aschaffe@sgi.com Special thanks are due to the Performer engineering team at Silicon Graphics, whose collective input has formed much of what you see here. ------------------------------ ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Oct 27 23:28:40 1993 From: "Michael Jones" Message-Id: <9310272328.ZM29008@babar.asd.sgi.com> Date: Wed, 27 Oct 1993 23:28:31 -0700 In-Reply-To: steve@pith.umecfr.maine.edu (Stephen Shaler) "Applicability of Performer for Log Sawing Visualization" (Oct 28, 12:50am) References: <9310280450.AA11446@pith.umecfr.maine.edu> X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Applicability of Performer for Log Sawing Visualization Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Oct 28, 12:50am, Stephen Shaler wrote: > Subject: Applicability of Performer for Log Sawing Visualization :... There are approximately 800,000 vertices which in a typical log. In order :to have a realistic visualization, I would plan on being able to apply textures which correspond :to sound wood, knots, stain, etc. This is a neat application, but I never realized wood had so many vertices ;-) :My questions then are [1] can this be done (I assume so), Yes. :[2] is Performer the best software :approach to do this or would some commercial solid modeler work better. I assume Performer would :be cheaper and it seems to me that in most cases an application package just never seems to be :able to quite do what you want. Also, is this a doable project for a reasonably proficient :programmer (say a 2 yr. MS student) or would I be better off hiring a full-time programmer to get :it done in half the time. IRIS Performer is a fine tool here, but I imagine that the bulk of the work will be on the application side rather than in the graphics. If I understand this right, you would start with a capped-cylinder made of polygons as the original log. Then the first pass of the log through the saw slices it into two parts -- this is equivalent to slicing the original geometric definition along a user defined plane. Subsequent passes would slice some subset of the previous fragments along different planes (caused by translating or rotating the log). You would do this until you had a truck- load of 2x4's and 800,000 vertices. Right? :I would appreciate any feedback or perspective on these general questions. :I will be writing a proposal shortly (due in 2 weeks) and want to be :realistic in what can be done. This seems feasible and not too difficult. The essential operations are slicing an object by a plane and deciding which existing objects would be effected by a pass through the mill. The slicer will need to cap (create new faces) where the slicing is done. You could even make synthetic texture maps as you go, based on the radial cut position into the log, saw speed, wood type, and so on. Please keep us posted on your progress, and don't get saw dust in your keyboard. -- 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 Thu Oct 28 01:42:17 1993 From: rmann@remarque.berkeley.edu (Roderick L. Mann) Message-Id: <9310280842.AA16992@remarque.berkeley.edu> Subject: pfSync() and faster dynamics To: info-performer@sgi.sgi.com (Performer Discussion) Date: Thu, 28 Oct 1993 01:42:05 -0700 (PDT) Content-Type: text Content-Length: 566 Status: O I am somewhat new to Performer, so forgive this (probably) bonehead question. I want to run my vehicle dynamics loop at an integral multiple of the cull/draw calls. That is, if the frame rate is 30 Hz, I'd like to cruise through my dynamics simulation at 60 or 120 Hz. The reason for this is to provide faster feedback to other systems, including a motion platform and cockpit displays (not the monitors). What would be the best way to do this? I am fairly sure that the model is simple enough to allow such a high rate. Rick -------- rmann@remarque.berkeley.edu From guest Thu Oct 28 05:51:23 1993 Message-Id: <9310281251.AA29288@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA Date: Thu, 28 Oct 1993 08:51:11 -0500 To: info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: Re: Applicability of Performer for Log Sawing Visualization Status: O My two cents: I haven't used performer, but based on the description of performer and the description of your project, it seems like the fit is loose. I think that performer is better at out the window simulations with large datasets and provides less of an advantage for smaller room-size simulations. It is not a solid modeler. For my PhD thesis, I created a Virtual Workshop which had a table saw, band saw, radial arm saw, drill press, and milling machine. Designers could choose different types of stock (mostly wood) and machine it into parts that could then be assembled into projects. On the third iteration of this project, I finally got smart and got a real solid modeling kernel that I used for boolean operations (subtracting swept tools from parts.) I think that having a good solid modeler made all of the difference when it came time to develop. I simply used GL on the SGI machine for rendering (z-buffered, lighted, shaded parts - I didn't use textures, but the SGI machines allow textures). Performer isn't a solid modeler at all. It accepts geometry (already defined) and determines the best way to display it. It determines what geometry will not be visible in a scene and doesn't bother rendering it (scene culling) and also maintains frame rates (draw less of a more complex scene so that the frame is ready to be displayed at the right time) to maintain interactivity. Unless you have a Reality Engine, you won't get real time, interactive textures right now. However, from your brief description, it doesn't sound like high-frame rate, texture-mapped images is the most important feature of your application. I would suggest getting a solid modeling kernel like ACIS from Spatial Technologies in Boulder, CO. (303) 449-0649. Their university licensing terms are fairly reasonable, and, although it is a big chunk of code (my executable was about 10 Meg when I included the kernel), the functionality is extensive and the code is quite robust. Using a kernel like ACIS, I think your biggest task is learning GL (or OpenGL), deciding on a representation for your data that will allow it to be stored in an ACIS solid, and then coding. By the way, you will also need C++ (and need to know how to use C++) for your application to use ACIS. That can add a few months onto the development time for a C programmer. I think that 2 years (Masters student) should allow ample time for development. A knowledgeable ACIS hacker who knows GL could easily do it in 6 months (unless there are some subtleties to the problem that I don't understand) and possibly in 2 to 4 months, depending on the complexity of the data, availability of the textures, etc. By the way, if all you want to do is slice an dataset with a plane and cap the ends of the sliced solids, you don't absolutely need a solid modeler, but ACIS gives you a robustness that you can't program in by yourself, and as soon as you decide to include non-planar sections or cuts, you can't beat having the capability already built in. Add a minimum of 6 months to the project for designing and writing your own solid modeler with planar boolean operations (just a guess). >I wish to develop an application in which a log can be realistically >visualized in 3-D and >then sawn (sectioned) along some arbitrary plane (typically along the length). >We have developed >a data base which defines the periphery of the log exterior, the pith of the >log (approximately >the center at any x-section), knots within the log, and other assorted >significant characteristics >such as mineral stain. There are approximately 800,000 vertices which in a >typical log. In order >to have a realistic visualization, I would plan on being able to apply >textures which correspond >to sound wood, knots, stain, etc. > >My questions then are [1] can this be done (I assume so), [2] is Performer the >best software >approach to do this or would some commercial solid modeler work better. I >assume Performer would >be cheaper and it seems to me that in most cases an application package just >never seems to be >able to quite do what you want. Also, is this a doable project for a >reasonably proficient >programmer (say a 2 yr. MS student) or would I be better off hiring a >full-time programmer to get >it done in half the time. > >I would appreciate any feedback or perspective on these general questions. I >will be writing a >proposal shortly (due in 2 weeks) and want to be realistic in what can be done. > >Thanks for your time. > >Stephen Shaler >Associate Professor of Wood Science >Forest Products Laboratory >University of Maine >steve@pith.umecfr.maine.edu >Stephen Shaler > >Forest Products Laboratory >University of Maine >steve@pith.umecfr.maine.edu ------------------------- 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 Oct 28 09:23:29 1993 Date: Thu, 28 Oct 93 09:23:21 -0700 From: jrohlf@tubes (John Rohlf) Message-Id: <9310281623.AA28491@tubes.asd.sgi.com> To: rmann@remarque.berkeley.edu (Roderick L. Mann), info-performer@sgi.sgi.com (Performer Discussion) Subject: Re: pfSync() and faster dynamics Status: O >I want to run my vehicle dynamics loop at an integral multiple >of the cull/draw calls. That is, if the frame rate is 30 Hz, I'd >like to cruise through my dynamics simulation at 60 or 120 Hz. >The reason for this is to provide faster feedback to other >systems, including a motion platform and cockpit displays (not >the monitors). > >What would be the best way to do this? I am fairly sure that the >model is simple enough to allow such a high rate. Probably the best method is to fork a processs which runs the dynamics simulation and communicates the results to Performer's APP process through shared memory. Remember that this dynamics process should not modify any Performer data structures. You can use the video clock through pfVClockSync to synchronize this process. pfVClockSync() uses the video retrace clock for synchronization so it won't work for rates > the video rate which is usually 60Hz. Therefore, running at 120Hz is problematic and requires a different synchronization mechanism. You could spin on pfGetTime() if you had a CPU to burn. From guest Thu Oct 28 12:13:55 1993 Date: Thu, 28 Oct 93 14:14:00 CDT From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9310281914.AA09638@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: How to get some simple statistics Status: O I am using Beta 1.2 Performer and I'm trying to get some statistics output every couple of seconds. I basically want: (1) Number of triangles (2) Framerate (3) CPU load in samples of 2 seconds. I have been working to get this working for a very long time, and I have run into wall after wall. I can poll for the number of triangles as done in pguide/libpf/progs/stats.c but this only works when I have the gfx statistics being printed. I then tried to enable all of the StatsClasses myself (just to get the number of triangles). So I looked in perfly/gui.c and got the stat_values[] for the "Gfx" and tried to pfStatsClass(stats,PFFSTATS_ENPFTIMES|PFSTATS_ENGFX| PFFSTATS_ENDB|PFFSTATS_ENCULL|PFSTATSHW_ENCPU,PFSTATS_ON); but that didn't seem to do the trick. I still couldn't get the number of triangles without turning on the Gfx statistics print feature. (Much less anything else). I haven't been able to pfQueryStats on anything except the PFQSTATS_GFX_GEOM_TRIS and as said, they only come in when I go to Gfx stats drawing from the GUI. So how can I get the 3 above statistics on a period of 2 seconds? (As in how do I modify Perfly to let me do this?) Thanks, Aaron Hightower ----------------------------------------------------------------------------- Aaron Hightower :: Texas Instruments aaron@dseg.ti.com Visualization and Simulation Technology Development (214)575-6759 (w) Here he comes, here comes speed racer (214)517-9245 (h) From guest Fri Oct 29 18:41:34 1993 Date: Fri, 29 Oct 93 18:42:32 -0700 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9310300142.AA09705@bessie.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: RE: pfSync() and faster dynamics Status: O Back in the early days before performer we used gl on 4D/60Gs. We were happy to get 6Hz on a Unmanned Aircraft Simulator. At that speed they system was very unstable. So what we did was devide the time from the last frame to this frame by 5 or 10 and use those as time steps. In Performer, how about running a fixed rate of 30Hz and the sim at 60hz. Draw, pfSync()/pfFrame(), every other cycle. Dave\ Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Fri Oct 29 19:07:47 1993 Message-Id: <9310300207.AA07315@surreal.asd.sgi.com> To: pratt@bessie.cs.nps.navy.mil (david pratt) Cc: info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics In-Reply-To: Your message of "Fri, 29 Oct 93 18:42:32 PDT." <9310300142.AA09705@bessie.cs.nps.navy.mil> Date: Fri, 29 Oct 93 19:07:39 -0700 From: Jim Helman Status: O Probably the best way to do this is to fork off a process which uses pfVClockSync() to wake up on every video retrace (60Hz) while running Performer at a frame rate of 30Hz. The dynamics process can communicate back to the application process through shared memory. Or if you're sure the appliation process runs safely under 16ms, you could run your current simulation loop but only call pfSync/pfDraw every other time. On the other iterations you could use pfVClockSync() to go to sleep until the next video retrace. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Oct 30 07:28:36 1993 Date: Sat, 30 Oct 93 07:29:14 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310301429.AA28593@netcom4.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics Status: O At the recent IEEE VR Symposium in San Jose this past week it appeared to me that the consensus in the VR research community was that synchronizing object action simulations to the rendering simulation rate was considered pretty much out of date. Even a fixed integer ratio between object simulation rate and rendering frame rate was not considered a great solution (though, certainly an improvement over 1-1 ratio). In Andy Van Dam's keynote talk, "VR As A Forcing Function: Software Implications of New Paradigns", he spoke in favor of every object in a VR simulation having its own independent simulation, what he referred to as fine grained concurrency. How to actually implement such concurrency is difficult to determine, and probably should be done differently for different applications. But, the point was that synchronizing application updates with rendering updates is a loser. Jim Helman's suggestion (and I believe also John Rohlfe in some earlier msgs.) of separate forked processes is one solution, though it adds a bit of run-time overhead and a lot of app. programmer overhead and debugging complexity (esp. if you're a klutz with programming multiple processes and shared memory like I am). Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Sat Oct 30 08:10:28 1993 Date: Sat, 30 Oct 93 08:10:56 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <9310301510.AA01322@netcom4.netcom.com> To: hitchner@netcom.com, info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics Status: O P.S. A point I forgot in my earlier msg. In most traditional visual scene simulations (e.g., flight and vehicle simulation or frame-at-a-time 3D graphics animation for film or video production) a difference between application sim. rate and rendering rate usually implies that the app sim runs faster than the rendering. In VR simulations, however, the ratio could go either way. Although flight simulator folks would turn their noses up at vehicle dynamics that run at a slower rate than the visual update rate, that's not necessarily the case in VR (examples: the UNC Nanomanipulator project with scanning tunneling microscope and projects at NASA Ames and Univ. of Alberta to visualize CFD super-computer simulations). In scientific visualization it's possible that the application simulation update rate might be relatively slow compared to the head tracked motion driving the viewing transformation and rendering frame update rate. And, of course the other way around (app sim rate > rendering rate) is certainly important in VR also, e.g., for collision detection. So, for VR the ratio between rendering update rate and application object simulation update rates can be: 1) not the same ratio for all objects, 2) not an integer ratio, and 3) >= 1 as well as < 1. From guest Sat Oct 30 16:42:36 1993 Message-Id: <9310302342.AA16696@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Re: pfSync() and faster dynamics In-Reply-To: Your message of "Sat, 30 Oct 93 08:10:56 PDT." <9310301510.AA01322@netcom4.netcom.com> Date: Sat, 30 Oct 93 16:42:11 -0700 From: Jim Helman Status: O Decoupling tasks to run at different rates is essential, but going from 1:1 to 1:N and N:1 (synchronous) gets you a lot more than going the next step to 1:X.X and X.X:1 (asynchronous). Given most common languages, fully asynchronous systems are much harder to debug (and harder to have confidence in) because of all the possible run-time timing variations. They are also more prone to problems of temporal aliasing as the frame udpate frequency beats with the asynchronous thread's frequency. All this can be dealt with, but why? I'm curious where Andy saw a big advantage for complete asynchronicity. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Oct 30 20:01:14 1993 From: rmann@remarque.berkeley.edu (Roderick L. Mann) Message-Id: <9310310301.AA10424@remarque.berkeley.edu> Subject: Re: pfSync() and faster dynamics To: hitchner@netcom.com (Lew Hitchner) Date: Sat, 30 Oct 1993 20:01:06 -0700 (PDT) Cc: info-performer@sgi.sgi.com (Performer Discussion) In-Reply-To: <9310301429.AA28593@netcom4.netcom.com> from "Lew Hitchner" at Oct 30, 93 07:29:14 am Content-Type: text Content-Length: 394 Status: O Hitchner writes that it is favorable to NOT sync the simulation to the rendering cycle. However, someone else mentioned that if the loop frequencies aren't integral multiples of each other, then there is a jerkiness caused by the beat frequency between the two loops. There are some solutions for this, such as extrapolating based on velocities, etc., but does anyone have any comments? Rick