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 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 To: 00A4269@msgate.emis.hac.com Subject: Re: Flight format V. 12 Cc: info-performer Status: OR 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 From: "Michael Jones" Message-Id: <9310062159.ZM10207@babar.asd.sgi.com> Date: Wed, 6 Oct 1993 21:59:04 -0700 To: aschaffe (Allan Schaffer) Subject: Re: Flight format V. 12 Status: OR 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 Date: Thu, 7 Oct 93 08:16:40 EDT 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: OR 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 guest Thu Apr 14 14:43:06 1994 From: "Stephen Joyce {75069}" Message-Id: <9404142141.AA23620@swlrgk> To: info-performer@sgi.sgi.com Status: OR If you have a very large MultiGen flight formatted data base, does Performer experience performance problems in traversing it? What would the bottlenecks be for traversing a large terrain database? Also, thank you for meeting with us yesterday and answering our questions. Thank you, Steve Joyce From guest Wed Apr 20 13:39:28 1994 Message-Id: <9404202039.AA25825@Crazypete.AI.SRI.COM> To: "Stephen Joyce {75069}" Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Thu, 14 Apr 1994 17:41:30 EDT." <9404142141.AA23620@swlrgk> Date: Wed, 20 Apr 1994 13:39:33 -0700 From: Stephen Lau Status: OR >What would the bottlenecks be for traversing a large terrain database? How large is large? For some of us gigabytes of terrain is considered "small". Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "No, no, not Orwellian, HUXLEY! SRI International | Brave New World." 333 Ravenswood Ave., Menlo Park, CA. 94025| - George Coates, "Box Conspiracy: (415) 859-2925 (415) 326-6200| An Interactive Sho" ------------------------------------------------------------------------------- From 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 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: OR 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: OR 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: OR 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 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: OR > 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 mclink.it!MC9258 Wed Feb 23 06:25:47 1994 remote from uunet To: multigen!paul Subject: Loadflt & Callback Date: Wed, 23 Feb 94 12:25:30 CET From: "Infobyte S.R.L." Message-Id: <9402231225.aa15991@ax433.mclink.it> Status: OR Hi Paul, it works. Disabling cleanTree the nodes don't disappear and can be obtained as parents of the intersected objects (they are transformed in Performer groups), i.e. pfNode *node; pfQueryHits(hits[0][0], PFQHIT_NODE, &node) printf ( "%s", pfGetNodeName ( pfGetParent(node, 0) ) ); And enabling cleanTree, the callback with CB_CLEANNODE detects that the nodes are effectively deleted by that function. Thank you. Three more questions: 1) How much performance is lost, disabling cleanTree? 2) I have noticed that, in my case, MultiGen objects are deleted, but MultiGen groups are not. Is this a general rule, so I can work with groups if I don't want an "object" deleted, or I have to verify every time with CB_CLEANNODE? 3) In the README.SS file is written that with the CB_CLEANNODE "the application can take the appropriate actions". Which are these appropriate actions? Is there a way to know which is the new address of the node? Thank you again. Massimo Cuomo - Infobyte - mc9258@mclink.it ========================================= MAILBOX Msg# 62445, 22/02/94 21:10 [4095] Da: Paul@multigenuunet.uu.net A : MC9258 Infobyte S.R.L. ----------------------------------------- Oggetto: Re: FWD>Loadflt Callback And From ammi.mclink.it!relay2.uu.net!uunet.uu.net!multigen!paul Tue Feb 22 21:08:44 1994 remote from ax433 CET 15:06:08 -0500 id AA01128; Tue, 22 Feb 1994 12:06:11 PST Message-Id: <00581.2844763571.1128@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: Infobyte S.R.L. From: Paul To: "Infobyte S.R.L." Date: Tue, 22 Feb 1994 10:13:23 PST Subject: Re: FWD>Loadflt Callback And Reply to: RE>FWD>Loadflt Callback And Pfnode Dear Massimo, My name is Paul Mlyniec. I have been maintaining the Flight format loader for some time. I would guess that your problem stems from cleanTree removing the nodes of interest. You can disable the call to cleanTree with a call to LoadFltMode() to test this hypothesis. (See README.SS in /usr/src/Performer/src/lib/libpfflt). Also note the CB_CLEANNODE callback in README.SS. Feel free to call me if you are still having problems. My phone number is (408) 261-4123. Please let me know how this turns out in any case, so that I can pass along the info to others. Thanks. Paul Mlyniec Software Systems 1884 The Alameda San Jose, CA 95126 (408) 261-4123 multigen!paul@uunet.UU.NET -------------------------------------- Date: 2/18/94 9:16 AM To: Paul From: Marcus From guest Wed Feb 23 16:21:31 1994 Message-Id: <00581.2844865374.1132@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 23 Feb 1994 16:05:18 PST Subject: Re: Loadflt & Callback Status: O Reply to: RE>Loadflt & Callback Dear Massimo, Thanks for getting back to me with the good news. I'll post the results for the general public now. As for your followup questions: 1) The cost of disabling cleanTree is not great. Traversal of additional pfNodes is the price you pay and this is not so bad. 2) It is true that MultiGen objects are generally deleted. This is because they are converted to pfGroups mostly to preserve their names in the scene graph. Certain hierarchies can cause groups to disappear as well, so I would recommend using the CB_CLEANNODE callback for protection. You also have the option of obtaining the source to modify the behavior of cleanTree. For instance, you could tag pfGroups that correspond to objects so that cleanTree leaves them alone. Incidentally, future revisions of the loader will probably allow the application to veto the deletion of pfNodes by cleanTree. 3) "Appropriate action" generally means that the application [can] no longer count on the existence of the soon-to-be-deleted node. Unfortunately, the node has already been unlinked from the scene graph when you are called with a CB_CLEANNODE. It is to late to change this for the current release of the loader, but again, you could obtain the source and reverse the order of the unlink and callback calls. Good Luck, Paul Mlyniec Software Systems -------------------------------------- Date: 2/23/94 7:55 AM To: Paul From: Infobyte S.R.L. From guest Wed Jan 26 07:47:52 1994 Date: Wed, 26 Jan 94 17:46:49 +0200 From: rany@bvr.co.il (Ran Yakir) Message-Id: <9401261546.AA01311@amcor.bvr.co.il> To: info-performer@sgi.sgi.com Subject: 1.0/1.1 bug in LoadFlt Status: OR Actualy, not in LoadFlt buf in one of its static functions named - getTexture (and resides in pfflt/geom.c). getTexture attepts to read the attributes file (.attr) using the line read(ifd, (char*)&texAttr, stbuf.st_size); where : 1. stbuf is the buffer returned by stat(), and stbuf.st_size containts the attributes file size. 2. texAttr is a structure that will contain the full contents of the file. If, for some reason, the .attr file is larger then its minimal size, the read command will run over texAttr right into the rest of the stack, and mess things up. You won't notice it at first, but then some malloc() will core you dump (or dump your core). What should be done (and is easy to do on-site) is replacing the line with : read(ifd, (char*)&texAttr, sizeof texAttr); Good luck Ran Yakir __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Wed Jan 26 08:13:38 1994 From: "Michael Jones" Message-Id: <9401260812.ZM15156@babar.asd.sgi.com> Date: Wed, 26 Jan 1994 08:12:22 -0800 In-Reply-To: rany@bvr.co.il (Ran Yakir) "1.0/1.1 bug in LoadFlt" (Jan 26, 5:46pm) References: <9401261546.AA01311@amcor.bvr.co.il> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: rany@bvr.co.il (Ran Yakir), info-performer@sgi.sgi.com Subject: Re: 1.0/1.1 bug in LoadFlt Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Jan 26, 5:46pm, Ran Yakir wrote: > Subject: 1.0/1.1 bug in LoadFlt : :Actualy, not in LoadFlt buf in one of its static functions named - :getTexture (and resides in pfflt/geom.c). :getTexture attepts to read the attributes file (.attr) using the line : : read(ifd, (char*)&texAttr, stbuf.st_size); : :where : :1. stbuf is the buffer returned by stat(), and stbuf.st_size containts : the attributes file size. :2. texAttr is a structure that will contain the full contents of the file. : :If, for some reason, the .attr file is larger then its minimal size, :the read command will run over texAttr right into the rest of the stack, and :mess things up. You won't notice it at first, but then some malloc() will :core you dump (or dump your core). : :What should be done (and is easy to do on-site) is replacing the line :with : : : read(ifd, (char*)&texAttr, sizeof texAttr); Good observation. This was indeed a bug in LoadFlt() and the fix given by Ran Yakir is the right one. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From rany Wed Jan 26 17:46:46 1994 To: info-performer@sgi.com Subject: 1.0/1.1 bug in LoadFlt Status: OR Actualy, not in LoadFlt buf in one of its static functions named - getTexture (and resides in pfflt/geom.c). getTexture attepts to read the attributes file (.attr) using the line read(ifd, (char*)&texAttr, stbuf.st_size); where : 1. stbuf is the buffer returned by stat(), and stbuf.st_size containts the attributes file size. 2. texAttr is a structure that will contain the full contents of the file. If, for some reason, the .attr file is larger then its minimal size, the read command will run over texAttr right into the rest of the stack, and mess things up. You won't notice it at first, but then some malloc() will core you dump (or dump your core). What should be done (and is easy to do on-site) is replacing the line with : read(ifd, (char*)&texAttr, sizeof texAttr); Good luck Ran Yakir __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Fri Feb 18 06:38:30 1994 To: info-performer@sgi.sgi.com Subject: Loadflt Callback And Pfnodes Date: Fri, 18 Feb 94 15:37:56 CET From: "Infobyte S.R.L." Message-Id: <9402181537.aa19654@ax433.mclink.it> Status: OR Hi all, I am "playing" with Performer1.2a81.irix5 beta and I have experienced a strange behavior: I am using the callback functions with LoadFlt routine. At loading time (in the callback function), I print the addresses of the Performer nodes and their names that are (by default) the same of MultiGen ones. When, after in the application, I print the same addresses (from the pfHit structure after a collision I can obtain the Geodes), they are different for the objects. I am sure that the nodes are the right ones because I know the polygons of the objects and because if I print the adresses and names of the Parents of the nodes, they are the right ones. Further when I try to find the addresses of the objects by name with pfFind, it doesn't work for them (NULL return values), but it works fine for the parent groups or lods. It seems that the objects' addresses are in some way changed and their names deleted, while groups' and lods' are not. Is it possible or is there anything else I have to do (or not to do!). Thank you in advance for any help. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Tue Mar 22 19:47:31 1994 Message-Id: <9403230347.AA05724@surreal.asd.sgi.com> To: "Infobyte S.R.L." Cc: info-performer@sgi.sgi.com Subject: Re: Loadflt Callback And Pfnodes In-Reply-To: Your message of "Fri, 18 Feb 94 15:37:56 +0700." <9402181537.aa19654@ax433.mclink.it> Date: Tue, 22 Mar 94 19:47:16 -0800 From: Jim Helman Status: OR As a performance optimization the loader "flattens" (removes static xform by applying them to geoemtry) and "cleans" (removes unnecessary nodes) the scene graph. Since flattening has to duplicate instanced subgraphs, you may find some new nodes in your scene graph. Since clean removes nodes, some may be missing as well. See LoadFltMode to change this behavior, or use callbacks or pfFind to reconstruct the information you need on the optimized scene graph. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 To: info-performer@sgi.sgi.com Subject: Loadflt Callback And Pfnodes Date: Fri, 18 Feb 94 15:37:56 CET From: "Infobyte S.R.L." Message-Id: <9402181537.aa19654@ax433.mclink.it> Hi all, I am "playing" with Performer1.2a81.irix5 beta and I have experienced a strange behavior: I am using the callback functions with LoadFlt routine. At loading time (in the callback function), I print the addresses of the Performer nodes and their names that are (by default) the same of MultiGen ones. When, after in the application, I print the same addresses (from the pfHit structure after a collision I can obtain the Geodes), they are different for the objects. I am sure that the nodes are the right ones because I know the polygons of the objects and because if I print the adresses and names of the Parents of the nodes, they are the right ones. Further when I try to find the addresses of the objects by name with pfFind, it doesn't work for them (NULL return values), but it works fine for the parent groups or lods. It seems that the objects' addresses are in some way changed and their names deleted, while groups' and lods' are not. Is it possible or is there anything else I have to do (or not to do!). Thank you in advance for any help. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Fri Jul 1 09:41:36 1994 From: "Annie SIMEAU" Message-Id: <9407011710.ZM4547@alice.paris.sgi.com> Date: Fri, 1 Jul 1994 17:10:53 -0600 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com, asim@alice.paris.sgi.com Subject: Performer 1.2 Loadflt Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi everybody, I am looking for the limitation of the Loadflt function. When loading more than 17 files .flt the program core dump without any message the stack is : MyFunction, LoadFlt, convTree, convTree, convTree, convTree, convTree, convTree, makeGeometry, makeGeode, pfNewGeode, pfBuffer When all the data base is in one file everything is OK. I can have a test program, Any help is welcome. -- /| o Annie Simeau, Country ID: IFR-340 /_| _ _ _ asim@paris.sgi.com / | / ) / ) / /_) . Phone Number : 33 1 34 88 80 88 / |_/ /_/ /_/_(_ . Fax Number : 33 1 34 88 80 76 From guest Thu Feb 17 14:44:16 1994 Date: Thu, 17 Feb 94 14:43:49 PST From: penafiel@guild.rdd.lmsc.lockheed.com (Hugo Penafiel) Message-Id: <9402172243.AA12773@guild.rdd.lmsc.lockheed.com> To: mwilliam@ldsa.com, info-performer@sgi.sgi.com Subject: DTED loader Status: OR The only two companies I know that have a DTED to MultiGen Flight Format converter are Software Systems Inc. in San Jose, CA and Coryphaeus Software in Los Gatos, CA. I have an address and phone number for Coryphaeus: 985 University Ave., Suite 31 Los Gatos, CA 95030 Phone: (408) 395-4537 Fax: (408) 395-6351 Good luck! Hugo Penafiel Phone: (415) 424-2913 e-mail: penafiel@guild.rdd.lmsc.lockheed.com Research & Development Division Lockheed Missiles & Space Co. Palo Alto, CA