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: OR 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 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: OR 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 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: OR 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 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: OR ----- > >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: 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. 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 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 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 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: OR 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! 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: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: OR 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 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! >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 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: OR 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? 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: OR > > 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 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 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: OR 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" 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 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 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 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 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 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 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: OR 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 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: OR 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 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 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 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 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 Nov 3 08:42:25 1993 Date: Wed, 3 Nov 93 16:42:54 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9311031642.AA00802@death.reading.sgi.com> To: info-performer Subject: ps what I really meant was runon 1 perfly -m0 toon.flt - Angus "Imagine your witty quote here" From guest Wed Nov 3 13:24:39 1993 Message-Id: <199311032129.AA04125@artemis.cmr.no> To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: pfInitGLXGfx(...) ? Date: Wed, 03 Nov 93 22:29:26 +0100 From: Nils Thune Hi, I'm using Performer 1.2 inside a Motif program and are creating the following GLwindow for rendering. The following code will create a GLwindow and set it in correct rendering mode (I hope): /***********/ GLXconfig glxConfig [] = {{ GLX_NORMAL, GLX_DOUBLE, TRUE }, { GLX_NORMAL, GLX_RGB, TRUE }, { GLX_NORMAL, GLX_STENSIZE, 1 }, { GLX_NORMAL, GLX_ZSIZE, GLX_NOCONFIG }, { 0, 0, 0 } }; renderAreaWidget = XtVaCreateManagedWidget("glxWidget", glxMDrawWidgetClass, parent, GlxNglxConfig, glxConfig, NULL); subpixel(TRUE); mmode(MVIEWING); zbuffer(TRUE); /***********/ My question is this: What happens inside pfInitGLXGfx(...)? Currently I'm not making a call to it. For some reason this function is not discussed in the manual. Should I set more GL modes to make Performer happy without calling pfInitGLXGfx(...)? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 05 574040 Phone: 05 574355 (Direct) Fax : 05 574041 -------------------------------- From guest Thu Nov 4 14:55:57 1993 Message-Id: <9311042255.AA03381@nova> Date: 4 Nov 1993 15:55:45 U From: "Chris Pratico" Subject: Scaling question To: info-performer@sgi.sgi.com Scaling question My question might not be so much a performer question as it is a graphics problem in general. But I am sure that performer must have some easy routines for solving the problem. My question: I have several objects in a scene, each with a different location/orientation in 3D space. I wish to zoom up or down each of the objects so that they all appear to be roughly the same size no matter how far they are from the viewers eyepoint. Has anyone done this already, and can you point me in the right direction on how to solve this problem? I figure that I probably want to use an axially aligned bounding box for each object and then transform the box coordinates from world to screen (or something like that), and then scale. Thanks in advance for any help, and for taking the time to read. Chris Pratico chris_pratico@maca.sarnoff.com From guest Thu Nov 4 15:50:28 1993 From: "Michael Jones" Message-Id: <9311041550.ZM2017@babar.asd.sgi.com> Date: Thu, 4 Nov 1993 15:50:20 -0800 In-Reply-To: "Chris Pratico" "Scaling question" (Nov 4, 3:55pm) References: <9311042255.AA03381@nova> X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: "Chris Pratico" , info-performer@sgi.sgi.com Subject: Re: Scaling question Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Nov 4, 3:55pm, Chris Pratico wrote: :I have several objects in a scene, each with a different location/orientation :in 3D space. I wish to zoom up or down each of the objects so that they all :appear to be roughly the same size no matter how far they are from the viewers :eyepoint. It's solved by "similar triangles". Given a distance to an object and an angular field-of-view, you can compute the angle the object subtends by looking at it's radius. Using the "corresponding parts of similar triangles are similar" cranial imprint, you can deduce the necessary scale factors. Just think of a top view: +-------------+--------------+ | | | The vertical lines represent radii, while the pluses are (left to right) the eye, a near object, and a far object. -- 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 Nov 4 17:04:37 1993 Date: Thu, 4 Nov 93 17:04:04 PST From: tnguyen@ucssun1.sdsu.edu (Tung Nguyen) Message-Id: <9311050104.AA27532@ucssun1.sdsu.edu> To: info-performer unsubscribe From guest Fri Nov 5 12:56:38 1993 Date: Fri, 5 Nov 93 15:57:34 -0500 From: marrou@indy.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9311052057.AA12852@indy.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: pfEnable Would there be a preference in using the following: { // disable fog pfDisable(PFEN_FOG); pfOverride(PFSTATE_ENFOG | PFSTATE_FOG, PF_ON); // enable fog pfOverride(PFSTATE_ENFOG | PFSTATE_FOG, PF_OFF); pfEnable(PFEN_FOG); } over: { // disable fog pfESkyFog(esky, PFES_GENERAL, NULL); // enable fog pfESkyFog(esky, PFES_GENERAL, fog); } Or is it preferable to use both and why? Thanks in advance for any help. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From guest Mon Nov 8 12:41:57 1993 Date: Mon, 8 Nov 93 15:42:09 -0500 From: russo@kidd.ait.nrl.navy.mil (Kevin Russo) Message-Id: <9311082042.AA24564@kidd.ait.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: Perf 1.1 on 5.1.1 I just loaded Performer 1.1 on a new Indigo2 XL and now perfly (and all the demos) fail miserably: Performer Warning (6):unable to determine graphics type -1. Default: VENICE . . . Performer Info (9):FP division by zero Performer Info (9):FP infinity minus infinity ERROR #22 texdef1d: ERR_BADINDEX What's going on? Thanks. Kevin Russo russo@ait.nrl.navy.mil SFA / Naval Research Lab Washington, DC From guest Mon Nov 8 14:19:16 1993 Message-Id: <9311082219.AA17731@surreal.asd.sgi.com> To: russo@kidd.ait.nrl.navy.mil (Kevin Russo) Cc: info-performer@sgi.sgi.com Subject: Re: Perf 1.1 on 5.1.1 In-Reply-To: Your message of "Mon, 08 Nov 93 15:42:09 EST." <9311082042.AA24564@kidd.ait.nrl.navy.mil> Date: Mon, 08 Nov 93 14:19:04 -0800 From: Jim Helman There are some FP bugs in the GL, usually not fatal if ignored. If you run with a lower pfNotifyLevel, Performer won't enable floating point exceptions (used nfor debugging purposes), and you should run OK, i.e. try using the "-n 2" or "-n 3" options to Perfly. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun Nov 14 21:15:27 1993 Date: Mon, 8 Nov 93 17:14:38 -0800 From: troy@sgitpei.taiwan.sgi.com (Troy Huang) Message-Id: <9311090114.AA03339@sgitpei.taiwan.sgi.com> To: info-performer@sgi.sgi.com Dear sir, pls unsubscrible me from your mailing list. Thanks Troy From guest Tue Nov 9 10:37:20 1993 Message-Id: <9311091833.AA02977@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA Date: Tue, 9 Nov 1993 13:33:38 -0500 To: gallir@anim.uib.es (Ricardo Galli), info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: Re: getting transformation matrix >I'm going to ask many thing. Let me present an example. > >We (with a student) have a scene composed by the root, >four DCS and one GeoDesc belonging to each DCS (I mean, >children of the DCSs). > >We are modifying the DCS in order to animate the objects. >Because we have to do a special collision checking (between >solids) of one object against the other ones, we need >to get as fast as possible the world coordinate of each >object. The only way we know is getting the DCS matrices >and multiplying each object vertex by the correponding >matrix. This is not very clever(is very slow to walk thru >the structure to get each matrix (matrices)). > >Is there another way for doing this? >Is it a good idea (and possible) to get the Model Matrix >using GL? > The following is not a Performer specific answer, but has to do with collision checking in general. I do not know about Performer specific object collision detection (in fact, I don't even know if Performer does object collision detection!) You must have each object in the same coordinate system to do collision checking. However, you don't have to actually test each object to determine whether or not that object is intersecting another object. There are many methods for detecting collisions based on bounding boxes and spheres, and simulation techniques that use information already calculated to determine whether or not two objects intersect. When two objects are very close together, you _have_ to do a vertex, edge, face check to determine whether or not they intersect and that check must be done with both objects in the same coordinate system. The trick is determining when they are close together. Bounding spheres: Choose a point (not necessarily a vertex of the model) that is approximately in the center of the object. Now choose a radius that is large enough for the sphere it describes to completely enclose the object (can be calculated using the vertexes of polyhedral objects). To check two objects, simply check the distance, d, between the two center points (Pa and Pb). If d is greater than the sum of the two radii (Ra and Rb) then it is impossible for the two objects to be intersecting. Only do a detailed intersection check when (Pa - Pb) < (Ra + Rb). The nicest thing about using bounding spheres for collision checking is that the transformation of a sphere from one coordinate system to another simply requires a translation of a single point. Much much cheaper than transforming the whole object for every check. Bounding boxes: Same idea, only use the x, y, and z mins and maxes to construct a box. If Axmin > Bxmax OR Axmax < Bxmin OR Aymin > Bymax OR Aymax < Bymin OR Azmin > Bzmax OR Azmax < Bzmin you know that the boxes cannot intersect and the objects can not be occupying the same space. Boxes are slightly more complicated because you have to be conservative when you transform them between coordinate systems. The box may grow with rotations, but it should not be permitted to shrink. The fact that the box changes at all is because it is constructed aligned with the axes. Rotations misalign the box and it must be realigned by creating a new box that completely encloses the transformed box. Unfortunately, I can't find any good discussions of collision detection so if anyone else has some reading suggestions, that might help here. The above is a very terse description of just a few possible options. (The Graphics Gems series - GG, GG II, and GG III - do discuss calculating bounding spheres and intersecting rays with spheres and axis-aligned boxes for ray-tracing applications.) One other thing to remember: When comparing two objects, it is not necessary to transform both objects into some "world" coordinate system. Often, it is only necessary to transform one of the objects into the coordinate system of the other object to do the test. If each object has 1000 vertices, you will save 1000 3x1 X 4x4 matrix calculations at the expense of one 4x4 matrix inversion and one 4x4 X 4x4 matrix multiply. > >IS IT A GOOD IDEA TO DO COLLISION CHECKING USING PERFORMER? >The collision checking is done for each object moving >in the scene against the other object belonging to the >same scene. > > >--Ricardo Galli >Universitat de les Illes Balears >Palma de Mallorca - SPAIN >Tel. +34 71 17 3201 >FAX. +34 71 17 3003 >e-mail. gallir@anim.uib.es >+--------------------------------------------------------------------+ >|The nice thing about standards is that there are so many of them to | >|choose from. | >| -- Andrew S. Tanenbaum | >+--------------------------------------------------------------------+ ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From guest Tue Nov 9 09:42:01 1993 Date: Tue, 9 Nov 93 18:36:11 GMT From: gallir@anim.uib.es (Ricardo Galli) Message-Id: <9311091836.AA01892@anim.uib.es> To: info-performer@sgi.sgi.com Subject: getting transformation matrix I'm going to ask many thing. Let me present an example. We (with a student) have a scene composed by the root, four DCS and one GeoDesc belonging to each DCS (I mean, children of the DCSs). We are modifying the DCS in order to animate the objects. Because we have to do a special collision checking (between solids) of one object against the other ones, we need to get as fast as possible the world coordinate of each object. The only way we know is getting the DCS matrices and multiplying each object vertex by the correponding matrix. This is not very clever(is very slow to walk thru the structure to get each matrix (matrices)). Is there another way for doing this? Is it a good idea (and possible) to get the Model Matrix using GL? IS IT A GOOD IDEA TO DO COLLISION CHECKING USING PERFORMER? The collision checking is done for each object moving in the scene against the other object belonging to the same scene. --Ricardo Galli Universitat de les Illes Balears Palma de Mallorca - SPAIN Tel. +34 71 17 3201 FAX. +34 71 17 3003 e-mail. gallir@anim.uib.es +--------------------------------------------------------------------+ |The nice thing about standards is that there are so many of them to | |choose from. | | -- Andrew S. Tanenbaum | +--------------------------------------------------------------------+ From guest Tue Nov 9 09:52:52 1993 Date: Tue, 9 Nov 93 18:49:38 GMT From: gallir@anim.uib.es (Ricardo Galli) Message-Id: <9311091849.AA01975@anim.uib.es> To: info-performer@sgi.sgi.com Subject: Bounding boxes Why when we try to get the bounding box from a DCS (making an OR with the aproppiate value to overpass a bug in performer) the b. box is much larger than the real one? --Ricardo Galli Universitat de les Illes Balears Palma de Mallorca - SPAIN Tel. +34 71 17 3201 FAX. +34 71 17 3003 e-mail. gallir@anim.uib.es +--------------------------------------------------------------------+ |The nice thing about standards is that there are so many of them to | |choose from. | | -- Andrew S. Tanenbaum | +--------------------------------------------------------------------+ From guest Tue Nov 9 12:52:28 1993 Message-Id: <9311092052.AA04471@surreal.asd.sgi.com> To: "Lee C. Moore" Cc: info-performer@sgi.sgi.com Subject: Re: which is the most recent version? In-Reply-To: Your message of "Tue, 09 Nov 93 11:15:12 PST." <9311091915.AA29578@gargar.wrc.xerox.com> Date: Tue, 09 Nov 93 12:52:11 -0800 From: Jim Helman The current releases are: Performer 1.0 for IRIX 4.0.5 Performer 1.1 for IRIX 5.X rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 9 12:53:54 1993 Date: Tue, 9 Nov 93 12:53:45 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9311092053.AA08073@tubes.asd.sgi.com> To: gallir@anim.uib.es (Ricardo Galli), info-performer@sgi.sgi.com Subject: Re: Bounding boxes >Why when we try to get the bounding box from a DCS (making >an OR with the aproppiate value to overpass a bug in >performer) the b. box is much larger than the real one? We only maintain bounding spheres internally for reduced storage requirements and culling/intersection speed. pfGetNodeBBox returns the bounding box that surrounds the bounding sphere that surrounds the real bounding box. I think however that we need to provide some easy way to get the true bounding box. From guest Tue Nov 9 12:57:41 1993 Message-Id: <9311092057.AA04490@surreal.asd.sgi.com> To: gallir@anim.uib.es (Ricardo Galli) Cc: info-performer@sgi.sgi.com Subject: Re: Bounding boxes In-Reply-To: Your message of "Tue, 09 Nov 93 18:49:38 GMT." <9311091849.AA01975@anim.uib.es> Date: Tue, 09 Nov 93 12:57:29 -0800 From: Jim Helman Internally, two types of bounding geometre are currently in use. libpf uses bounding spheres around pfNodes. libpr uses axial bounding boxes around pfGeoSets. The get/set bbox API anticipates the potential of other bounding geometry types, but for now, pfGetNodeBBox() will return a box around the current bounding sphere, hence it's larger size. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 9 13:11:12 1993 Message-Id: <9311092111.AA04545@surreal.asd.sgi.com> To: gallir@anim.uib.es (Ricardo Galli) Cc: info-performer@sgi.sgi.com Subject: Re: getting transformation matrix In-Reply-To: Your message of "Tue, 09 Nov 93 18:36:11 GMT." <9311091836.AA01892@anim.uib.es> Date: Tue, 09 Nov 93 13:11:04 -0800 From: Jim Helman >Is there another way for doing this? Little things. You can be more clever and cache the concatenation of unchanging parts of the xform hierarchy if possible; keep track of what portions of the 4x4 xform are actually in use for quicker mults, etc. But the bottom line is that someone has to compute it. Getting the concatenated xform from Performer or GL would be difficult because in a multiprocessed environment Performer (in the cull) and GL (in the draw) are potentially a frame or two behind the application process. Also, it only works for visible geometry. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 9 14:15:17 1993 Date: Tue, 9 Nov 93 14:14:21 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9311092214.AA08597@tubes.asd.sgi.com> To: "Chris Pratico" , info-performer@sgi.sgi.com Subject: Re: another bounding box questi Status: OR >I want to get the radius of the bounding sphere around an object, currently I >do the following: > >pfBox bbox, *bboxes; >pfSphere bsphere; > >pfGetNodeBBox(object, &bbox, NULL); >bboxes = &bbox; >pfSphereAroundBoxes(&bsphere, &bboxes, 1); > >r1 = bsphere.radius; > >Since the underlying geometery of the bounding box is actually a sphere, is >there a more direct way of doing this? Do I really need to get the bounding >box of the object and then extend a sphere around the bbox to get its radius? pfGetNodeBSphere(object, &bsphere) will be in the 1.2 release. From guest Tue Nov 9 14:58:30 1993 From: buckley@vsl.ist.ucf.edu (Bob Buckley) Message-Id: <9311092258.AA04506@vsl.ist.ucf.edu> Subject: FOV Acquisition To: info-performer@sgi.sgi.com Date: Tue, 9 Nov 93 17:58:18 EST X-Mailer: ELM [version 2.3 PL0] While running Performer (or anything on top of GL) I need to acquire the FOV in both x and y. GL does not provide a FOV query, however, by directly reading the projection matrix (perspective) I can get the FOV's. Is there any problem to getting this info while running Performer? =============================================================================== 'Bwana' Bob Buckley Computer Science Masters Student The University of Central Florida email: buckley@vsl.ist.ucf.edu =============================================================================== Graduate Research Assistantship | Research Fellowship The Institute for Simulation & Training | The Naval Training Systems Center Visual Systems Lab | Visual Technology Research Simulator IST/VSL (407) 658-5073/74 | NTSC/VTRS (407) 249-3127 =============================================================================== From guest Tue Nov 9 13:54:59 1993 Message-Id: <9311092154.AA17003@nova> Date: 9 Nov 1993 16:15:54 U From: "Chris Pratico" Subject: another bounding box questi To: info-performer@sgi.sgi.com another bounding box question While we seem to be on the subject of bounding boxes - I have a related question. I want to get the radius of the bounding sphere around an object, currently I do the following: pfBox bbox, *bboxes; pfSphere bsphere; pfGetNodeBBox(object, &bbox, NULL); bboxes = &bbox; pfSphereAroundBoxes(&bsphere, &bboxes, 1); r1 = bsphere.radius; Since the underlying geometery of the bounding box is actually a sphere, is there a more direct way of doing this? Do I really need to get the bounding box of the object and then extend a sphere around the bbox to get its radius? Thanks Chris Pratico chris_pratico@maca.sarnoff.com From guest Thu Nov 11 17:58:06 1993 Date: Thu, 11 Nov 93 14:39:05 CST From: reedwhit@skips.dseg.ti.com (Reed Whittington) Message-Id: <9311112039.AA29810@skips.dseg.ti.com> To: info-performer@sgi.sgi.com Subject: When to change scene hooks Hello Performer Group, My Performer application is for a tank simulation: Im trying to implement gun stabalization. My tank (the ownship) is modeled as chained DCS's : pfGroup* TankRoot = pfNewGroup(); pfAddChild(ownship->dcs_hull, LoadFile(hull_file, NULL )); pfAddChild(TankRoot, ownship->dcs_hull); pfAddChild(ownship->dcs_tur, LoadFile(tur_file, NULL )); pfAddChild(ownship->dcs_hull, ownship->dcs_tur); pfAddChild(ownship->dcs_gun, LoadFile(gun_file, NULL )); pfAddChild(ownship->dcs_tur, ownship->dcs_gun); pfAddChild(scene, TankRoot); My sim loop looks something like this (adapted from perfly): SimLoop: { updateView - update channel views pfFrame (draw frame N) updateSim ( for frame N+1 ) - get sim inputs - calculate new values - adjust ownship DCS's (these are direct hooks into the scene) pfDCSRot( ownship->dcs_tur, ownship->tur_heading, 0.0, 0.0 ); do gun stabalization pfDCSRot( ownship->dcs_gun, 0.0, ownship->gun_pitch, 0.0 ); } My question is: Will adjusting the ownship DCS's after pfFrame cause a DCS to shift during a Cull/Draw? If so what can I do to get around this. I don't want to have to adjust the DCS's in updateView because of turret stabalization calculations that need access to intermediate transformation matrix values after a DCSRot for the turret. Thanks in advance. --Reed ******************************** Reed Whittington Texas Instruments Visual Simulation Technology Development MS 8518 6620 Chase Oaks Blvd. Plano, Texas 75086 (214) 575-6761 off (214) 575-6771 fax reedwhit@dseg.ti.com ******************************** From guest Thu Nov 11 21:44:59 1993 Message-Id: <9311120544.AA00442@surreal.asd.sgi.com> To: reedwhit@skips.dseg.ti.com (Reed Whittington) Cc: info-performer@sgi.sgi.com Subject: Re: When to change scene hooks In-Reply-To: Your message of "Thu, 11 Nov 93 14:39:05 CST." <9311112039.AA29810@skips.dseg.ti.com> Date: Thu, 11 Nov 93 21:44:45 -0800 From: Jim Helman > > My question is: > > Will adjusting the ownship DCS's after pfFrame cause a DCS to shift > during a Cull/Draw? If so what can I do to get around this. I > don't want to have to adjust the DCS's in updateView because of > turret stabalization calculations that need access to intermediate > transformation matrix values after a DCSRot for the turret. The short answer is no. All the state related to pfNodes in the scene graph, including pfDCSes, propagates frame accurately, so the cull won't see changes made in the app for frame N+1 until it is culling frame N+1. pfFrame defines the end of an frame in the application and anything between two pfFrame()s is part of the same frame. > SimLoop: > { > updateView > - update channel views > > pfFrame (draw frame N) > > updateSim ( for frame N+1 ) > - get sim inputs > - calculate new values > - adjust ownship DCS's (these are direct hooks into the scene) > pfDCSRot( ownship->dcs_tur, ownship->tur_heading, 0.0, 0.0 ); > do gun stabalization > pfDCSRot( ownship->dcs_gun, 0.0, ownship->gun_pitch, 0.0 ); > } But I am curious about your distinction between updateSim and updateView. From the loop above, without pfSync(), moving the DCS update wouldn't change any timing w.r.t. other processes in the pipeline because there is no timing separation between updateSim and updateView, e.g. in any PFAPP_CULL mode both overlap the cull: (FR=pfFrame) | | | | Sn Vn FR | Sn+1 Vn+1 FR | |-------==== |-------===== | | | | | | CULL n | | |------------------- | But if you're using pfSync() after the Sim but before the View, then there is a difference. (SY=pfSync) | | | | Sn SY | Vn FR Sn+1 SY | Vn+1 |------- |==== ------- |==== | | | | | CULL n | | | --------------- | ^ | Note later start of cull rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Nov 12 08:38:31 1993 From: Renee Strong Message-Id: <9311121638.AA00284@pat.mdc.com> Subject: pfInit error To: info-performer@sgi.sgi.com Date: Fri, 12 Nov 93 10:38:23 CST X-Mailer: ELM [version 2.3 PL11] Status: OR I just got this error message today when trying to run performer on our VGX: Performer Fatal (22):pfInit: usinit failed for /usr/tmp/pfSemaFile.a01418 Can anybody tell me what's going on here? The same executable is running fine on several different PIs. I really want this thing to run on the VGX so I can see if I've figured out how to do texture mapping correctly Thanks, Renee Strong renee@pat.mdc.com From guest Fri Nov 12 12:17:28 1993 Date: Fri, 12 Nov 93 12:17:10 PST From: stiles@aic.lockheed.com (Randy Stiles) Message-Id: <9311122017.AA20153@aic.lockheed.com> To: chris_pratico@maca.sarnoff.com Cc: info-performer@sgi.sgi.com In-Reply-To: "Chris Pratico"'s message of 12 Nov 1993 14:08:32 U <9311121951.AA26756@nova> Subject: Cull problem Date: 12 Nov 1993 14:08:32 U From: "Chris Pratico" Cull problem I have created a grid as a pfGeoSet of unit size 1 during the initialization period of my application process. Later, within my simulation loop, I scale the DCS parent of this GeoSet to various sizes. The problem is that the grid appears to be culled to the original dimensions of the GeoSet (i.e.: as if the grid were still a unit size of 1). Although when it is drawn to the screen it appears to be scaled to the proper dimensions. As a result the grid disappears from the screen as if it were always a grid of dimension size 1. Has anyone seen this problem? Is there someway I can work around this (ie. have an object never cull)? I have tried everything and can't seem to figure out why this is happening. I believe you want to rescale the bounding box, since it culls using this. The box stays the same size unless you tell it to be dynamic or you rescale it yourself each time. man pfNodeBBox - use arg PFN_BMODE_DYNAMIC -Randy # Randy Stiles (stiles@aic.lockheed.com) # Office: 415.354.5256, Fax: 415.354.5235 # Lockheed AI Center, Orgn 9620 Bldg 254F # 3251 Hanover St., Palo Alto, CA 94304 From guest Fri Nov 12 12:58:19 1993 Message-Id: <9311122058.AA08670@surreal.asd.sgi.com> To: Renee Strong Cc: info-performer@sgi.sgi.com Subject: Re: pfInit error In-Reply-To: Your message of "Fri, 12 Nov 93 10:38:23 CST." <9311121638.AA00284@pat.mdc.com> Date: Fri, 12 Nov 93 12:58:06 -0800 From: Jim Helman > I just got this error message today when trying to run performer on our VGX: > > Performer Fatal (22):pfInit: usinit failed for /usr/tmp/pfSemaFile.a01418 > > Can anybody tell me what's going on here? The same executable is running > fine on several different PIs. I really want this thing to run on the VGX > so I can see if I've figured out how to do texture mapping correctly > The 22 (EINVAL) is the last value that errno was set to. It's probably from the usinit. If so, it indicates a library/OS version problem with libmpc.a. Try relinking on the VGX. From 'man usinit' [EINVAL] This error is returned if the version the currently attaching process was compiled with is incompatible with the version compiled into the creator of the arena. If you still have problems, also make sure that /usr/tmp is writable, has free space sand is free of any leftover arena or data pool files. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Nov 12 13:19:31 1993 Message-Id: <9311122119.AA08730@surreal.asd.sgi.com> To: stiles@aic.lockheed.com (Randy Stiles) Cc: chris_pratico@maca.sarnoff.com, info-performer@sgi.sgi.com Subject: Re: Cull problem In-Reply-To: Your message of "Fri, 12 Nov 93 12:17:10 PST." <9311122017.AA20153@aic.lockheed.com> Date: Fri, 12 Nov 93 13:19:18 -0800 From: Jim Helman Date: Fri, 12 Nov 93 12:17:10 PST From: stiles@aic.lockheed.com (Randy Stiles) Subject: Cull problem Date: 12 Nov 1993 14:08:32 U From: "Chris Pratico" Cull problem [Description of problem culling under DCSes of scale > 1] I believe you want to rescale the bounding box, since it culls using this. The box stays the same size unless you tell it to be dynamic or you rescale it yourself each time. man pfNodeBBox - use arg PFN_BMODE_DYNAMIC No. The bounding volume of the DCS is automatically recomputed. The problem culling under scaled DCSes with scales > 1 is a bug in 1.0 that was fixed in 1.1. There is no easy workaround. In general, you should never have to set bounding volumes manually unless you are doing actual vertex warping or are doing massive scene graph reorganizations and wish to avoid bounding volume recomputation time by making bounding volumes static. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Nov 12 11:51:43 1993 Message-Id: <9311121951.AA26756@nova> Date: 12 Nov 1993 14:08:32 U From: "Chris Pratico" Subject: Cull problem To: info-performer@sgi.sgi.com Cull problem I have created a grid as a pfGeoSet of unit size 1 during the initialization period of my application process. Later, within my simulation loop, I scale the DCS parent of this GeoSet to various sizes. The problem is that the grid appears to be culled to the original dimensions of the GeoSet (i.e.: as if the grid were still a unit size of 1). Although when it is drawn to the screen it appears to be scaled to the proper dimensions. As a result the grid disappears from the screen as if it were always a grid of dimension size 1. Has anyone seen this problem? Is there someway I can work around this (ie. have an object never cull)? I have tried everything and can't seem to figure out why this is happening. Thanks Chris Pratico chris_pratico@maca.sarnoff.com From guest Fri Nov 12 13:54:34 1993 Message-Id: <9311122154.AA27205@nova> Date: 12 Nov 1993 16:02:21 U From: "Chris Pratico" Subject: Re: Cull problem To: "Randy Stiles" Cc: info-performer@sgi.sgi.com Return-Receipt-To: "Chris Pratico" Reply to: RE>Cull problem Thanks for your reply, but I checked and my BBox is dynamic. In fact when I check the dimensions of the bounding box of the grid the values seem to grow and shrink appropriately with the scale. So the BBox seems to be working properly#004#. When I check the numbers - they all look correct - but when I draw it to the screen, the culling is all wrong. I am confused. Chris Pratico chris_pratico@maca.sarnoff.com From guest Sat Nov 13 01:36:05 1993 Message-Id: <9311130936.AA10952@surreal.asd.sgi.com> To: buckley@vsl.ist.ucf.edu (Bob Buckley) Cc: info-performer Subject: Re: FOV Acquisition In-Reply-To: Your message of "Tue, 09 Nov 93 17:58:18 EST." <9311092258.AA04506@vsl.ist.ucf.edu> Date: Sat, 13 Nov 93 01:36:02 -0800 From: Jim Helman > While running Performer (or anything on top of GL) I need to > acquire the FOV in both x and y. GL does not provide a FOV query, > however, by directly reading the projection matrix (perspective) I > can get the FOV's. Is there any problem to getting this info while > running Performer? In the *draw* process callback, you can use something like: prev=getmmode(); mmode(MPROJECTION); getmatrix(mine); mmode(prev); to get the projection matrix. You can then use the matrix definitions in the GL Programming guide to back out the FOV, but the form of "mine" that Performer uses is not documented, it could have other transformations built in, and it could vary between releases. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Nov 13 07:00:21 1993 From: kotto@caeg.rmi.de Date: Sat, 13 Nov 93 15:59:21 +0100 Message-Id: <9311131459.AA01253@caeg> To: info-performer@sgi.sgi.com Subject: callback functions Hi Performer Group, Working with a Performer 1.2 beta version we noticed that for example pfGetNodeBBox or pfSetSwitchVal for a pfDCS or pfGroup is not allowed in a callback procedure anymore (neither Cull nor Draw, it was allowed in 1.1). We get the message: Performer Warning: cannot access this object from this process. Object type is pfDCS, id is ... , process id is ... Is this a bug or implemented on purpose. Only with PFMP_APPCULLDRAW it is possible to call those functions. Can anybody explain? Kind regards, Klaus Otto CAE Electronics GmbH (kotto%caeg.uucp@Germany.EU.net) From guest Sat Nov 13 10:27:28 1993 From: "Michael Jones" Message-Id: <9311131027.ZM17982@babar.asd.sgi.com> Date: Sat, 13 Nov 1993 10:27:20 -0800 In-Reply-To: kotto@caeg.rmi.de "callback functions" (Nov 13, 3:59pm) References: <9311131459.AA01253@caeg> X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: kotto@caeg.rmi.de, info-performer@sgi.sgi.com Subject: Re: callback functions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 -------------------------------------------------------------------- I am sorry to do just that which I was asking "kotto" not to do, but his mailer rejected my private email. I mean no harshness here, just trying to encourage proper network etiquette. -------------------------------------------------------------------- On Nov 13, 3:59pm, kotto@caeg.rmi.de wrote: > Subject: callback functions :Working with a Performer 1.2 beta version we noticed that ... Please do not use the info-performer mailing list for beta-related questions. There is a special mail address for these questions--it is provided in the "ReadMe1.2" file in /usr/src/Performer--and we ask that all beta-test sites use it. Asking beta-questions in the other list is not a productive use of the time of the many IRIS Performer developers not participating in the beta program. Thank you. Now, about your question...(It is of general interest)... :Working with a Performer 1.2 beta version we noticed that for example :pfGetNodeBBox or pfSetSwitchVal for a pfDCS or pfGroup is not allowed :in a callback procedure anymore (neither Cull nor Draw, it was allowed :in 1.1). : :We get the message: :Performer Warning: cannot access this object from this process. : Object type is pfDCS, id is ... , process id is ... : :Is this a bug or implemented on purpose. : :Only with PFMP_APPCULLDRAW it is possible to call those functions. You must not call node functions in the draw process, because the nodes are gone at stage and only geostates and geosets remain. Likewise, you must call graphics functions such as gl from the draw process because it has the graphics context. When you run in PFMP_APPCULLDRAW mode--singe process--these restrictions are removed since it's "all" there in the same process context. It is best to honor the process restrictions by verifying that your program will run in PPMP_APP_CULL_DRAW mode even if you have a single-cpu system because one day you may want to run that application on a multiple-CPU system. IRIS Performer provides the Indy->Onyx portability at full preformance IFF you abide by the process guidelines above and as detailed in the Programming Guide. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Nov 15 12:51:50 1993 Posted-Date: Mon, 15 Nov 93 15:51:27 -0500 Message-Id: <9311152051.AA01563@graphics.cis.upenn.edu> To: info-performer Cc: crabtree@graphics.cis.upenn.edu, granieri@graphics.cis.upenn.edu Subject: matrix stack overflow in Performer 1.0 Date: Mon, 15 Nov 93 15:51:27 -0500 From: John Granieri Status: OR Hello: We're creating a fairly deep node heirarchy in Performer (at least 70 pfDCS and pfSCSs deep), and get a matrix stack overflow when Performer traverses for the cull (this is a modified perfly program). Performer Warning (9):pfPushMStack: Matrix stack full it then core dumps. It seems to be pushing the matrix stack at pfDCS node (and pfGroup nodes), but is not really necessary at each level for our application (there are only about 5 max branches in our articulation tree going down any one path in the database). so I was wondering how I can control Performer's pushing and poping of the matrix stack using the node callbacks (to suppress the unnecessary pushes). Does anyone have an example of this? Thanks John Granieri Computer Graphics Research Lab University of PA. From guest Mon Nov 15 14:12:12 1993 Message-Id: <9311152212.AA04706@surreal.asd.sgi.com> To: John Granieri Cc: info-performer, crabtree@graphics.cis.upenn.edu Subject: Re: matrix stack overflow in Performer 1.0 In-Reply-To: Your message of "Mon, 15 Nov 93 15:51:27 EST." <9311152051.AA01563@graphics.cis.upenn.edu> Date: Mon, 15 Nov 93 14:12:09 -0800 From: Jim Helman Status: OR > We're creating a fairly deep node heirarchy in Performer (at least 70 > pfDCS and pfSCSs deep), "fairly" How about "very"? Currently the maximum depth of the Performer transformation stack is 64, which compares with GL's 32. So even if we could traverse it, you probably won't get it past the GL. Similarly, the OpenGL spec only requires that an implementation support of a depth of at least 32. I'm curious what sort of applications require such a deep transformation hierarchy. > and get a matrix stack overflow when Performer > traverses for the cull (this is a modified perfly program). > > Performer Warning (9):pfPushMStack: Matrix stack full > > it then core dumps. > > It seems to be pushing the matrix stack at pfDCS node (and pfGroup > nodes) Only at DCSes and SCSes. > but is not really necessary at each level for our application > (there are only about 5 max branches in our articulation tree going > down any one path in the database). so I was wondering how I can > control Performer's pushing and poping of the matrix stack using the > node callbacks (to suppress the unnecessary pushes). Does anyone have > an example of this? Are you saying that only 5 of the 70 pfDCSes and pfSCSes down any one path are non-identity transformations? If so, I can only suggest that you modify the effective topology of your scene graph. You can either dynamically reparent nodes or place pfSwitch nodes in parallel to switch between a path that goes through the DCS and one which goes around it. To avoid the memory and performance impact of lots of pfSwitch nodes, the same thing can be done with traversal masks and additional connections in the existing scene graph. Any of these approaches will return both the Performer and GL stack depth requirements of the application to within sane limits. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Nov 15 20:52:52 1993 Date: Mon, 15 Nov 93 22:34:45 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9311160434.AA16348@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Using all the CPU's Status: OR I have an application that has two pfPipes (one each on a sep. RE2 GE), one pfPipe with 4 pfChannels, and the other with 3 pfChannels. So basically, I have seven pfChannels. I am running on a four CPU system, and my CPU usage never goes anywhere above 70%. In fact, it usually hovers around 40% - 60%. Apparently the cull and draw processes are maxing out the CPU's (my database tries to balance the cull and draw processes) and there is no application stuff (to speak of) going on at this time. My question is this: What if I had 8 CPU's or 16? Would I still only be using 2.25 CPU's in this situation? I would like to be able to "parallelize" (not paralyze :-) my culling procedures if I have the idle CPU time sitting around (like I have a CPU that is totally idle at the moment.) I realize that later, my application and intersection routines will be more significant than they are now (I am in the testing/benchmarking phase.) But I can't help but wonder if there is something that I am missing that would allow me to load up the CPU's a bit more. Later, Aaron ----------------------------------------------------------------------------- Aaron Hightower :: Texas Instruments aaron@dseg.ti.com Visualization and Simulation Technology Development (214)575-6759 (w) Gig 'Em Ags! (214)517-9245 (h) From guest Mon Nov 15 22:51:10 1993 Message-Id: <9311160651.AA06494@surreal.asd.sgi.com> To: aaron@skips.dseg.ti.com (Aaron M. Hightower) Cc: info-performer@sgi.sgi.com Subject: Re: Using all the CPU's In-Reply-To: Your message of "Mon, 15 Nov 93 22:34:45 CST." <9311160434.AA16348@skips.dseg.ti.com> Date: Mon, 15 Nov 93 22:50:59 -0800 From: Jim Helman Status: OR Currently, you can have one draw process per pipe and one cull process per pipe. Usually this is adequate. In principle, an implementation of Performer could parallelize culling, but we do not currently. 70% CPU utilization is good. If you want to run at a constant frame rate, some headroom is usually required for a typical eyepoint, or you must find and benchmark the worst possible eyepoint in the database. Actually, with only 4 CPUs and 2 pipes, you are generating 5 processes APP, CULL1, CULL2, DRAW1, DRAW2. Since two of these processors must compete for a CPU, you might actually have too few processors if all processes are CPU intensive. Regarding 8-16 CPUs, the typical equation is 2*NumPipes + 1 (for APP) + 1 (for Unix). but applications with lots of intersections, dynamics, behaviors, networking, and I/O may use many more. Intersections can be N-way parallelized. CPU consumption for dynamics, behaviors, etc. is potentially unbounded. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 16 07:08:46 1993 Message-Id: <9311161508.AA11162@sgi.sgi.com> Date: 16 Nov 93 10:00:00 EST From: "Robert Reif" To: "info-performer" Status: OR I am getting floating point exceptions in pfSegsIsectNode when given segments with a direction of 0.0, 1.0, 0.0 under Performer 1.1 on an Onyx running 5.1.1.1. The error I get is: Performer info (11) FP division by zero. I don't have CASEVision on this machine so I can't determine if it is the pfSegIsectBox bug from 1.0 or something else. Robert Reif reif@ntsc-rd.navy.mil From guest Mon Nov 15 20:21:23 1993 From: "Jeff Olds" Message-Id: <9311161407.ZM3573@dolphin.brisbane.sgi.com> Date: Tue, 16 Nov 1993 14:07:13 -0500 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 unsubscribe -- Best Regards Jeff ---------------------------------------------------------------------- Jeff Olds o o Level 1, 895 Ann St., Senior Systems Engineer, | Fortitude Valley 4006 Silicon Graphics, Brisbane, Australia \_/ Voice Mail: 5-9178 Ph: +61-7-257-1194 jeffo@sydney.sgi.com Mail Stop: IAS-347 Fax: +61-7-257-1206 ---------------------------------------------------------------------- From guest Tue Nov 16 22:17:36 1993 Message-Id: <9311161928.AA13843@surreal.asd.sgi.com> To: "Robert Reif" Cc: "info-performer" In-Reply-To: Your message of "16 Nov 93 10:00:00 EST." <9311161508.AA11162@sgi.sgi.com> Date: Tue, 16 Nov 93 11:28:57 -0800 From: Jim Helman Status: OR Yes, this is the pfSegIsectBox bug from 1.0. I was under the impression it was fixed in 1.1 and may have said so. But after looking more closely, I now see the fix was inadvertantly backed out when 1.1 was built. The bug will cause a decrease of precision in the test against the bounding box of the pfGeoSet as the segment direction gets very close to (0,1,0); dead on, a divide by zero results. Ths risk is that you will miss a valid intersection if the precision gets bad enough. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 16 15:19:50 1993 Message-Id: <9311162319.AA13587@sgi.sgi.com> Date: 16 Nov 93 17:10:00 EST From: "Robert Reif" Subject: Bus error when using pfNodeTravMask To: "info-performer" I'm getting a bus error when using pfNodeTravMask to turn on intersection caching in Performer 1.0. The following line of code causes the problem: pfNodeTravMask(node, PFTRAV_ISECT, 0xffffffff, PFTRAV_SELF|PFTRAV_DESCEND|PFTRAV_IS_CACHE, PF_OR); CASEVision gives me the following message: Core from signal SIGBUS: Bus error _lmalloc() ["malloc.c":514, 0x43fe00] I did a pfDebugPrint on the node to make sure the node is good and everything looked OK. Robert Reif reif@ntsc-rd.navy.mil From guest Tue Nov 16 20:28:22 1993 Message-Id: <9311162359.AA19110@surreal.asd.sgi.com> To: "Robert Reif" Cc: "info-performer" Subject: Re: Bus error when using pfNodeTravMask In-Reply-To: Your message of "16 Nov 93 17:10:00 EST." <9311162319.AA13587@sgi.sgi.com> Date: Tue, 16 Nov 93 15:59:01 -0800 From: Jim Helman Sounds like something is stomping memory and trashing the arena data structures. It's probably blowing up in pfNodeTravMask because that's where the next pfMalloc is occuring that touches bogus data. Bugs like this can be hard to trace unless you have a good idea who might be writing past the end of an allocated array or such. If you don't have any idea, there's the hunt-and-peck method. You can use amallopt(3X) to turn on M_DEBUG so the data structure will be checked on every amalloc. Then you start sprinkling your code with pfMallocs from the arena until you narrow it down. I'm assuming that you're programming for MP and that the geosets in question were allocated from a shared memory arena, not from the heap. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Nov 16 22:39:15 1993 Date: Wed, 17 Nov 93 00:39:28 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9311170639.AA25654@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Coloring pfGroups We have an immediate need to turn a model black at sim time. We need to be able to (given a pfGroup *) change all the geosets in that group to use a single color (like black for instance). Is there a way to do this with pfNodeTravFuncs(mygroup, PFTRAV_DRAW, my_gl_func_to_color_everything_black, if_this_thing_says_ok, NULL, NULL); I haven't tried it, but I expect the GeoSet to override any color or texture that I use to turn this black (since I looked at the pfPrint of the group and found per vertex color and texture Attributes on the pfGeoSet level of the group model that I want to turn black). If I do lighting hacks (like a light with a color of black), I am assuming that I will have to re-enable the lighting in the post callback. We would ultimately like to be able to have some kind of pfSwitch that handles this by managing two Groups each with its own color settings, or else some way that implements this as part of the scene database. Anyway, we have not come up with a clear cut solution, and just thought that someone might know of a way to implement this type of thing. Anyone have a good method in performer? Also we have the same need for switching textures (IE having two textures that we can switch between at sim time). Thanks, Aaron Hightower ----------------------------------------------------------------------------- Aaron Hightower :: Texas Instruments aaron@dseg.ti.com Visualization and Simulation Technology Development (214)575-6759 (w) What did you dream? It's alright, we told you what to dream. -Pink Floyd From guest Wed Nov 17 01:54:35 1993 From: "Richard Mercille" Message-Id: <9311171054.ZM3849@loukoum.neu.sgi.com> Date: Wed, 17 Nov 1993 10:54:15 +0100 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Test please ignore Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 From aschaffe Wed Nov 17 21:10:59 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9311172110.ZM17558@holodeck.asd.sgi.com> Resent-Date: Wed, 17 Nov 1993 21:10:58 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) Resent-To: info-performer-dist Date: Wed, 17 Nov 93 13:00:24 -0500 From: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Message-Id: <9311171800.AA04846@ gizmo.lasc.lockheed.com> To: iris-performer@sgi.sgi.com Subject: Processor Selection Configuration: Onyx, 4 CPUs, 3 RE2 Pipes each with 4 RMs. This configuration doesn't meet the 2*NumPipes + 1App + 1Unix processor suggestions I've seen but I thought there might be some ways to configure a 2 or 3 pipe application to take advantage of the CPUs. I'm looking for suggestions on using sysmp and schedctl to control where the multiple processes run or any other scheme that works. Thanx -- Barry W. Webb Email: bwebb@gizmo.lasc.lockheed.com Lockheed Aeronautical Systems Company Vmail: (404) 494-6952 Fax: 6989 Marietta, Georgia 30063-0670 From aschaffe Wed Nov 17 21:14:50 1993 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9311172114.ZM17586@holodeck.asd.sgi.com> Resent-Date: Wed, 17 Nov 1993 21:14:50 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) Resent-To: info-performer-dist From: Renee Strong Message-Id: <9311171827.AA20580@pat.mdc.com> Subject: Cameras in trees To: info-performer@sgi.sgi.com Date: Wed, 17 Nov 93 12:27:41 CST X-Mailer: ELM [version 2.3 PL11] In our application we have cameras in trees attached to different pieces of hardware. When a user switches cameras we're going back up through the tree trying to create the proper matrix for the channel. Are we supposed to be pre-multiplying, post-multiplying or what? Any help would really be wonderful! Here's the code: extern OBJ *cur_camera; extern pfChannel *cur_channel; extern pfPipe *cur_pipe; extern pfScene *scene; void change_cams() { pfMatrix pos_rot, matrix; pfMatrix mat; pfCoord view; pfDCS *dcs; CAMERA *camera; camera = cur_camera->type_data.camera; cur_channel = camera->perf_cam_data; dcs = cur_camera->perf_node; pfChanNearFar(cur_channel, camera->near, camera->far); pfChanFOV(cur_channel, camera->FOV, -1.0f); pfGetDCSMatrix(dcs, pos_rot); /* * put in pan and tilt */ pfSetVec3(view.hpr, -camera->pan, 0.0, -camera->tilt); pfSetVec3(view.xyz, 0.0, 0.0, 0.0); pfMakeCoordMat(matrix, &view); pfPreMultMat(pos_rot, matrix); /* * rotate -90 in x because performer is off by 90 degrees in x from gl */ pfSetVec3(view.hpr, 0.0, -90.0, 0.0); pfSetVec3(view.xyz, 0.0, 0.0, 0.0); pfMakeCoordMat(matrix, &view); pfPreMultMat(pos_rot, matrix); /* * put on all the preceding trans and rots */ do { dcs = (pfDCS *)pfGetParent(dcs, 0); pfGetDCSMatrix(dcs, mat); pfPreMultMat(pos_rot, mat); } while (dcs != root_node->perf_node); pfChanViewMat(cur_channel, pos_rot); pfChanScene(cur_channel, scene); } Thanks, Renee Strong renee@pat.mdc.com From guest Thu Nov 18 09:47:17 1993 From: Renee Strong Message-Id: <9311181700.AA24015@pat.mdc.com> Subject: backfacing and timing tests To: info-performer@sgi.sgi.com Date: Thu, 18 Nov 93 11:00:47 CST X-Mailer: ELM [version 2.3 PL11] We're trying to do some timing tests with Performer. The software we're running against has backfacing enabled so the backfacing polygons are NOT drawn. Does Performer automatically enable backfacing or is there something I can do to enable it? Thanks, Renee Strong renee@pat.mdc.com From guest Thu Nov 18 10:25:14 1993 From: "Michael Jones" Message-Id: <9311181023.ZM10776@babar.asd.sgi.com> Date: Thu, 18 Nov 1993 10:23:29 -0800 In-Reply-To: Renee Strong "backfacing and timing tests" (Nov 18, 11:00am) References: <9311181700.AA24015@pat.mdc.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: Renee Strong , info-performer@sgi.sgi.com Subject: Re: backfacing and timing tests Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Nov 18, 11:00am, Renee Strong wrote: > Subject: backfacing and timing tests : :We're trying to do some timing tests with Performer. The software we're :running against has backfacing enabled so the backfacing polygons are NOT :drawn. Does Performer automatically enable backfacing or is there something :I can do to enable it? Culling of backfacing polygons is controlled with the pfCullFace() function -- check the man page for examples. -- 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 Nov 18 20:16:40 1993 Date: Thu, 18 Nov 93 23:24:01 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9311190424.AA28608@cae.ca> To: info-performer@sgi.sgi.com Subject: Gfx engine crash During the last week, I have run the same Performer-based program which makes heavy use of texture mapping on two different Reality Engine platforms (a 420 RE running Irix 4.0.5H and an Onyx/4 RE2 running Irix 5.0.1). Everything is fine most of the time but occasionally (once every couple of hours), the graphics freeze up and die and I am thrown back to the login prompt without warning or even a core dump. After looking around, I did find the following cryptic messages in /usr/adm/SYSLOG: Nov 18 18:37:18 mesef_visual unix: GE4: Bad CP command encountered Nov 18 18:37:18 mesef_visual unix: GE5: Bad CP command encountered Nov 18 18:37:18 mesef_visual unix: GE5: Bad CP command order Nov 18 18:37:18 mesef_visual unix: GE5: Bad CP command encountered Nov 18 18:37:18 mesef_visual unix: GE5: Bad CP command order Nov 18 18:37:18 mesef_visual unix: GE6: Bad CP command encountered Nov 18 18:37:18 mesef_visual unix: GE6: Bad CP command order Nov 18 18:37:33 mesef_visual unix: WARNING: venice: lightweight deactivation timed out Nov 18 18:37:33 mesef_visual unix: WARNING: venice: vcstage change timed out I have seen Reality Engines do that before with pure GL programs on Crimson RE and 420 RE platforms and have talked to people complaining of similar problems. I was hoping that using Performer on a brand-new Onyx running a brand-new OS (IRIX 5) would take care of the problem but I was apparently mistaken. Now, am I doing something wrong or is this a well-known problem with the Reality Engine? Is this happening to anybody else? --------------------------------------------------------------------------- J.F. Richard CAE Electronics --------------------------------------------------------------------------- From guest Fri Nov 19 07:14:31 1993 From: "Michael Jones" Message-Id: <9311190714.ZM14275@babar.asd.sgi.com> Date: Fri, 19 Nov 1993 07:14:29 -0800 In-Reply-To: "Stephen Joyce {75069}" "" (Nov 18, 3:24pm) References: <9311182024.AA24446@swlrgk> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: "Stephen Joyce {75069}" , info-performer Subject: Stereo Capability Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Nov 18, 3:24pm, Stephen Joyce {75069} wrote: :Does anyone know if stereo capability is going to be :present in Performer 1.2? People have been doing stereo with IRIS Performer since day one. What exactly is meant by the question--I presume that you mean "will IRIS Performer 1.2 make stereo easier" or "automatic". If you mean possible then it already is. -- 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 Sat Nov 20 07:18:13 1993 Date: Sat, 20 Nov 93 14:57:14 GMT From: David Cooper Message-Id: <9311201457.AA14492@ariel.division.demon.co.uk> To: performer@crusty, info-performer@sgi.sgi.com Subject: Questions Status: OR I have an urgent need to know the answers to the following questions: I am using Performer 1.1 1) Is there a way to modify the zwritemask from within performer or do I have to use a pre/post render callback approach ? With the callback method would there be any other implications ? How could I minimise the impact of this mode change if I have a number of geosets that require a modified zwritemask ? 2) If I want to switch blendfunction on/off dynamically for a number of geosets depending on a variable set per frame, what is the most performance efficent way to do this ? The blendfunction may be the only common feature between the geosets. Would changing the geostate of a parent node while in cull work reliably when in multiprocess mode ? 3) If I have dynamically changing geometry, performance wise is it better to write the code in GL or to modify geosets at cull time ? Is there a way to lock out the render process to allow safe changing of geosets dynamically, in a multiprocess environment ? 4) When running an a RE what does performer do with the ms alpha mask ? If I was to modify this dynamically would there be any Performer implications ? 5) Again in a multiprocess environment what would happen if a cull callback was to delete its node ? Would this throw the app out of skew ? 6) Is the pfChanData structure the only multiprocess buffered data available ? Is it possible to use pfNodeTravFuncs data in shared memory to communicate bewteen associated cull and render callbacks - assuming of course that there is a way to buffer the data. 7) Is there a way to prepage texture into texture memory dynamically, to avoid having the huge delay on the first drawing of every texture? Without having the luxury of being able to load/draw every texture at init time ? I don't care if it is unsupported or unreliable, anything would be better than the current situation. 8) Our virtual reality systems operate in a different coordinate frame from Performer, it is not possible to modify our existing system as it encompasses a lot of hardware/software (tracking, sound, collison detection, etc) some from external suppliers. This gives me a number of headaches and makes it very difficult to use some Performer functions including pfESky and pfBillboards which use the eye heading, roll, and pitch to operate. Is there any way to get performer to change its coord frame? Simply rotating/translating the channel viewpoint does not appear to work - the sky flies all over the place when you change orientation. If one doesn't exist how about a user settable flag to indicate what coord system your using. After all, Performer doesn't agree with GL, and SGI worked for 10 years to get GL accepted as a standard. Theres a lot of code out there aimed at the GL coord system, and it can be a pain to convert. David Cooper Division Ltd UK From guest Sat Nov 20 08:03:28 1993 Date: Sat, 20 Nov 93 15:25:10 GMT From: David Cooper Message-Id: <9311201525.AA14532@ariel.division.demon.co.uk> To: performer@crusty, info-performer@sgi.sgi.com Subject: One more question I am having probems getting performer to load 1 or 4 component textures on a onyx - I am using pfLoadTexFile. 3 component looks fine but 1 or 4 get loaded as 3 causing some strange results. Is there something else I need to do ? And one last question, on an onyx is 4 bit per component texture quicker than 8 bit. I have a feeling that the texture bus is 16 bits wide but I am not sure. David Cooper Division Ltd UK From guest Sat Nov 20 09:10:30 1993 Date: Sat, 20 Nov 1993 09:10:41 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199311201710.JAA03447@mail.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: Questions Status: OR David Cooper, Division, Ltd. writes: 8) Our virtual reality systems operate in a different coordinate frame from Performer, it is not possible to modify our existing system as it encompasses a lot of hardware/software (tracking, sound, collison detection, etc) some from external suppliers. This gives me a number of headaches and makes it very difficult to use some Performer functions including pfESky and pfBillboards which use the eye heading, roll, and pitch to operate. Is there any way to get performer to change its coord frame? Simply rotating/translating the channel viewpoint does not appear to work - the sky flies all over the place when you change orientation. If one doesn't exist how about a user settable flag to indicate what coord system your using. After all, Performer doesn't agree with GL, and SGI worked for 10 years to get GL accepted as a standard. Theres a lot of code out there aimed at the GL coord system, and it can be a pain to convert. I second David's suggestion/request. Our Performer application we built at NASA Ames evolved from an existing application that used GL coord. axis orientation. Although it was fairly trivial to just compose a matrix transformation with the view matrix prior to each pfFrame (I should say, "trivial" once I figured out how Performer's view matrix transformation is composed since that's not clearly described in the documentation), it still left a lot of design headaches due to having to think about two different coord. systems simultaneously. Lew (the documentation gadfly) Hitchner Xtensory Inc. Scotts Valley, CA From guest Sat Nov 20 11:11:46 1993 Date: Sat, 20 Nov 1993 13:10:43 -0600 (CST) From: Ming Pan Subject: ? To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I forget how to unscribe. Thanks for help. ===================================================== Their address sums up their attitude and destiny: One Microsoft Way Ming Pan Tel: (512) 320-8859 ===================================================== From guest Sat Nov 20 12:33:35 1993 Message-Id: <9311202033.AA26311@surreal.asd.sgi.com> To: Renee Strong Cc: info-performer@sgi.sgi.com Subject: Re: backfacing and timing tests In-Reply-To: Your message of "Thu, 18 Nov 93 11:00:47 CST." <9311181700.AA24015@pat.mdc.com> Date: Sat, 20 Nov 93 12:33:27 -0800 From: Jim Helman In Performer 1.0/1.1, pfCullFace(CF_BACK) was not enabled by default in libpf, but perfly did in its initGfx routine. In Perfomer 1.2 backface removal is enabled by libpf in pfInitGfx or pfInitGLXGfx. To disable it, call pfCullFace(CF_OFF) after calling the respective routine. This assumes you are inheriting the cull face mode. Each individual pfGeoState can also specify it. If you only have a few things which won't work with backface removal, it's better to just have those pfGeoStates disable it. -jim From guest Sat Nov 20 12:55:07 1993 Message-Id: <9311202054.AA26340@surreal.asd.sgi.com> To: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Cc: iris-performer@sgi.sgi.com Subject: Re: Processor Selection In-Reply-To: Your message of "Wed, 17 Nov 93 13:00:24 EST." <9311171800.AA04846@ gizmo.lasc.lockheed.com> Date: Sat, 20 Nov 93 12:54:59 -0800 From: Jim Helman re: 2 pipes on 4 CPUs. The appropriage Performer multiprocessing mode depends on how APP, CULL or DRAW intensive your application is. And whether you need absolute realtime behavior (Unix out of your hair). If neither the APP or CULL is too long, but the DRAW is heavy, you might run PFMP_APP_CULL_DRAW, get 5 processes (APP + CULL1 + CULL2 + DRAW1 + DRAW2) for your 2 pipes and have the Unix + CULL1 share a processor and have APP + CULL2 share another with each DRAW taking one of the remaining two. If your APP is heavy, but CULL or DRAW isn't you could run PFAPP_CULLDRAW, get 3 processes (APP + CULLDRAW1 + CULLDRAW2). Then you can lock everything down and still have one for Unix. Performer 1.2 has a cull direct mode which should be faster than the sequential CULLDRAW in the last example. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Nov 20 13:44:21 1993 Message-Id: <9311202144.AA26587@surreal.asd.sgi.com> To: David Cooper Cc: performer@crusty, info-performer@sgi.sgi.com Subject: Re: One more question In-Reply-To: Your message of "Sat, 20 Nov 93 15:25:10 GMT." <9311201525.AA14532@ariel.division.demon.co.uk> Date: Sat, 20 Nov 93 13:44:14 -0800 From: Jim Helman > I am having probems getting performer to load 1 or 4 component textures on a > onyx - I am using pfLoadTexFile. 3 component looks fine but 1 or 4 > get loaded as 3 causing some strange results. Is there something else I need > to do ? Should work. What does istat say about the depth? What application is creating the textures? > And one last question, on an onyx is 4 bit per component texture quicker than > 8 bit. I have a feeling that the texture bus is 16 bits wide but I am not sure. 16 bit texels are about twice as fast as 32 bit texels. By default, Performer uses what is fastest rather than prettiest. It can be specified using pfTexFormat, e.g. for RGB or RGBA textures: pfTexFormat(tex, PFTEX_INTERNAL_FORMAT, PFTEX_RGBA8) rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Nov 20 13:50:18 1993 Message-Id: <9311202150.AA26595@surreal.asd.sgi.com> To: hitchner@netcom.com (Lew Hitchner) Cc: info-performer@sgi.sgi.com Subject: Re: Questions In-Reply-To: Your message of "Sat, 20 Nov 93 09:10:41 PST." <199311201710.JAA03447@mail.netcom.com> Date: Sat, 20 Nov 93 13:50:10 -0800 From: Jim Helman Status: OR Currently, Performer only supports the one coordinate system, and it's up to an application or higher level toolkit to deal with the differences. We've talked about multiple coordinate systems, but given the number of different coordinate systems and the number of Euler permutations, it would be difficult to cover all bases. GL's frame would be the most important. What Euler conventions would you want for it? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Nov 20 14:51:58 1993 Message-Id: <9311202251.AA26715@surreal.asd.sgi.com> To: David Cooper Cc: info-performer@sgi.sgi.com Subject: Re: Questions In-Reply-To: Your message of "Sat, 20 Nov 93 14:57:14 GMT." <9311201457.AA14492@ariel.division.demon.co.uk> Date: Sat, 20 Nov 93 14:51:43 -0800 From: Jim Helman Too many good questions.... 1) Is there a way to modify the zwritemask from within performer or do I have to use a pre/post render callback approach ? With the callback method would there be any other implications ? How could I minimise the impact of this mode change if I have a number of geosets that require a modified zwritemask ? Callbacks are the way to do it. You can group the affected geodes together under a single group and set and restore the Z writemask in its pre- and post- draw callbacks. If the geometry is not spatially localized, you'll have a cull vs. draw tradeoff to make. One big pfGroup with geometry from all over the database would minimize the mode changes, but be detrimental to efficient cull testing. 2) If I want to switch blendfunction on/off dynamically for a number of geosets depending on a variable set per frame, what is the most performance efficent way to do this ? The blendfunction may be the only common feature between the geosets. Would changing the geostate of a parent node while in cull work reliably when in multiprocess mode ? Nodes do not have geostates, but if you want to turn on blendfunction for everthing under a single node, you could turn on blendfunction in a pre-draw callback and then turn it off in the post-draw callback. You might also want to change the Performer transparency mode, since we default to multisample alpha. 3) If I have dynamically changing geometry, performance wise is it better to write the code in GL or to modify geosets at cull time ? Is there a way to lock out the render process to allow safe changing of geosets dynamically, in a multiprocess environment ? It depends. Doing any computation in the draw process will detract from rendering throughput. Modifying the geosets in the draw process could also create problems in multipipe mode, as well as potentially duplicate work. The best thing to do is to create multiple copies of the geometry and use a pfSwitch node to cycle among them. This way all the computations can be done in the application process. See the code to the lake demo, the water is handled this way. A future release will have a much slicker way to handle dynamic geometry. 4) When running an a RE what does performer do with the ms alpha mask ? If I was to modify this dynamically would there be any Performer implications ? By default, we use multisample alpha rather then blendfunction transparency since it's faster. We also use msmask() for fade LOD. Playing with it could affect fade LOD or transparency. 5) Again in a multiprocess environment what would happen if a cull callback was to delete its node ? Would this throw the app out of skew ? You can only delete portions of the scene graph safely in 1.2. You should only create and delete pfNodes in the application process. 6) Is the pfChanData structure the only multiprocess buffered data available ? Is it possible to use pfNodeTravFuncs data in shared memory to communicate bewteen associated cull and render callbacks - assuming of course that there is a way to buffer the data. As long as the userdata pointer or pfNodeTravData pointers you supply point to share memory, you can look at them in any process. The pointers themselves should be set in the application process since they propagate downstream frame accurately. 7) Is there a way to prepage texture into texture memory dynamically, to avoid having the huge delay on the first drawing of every texture? Without having the luxury of being able to load/draw every texture at init time ? I don't care if it is unsupported or unreliable, anything would be better than the current situation. A future release will support texture paging. Currently, when a texture is needed, it's downloaded. For large textures this can be time consuming especially on PowerSeries machines. Using smaller textures will help some since you can spread the download over several frames. Like in the perly downloadtextures routine, be sure you have done a pfApplyTex on all of the textures before hand, even if they won't all fit in the pipe . This insures that the texdef has been done, the texture formatted and mipmaps generated. Also calling pfIdleTex on any textures you know are no longer needed will also help. This tells the texture manager what can be safely trashed. Otherwise you might thrash for a while as you overwrite needed textures. It's best to spread these out over a number of frames, since pfIdleTex can be slow. This is the approach used by the Yellowstone Park geospecific terrain flythough shown at TriAda. If the texture is not mipped and you need to def on the fly as well, you can do a fast def using the GL's TX_FAST_DEFINE and a texture already in the correct format. This is how programm like Wade Olsen's tele do video effects texturing in Performer at 30Hz. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Nov 20 16:44:32 1993 Date: Sat, 20 Nov 1993 16:44:51 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199311210044.QAA14637@mail.netcom.com> To: jimh@surreal Subject: Re: Questions Cc: info-performer@sgi.sgi.com Status: OR Jim Helman writes: GL's frame would be the most important. What Euler conventions would you want for it? I guess for consistency rotations about x, y, z would be the best ordering, i.e., pitch, yaw, roll with same sign conventions as GL rotations. Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Mon Nov 22 06:49:43 1993 From: kotto@caeg.rmi.de Date: Mon, 22 Nov 93 15:48:31 +0100 Message-Id: <9311221448.AA01243@caeg> To: info-performer@sgi.sgi.com Subject: zwritemask modification Trying to modify the zwritemask (to 0x0) for entire branches of the database tree we found that Performer re-enables the z-writing (for example while drawing light points or transparent geometry). So I have the following questions: 1) Can I tell Performer to keep the zwritemask at the given state? 2) Is there a list of Performer functions where zwritemask is switched? 3) In those functions, is the zwritemask switched at the end of the function or somewhere in the middle? If the latter is true I think I have to avoid such geometry ! For the first I would have to live with zwritemask(0x0)'s in all (critical) post draw callbacks. Thanks in advance, Klaus Otto CAE Electronics GmbH (kotto%caeg.uucp@Germany.EU.net) From guest Tue Nov 23 10:11:31 1993 Date: Tue, 23 Nov 1993 10:11:37 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199311231811.KAA28777@mail.netcom.com> To: decker@pat.mdc.com, renee@pat.mdc.com Subject: Re: GL to Performer Transformation Cc: info-performer@sgi.sgi.com Here is my C code that I used to convert from a viewing transformation matrix that was caclulated in GL coord. axis frame to the Performer coord. frame. This is just a "trivial" 90 degree rotation matrix as was pointed out by a couple list members. The "non-trivial" part was figuring out how to use this matrix in Performer. My discovery (by trial and error) was that Performer composes its viewing transformation matrices differently than GL. Thus pre-multiplication by the inverse of the 90 degree rotation worked instead of post-multiplication by the forward matrix. My calculations for composing the viewing transf. matrix used below (calculated in a separate function) were also done by pre-multiplying of inverse transf. rather than post-mult. forward transf. Perhaps the explanation of how transformation matrices are composed could be included in future Performer documentation. Lew Hitchner Xtensory Inc. Scotts Valley, CA void ViewUpdate( ObjectPtr viewObjPtr ) { ViewPtr theView; int chan, nChannels; ChannelPtr *chanInfoPtr; pfMatrix channelViewTransf; static pfMatrix /* conversion transf. from: RHS Euclidean Coords.: +X = right, +Y = up, +Z = backwards to SGI Performer Coords.: +X = right, +Y = forwards, +Z = up */ coordTransfFwd = { { ONEF, ZEROF, ZEROF, ZEROF }, { ZEROF, ZEROF, ONEF, ZEROF }, { ZEROF, -ONEF, ZEROF, ZEROF }, { ZEROF, ZEROF, ZEROF, ONEF } }, coordTransfInv = { { ONEF, ZEROF, ZEROF, ZEROF }, { ZEROF, ZEROF, -ONEF, ZEROF }, { ZEROF, ONEF, ZEROF, ZEROF }, { ZEROF, ZEROF, ZEROF, ONEF } }; if (viewObjPtr == (ObjectPtr)NULL) return; theView = (ViewPtr)viewObjPtr; . . . /* ** Set the viewing transformation matrix for each channel. */ nChannels = theView->chanList->nChannels; for (chan = 0, chanInfoPtr = theView->chanList->chanInfo; chan < nChannels; chan++, chanInfoPtr++) { /* ** Get the transformation matrix for the View platform ** associated with this 3D viewing channel. ** (This is calculated elsewhere. It is calculated ** by pre-multiplying of inverse transf. rather than ** post-mult. forward transf.) */ vpGetGlobalTransf(theView->chanList->platform[chan], (char *)NULL, channelViewTransf, False, False); . . . /* ** Set Performer's channel view transf. matrix. ** Change coord. system from GL to SGI Performer coords.: ** from RHS with +X right, +Y up, and +Z backwards ** to RHS system with +X right, +Y forwards, and +Z up. */ matMultiply(coordTransfInv, channelViewTransf, channelViewTransf); pfChanViewMat((*chanInfoPtr)->pfchannel, channelViewTransf); . . . } . . . return; } From guest Tue Nov 23 12:28:07 1993 Date: Tue, 23 Nov 93 12:27:55 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9311232027.AA16955@tubes.asd.sgi.com> To: kotto@caeg.rmi.de, info-performer@sgi.sgi.com Subject: Re: zwritemask modification >Trying to modify the zwritemask (to 0x0) for entire branches of the >database tree we found that Performer re-enables the z-writing >(for example while drawing light points or transparent geometry). > >So I have the following questions: > >1) Can I tell Performer to keep the zwritemask at the given state? Not at this time. >2) Is there a list of Performer functions where zwritemask is switched? pfTransparency and pfDecal(PFDECAL_BASE_DISPLACE) both set zwritemask. >3) In those functions, is the zwritemask switched at the end of the > function or somewhere in the middle? > If the latter is true I think I have to avoid such geometry ! > For the first I would have to live with zwritemask(0x0)'s in > all (critical) post draw callbacks. pfLightPoints and pfLayer nodes call pfTransparency and pfDecal respectively. You can choose to use stencil-type decaling with pfLayerMode(layer, PFDECAL_BASE_STENCIL) which will not modify the zwritemask. To get around pfTransparency setting the zwritemask you will have to use post-draw callbacks on all transparent geometry to be safe. Alternately you can globally disable transparency with pfOverride. From guest Tue Nov 23 12:34:45 1993 Date: Tue, 23 Nov 93 12:34:28 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9311232034.AA17000@tubes.asd.sgi.com> To: aaron@skips.dseg.ti.com (Aaron M. Hightower), iris-performer@sgi.sgi.com Subject: Re: Coloring pfGroups >We have an immediate need to turn a model black at sim time. We need to >be able to (given a pfGroup *) change all the geosets in that group to >use a single color (like black for instance). > >Is there a way to do this with > >pfNodeTravFuncs(mygroup, > PFTRAV_DRAW, > my_gl_func_to_color_everything_black, > if_this_thing_says_ok, > NULL, > NULL); > >I haven't tried it, but I expect the GeoSet to override any color or >texture that I use to turn this black (since I looked at the pfPrint of >the group and found per vertex color and texture Attributes on the >pfGeoSet level of the group model that I want to turn black). > >If I do lighting hacks (like a light with a color of black), >I am assuming that I will have to re-enable the lighting in the post callback. > >We would ultimately like to be able to have some kind of pfSwitch that >handles this by managing two Groups each with its own color settings, >or else some way that implements this as part of the scene database. > >Anyway, we have not come up with a clear cut solution, and just thought >that someone might know of a way to implement this type of thing. > >Anyone have a good method in performer? Also we have the same need for >switching textures (IE having two textures that we can switch between >at sim time). Colors are set locally by pfGeoSets unless lighting is active and lmcolor mode is off (LMC_NULL). What you should do is 1. enable lighting: pfEnable(PFEN_LIGHTING); 2. apply a lighting model without ambient: pfApplyLModel() 3. apply a material without ambient: pfApplyMtl() 4. apply a black light: pfLightOn() 5. disable lmcolor mode: pfMtlColorMode(mtl, PFMTL_FRONT, PFMTL_CMODE_NULL); Furthermore, you should override all of the above state so they cannot be modified by any pfGeoStates etc: pfOverride(PFSTATE_ENLIGHTING|PFSTATE_LMODEL etc..., 1); From guest Wed Nov 24 16:14:00 1993 From: "Sharon Fischler" Message-Id: <9311241613.ZM28393@rose.asd.sgi.com> Date: Wed, 24 Nov 1993 16:13:48 -0800 In-Reply-To: jrohlf@tubes (John Rohlf) "Re: Coloring pfGroups" (Nov 23, 12:34pm) References: <9311232034.AA17000@tubes.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: jrohlf@tubes (John Rohlf), aaron@skips.dseg.ti.com (Aaron M. Hightower), iris-performer@sgi.sgi.com Subject: Re: Coloring pfGroups Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 +>---- On Nov 23, 12:34pm, John Rohlf wrote: > Subject: Re: Coloring pfGroups -> ->>We have an immediate need to turn a model black at sim time. We need to ->>be able to (given a pfGroup *) change all the geosets in that group to ->>use a single color (like black for instance). [ ....] -> -> Colors are set locally by pfGeoSets unless lighting is active ->and lmcolor mode is off (LMC_NULL). What you should do is -> -> 1. enable lighting: pfEnable(PFEN_LIGHTING); -> 2. apply a lighting model without ambient: pfApplyLModel() -> 3. apply a material without ambient: pfApplyMtl() -> 4. apply a black light: pfLightOn() -> 5. disable lmcolor mode: -> pfMtlColorMode(mtl, PFMTL_FRONT, PFMTL_CMODE_NULL); -> ->Furthermore, you should override all of the above state so they cannot ->be modified by any pfGeoStates etc: -> -> pfOverride(PFSTATE_ENLIGHTING|PFSTATE_LMODEL etc..., 1); -> +>---- End of excerpt from John Rohlf It can be a little bit simpler than this using highlighting. You can set a pfHighlight structure with black forground/background colors on the pfGeoSets or pfGeoStates of interest. If lighting is not enabled, your geometry will be black. If lighting is enabled, your geometry will be black with white specular highlights - so you may want to override lighting off, as suggested above. To put a highlight structure on a pfGeoSet: pfGSetHlight(pfGeoSet* _gset, pfHighlight *_hlight); To put a highlight structure on a pfGeoState: pfGStateAttr(gstate, PFSTATE_HIGHLIGHT, hlight); Highlighting can also be be enabled/disabled, overrided, and set with pfEnable(),pfDisable(), pfOverride(), and pfApplyHlight() If this looks interesting, see the man pages for the above, and also the example hlcube.c in /usr/src/Performer/src/pguide/libpr/progs/ Also, in libpfutil, there is a traversal provided that will put a specific highlighting structure on all of the geometry under a specified node: pfuTravNodeHlight(pfNode *_node, pfHighlight *_hl); srf. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Wed Nov 24 16:39:48 1993 From: "Michael Jones" Message-Id: <9311241639.ZM2241@babar.asd.sgi.com> Date: Wed, 24 Nov 1993 16:39:35 -0800 In-Reply-To: "Sharon Fischler" "Re: Coloring pfGroups" (Nov 24, 4:13pm) References: <9311232034.AA17000@tubes.asd.sgi.com> <9311241613.ZM28393@rose.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: "Sharon Fischler" , jrohlf@tubes (John Rohlf), aaron@skips.dseg.ti.com (Aaron M. Hightower), iris-performer@sgi.sgi.com Subject: Re: Coloring pfGroups Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 It's simpler yet if you use colortables. That's what they are designed to do. Check out the pfColortable manpage. -- 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 Nov 30 13:29:37 1993 From: JAYDEE@zeus.ats.qc.ca 30 Nov 93 16:29:29 +500 Message-Id: Organization: ATS Aerospace To: info-performer@sgi.sgi.com Date: Tue, 30 Nov 1993 16:22:20 EDT-500 Subject: Multipipe query X-Mailer: PMail v3.0 (R1a) Status: OR We are having problems with IRIS Performer 1.1 in a multipipe/ multichannel configuration. The hardware involved is an Onyx RE^2 with three graphics pipelines, each of which has the Multi-Channel Option installed. Other relevant tidbits from hinv are: 2 150 MHZ IP19 Processors CPU: MIPS R4400 Processor Chip Revision: 5.0 FPU: MIPS R4010 Floating Point Chip Revision: 0.0 Main memory size: 128 Mbytes, 2-way interleaved Multi-Channel Option board installed RealityEngine Graphics option installed Multi-Channel Option board installed RealityEngine Graphics option installed Multi-Channel Option board installed RealityEngine Graphics option installed Our application requires 8 45-degree channels of realistic visuals with an update rate of 30Hz. The eyepoint is generally fixed, but there is a potentially large number of visible moving models. The world and moving model databases are loaded from MultiGen .flt files. Currently, we can achieve 20Hz with occasional blips in performance with 3 channels on a single pipe (the PFMP_APPCULL_DRAW multiprocessing model seems to give the smoothest performance). Attempts to extend to multiple pipelines meet with limited success. When the scene is restricted to a single pfGeode cube (no .flt files loaded), we get high (~75%) utilization on both processors driving one channel on each of the 3 pipes at 20Hz (using PFMP_APPCULLDRAW or PFMP_APP_CULL_DRAW -- PFMP_APPCULL_DRAW is illegal). Things really go downhill when the scene is loaded from a flight file. There are frequent bus errors and segmentation faults. Typical Performer diagnostics are (I paraphrase): pfFree() -- attempt to free block not allocated with pfMalloc() pfMakeEmptyDList() -- NULL pfDispList pfDrawDList() -- NULL pfDispList These diagnostics appear on the first frame. When the program does run successfully, there is no texture visible on the channels for pipes 1 and 2 (pipe 0 is rendered correctly). Texture does work on all pipes with the trivial cubic pfGeode. It appears that the .flt loader is unable to deal with multipipe/multi processing. I have broached the topic with Software Systems (who now support the loader), but have yet to hear back from them. I have also opened a service call to SGI directly. Does anyone out there have experience with a similar hardware/software configuration? In particular, what needs to be allocated in shared memory so as to be accessible from the multitude of draw processes in the multiple pipe scenario? Does the whole scene graph have to live in the shared arena? It was my impression that everything allocated in the application process prior to the forking of cull and draw processes would be visible to the child processes. Of course, LoadFlt() is called _after_ pfConfig(), which purportedly perpetrates the forking... Is there a sample program for multiple pipes? I'm a bit confused about the callback function for pfInitPipe(). How much needs to be done on a per pipe basis (e.g. config a gl window), and what is done only once per application (device queuing, applying default texture environment...)? Similarly for the channel draw callback function. Once the application is limping along with no catastrophic errors, is there an easy way to determine to what extent it is CPU-bound? Are we asking too much of our 2 processors (it looks like PFMP_APP_CULL_DRAW results in 7 processes)? Any feedback or pointers to useful sources of information would be greatly appreciated. Cheers, Jean Daigle. ----------------------------------------------------------------- | Jean Daigle ATS AeroTechnologies Inc. | | Software Designer 1250 Boul Marie-Victorin | | St. Bruno, QC J3V 6B8 | | jaydee@ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 | ----------------------------------------------------------------- From guest Tue Nov 30 15:33:23 1993 Message-Id: <9311302333.AA06566@surreal.asd.sgi.com> To: JAYDEE@zeus.ats.qc.ca Cc: info-performer@sgi.sgi.com Subject: Re: Multipipe query In-Reply-To: Your message of "Tue, 30 Nov 93 16:22:20 EDT." Date: Tue, 30 Nov 93 15:33:06 -0800 From: Jim Helman Status: OR > The hardware involved is an Onyx RE^2 with three graphics pipelines, > each of which has the Multi-Channel Option installed. Other > relevant tidbits from hinv are: > > 2 150 MHZ IP19 Processors > CPU: MIPS R4400 Processor Chip Revision: 5.0 > FPU: MIPS R4010 Floating Point Chip Revision: 0.0 > Driving 3 graphics pipes and 8 channels with 2 CPUs is very aggressive. I doubt you will achieve 30Hz. A configuration for maximum throughput would have 2 CPUs per hardware graphics pipe (CULL+DRAW) plus one for the APP plus one for Unix. If your many moving models all need 30Hz terrain following, you may need more (MP intersections are supported in 1.2). Under 1.2, you can get by with 1 CPU per graphics pipe at some cost in throughput by using a cull traversal which directly draws, but under 1.1 your cull time will subtract from your drawing time. > Attempts to extend to multiple pipelines meet with limited success. > When the scene is restricted to a single pfGeode cube (no .flt files > loaded), we get high (~75%) utilization on both processors driving > one channel on each of the 3 pipes at 20Hz (using PFMP_APPCULLDRAW > or PFMP_APP_CULL_DRAW -- PFMP_APPCULL_DRAW is illegal). > Both PFMP_APPCULLDRAW, PFMP_APPCULL_DRAW should work as arguments to pfMultipipe. But in multipipe mode Performer will go ahead and fork the CULL leaving PFMP_APP_CULLDRAW, PFMP_APP_CULL_DRAW, respectively. > Things really go downhill when the scene is loaded from a flight > file. There are frequent bus errors and segmentation faults. Typical > Performer diagnostics are (I paraphrase): > pfFree() -- attempt to free block not allocated with pfMalloc() > pfMakeEmptyDList() -- NULL pfDispList > pfDrawDList() -- NULL pfDispList > From the Performer FAQ (posted in here and in comp.sys.sgi.graphics periodically): Subject: -49- 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; > It appears that the .flt loader is unable to deal with multipipe/multi > processing. I have broached the topic with Software Systems (who now > support the loader), but have yet to hear back from them. I have > also opened a service call to SGI directly. Multipipe operation isn't a database loader issue. Hopefully, the above initialization will fix your problem. The next most frequent source of multipipe problems are application MP issues. > Once the application is limping along with no catastrophic errors, > is there an easy way to determine to what extent it is CPU-bound? > Are we asking too much of our 2 processors (it looks like > PFMP_APP_CULL_DRAW results in 7 processes)? Yes. You have 7 active processes, actually 8 total processes (1 APP + 3 CULL + 3 DRAW + CLOCK), but the clock wrapper doesn't really count. If you want to have a process feeding each graphics pipe all the time, you need more CPUs. Also for solid realtime behavior, you need to isolate processors and dedicate them to tasks (see sysmp(2)). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun Dec 5 01:02:14 1993 Message-Id: <199312050902.AA06202@artemis.cmr.no> To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: pfRemoveChild(...) Date: Sun, 05 Dec 93 10:02:03 +0100 From: Nils Thune Will a call to pfRemoveChild(scene, boat) not only remove the boat from the scene but also delete the boat? If the boat is to be removed and deleted should we call: pfRemoveChild(scene, boat); pfDelete(boat); - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Sun Dec 5 07:13:33 1993 Message-Id: <9312051513.AA26902@surreal.asd.sgi.com> To: Nils Thune Cc: info-performer@sgi.sgi.com Subject: Re: pfRemoveChild(...) In-Reply-To: Your message of "Sun, 05 Dec 93 10:02:03 +0100." <199312050902.AA06202@artemis.cmr.no> Date: Sun, 05 Dec 93 07:13:25 -0800 From: Jim Helman > If the boat is to be removed and deleted should we call: > > pfRemoveChild(scene, boat); > pfDelete(boat); Yes, but remember to create and delete nodes only in the application process. Also, pfDelete is not complete or MP safe in 1.0/1.1, but should work swimmingly in 1.2. If you do use it in 1.0/1.1, don't delete the boat for a few frames after you remove it just to make sure the back end draw process is done with all of it. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 9 07:49:38 1993 From: Kevin Russo Message-Id: <199312091549.PAA01685@midway> To: info-performer@sgi.sgi.com Subject: Cursor changes Status: OR I want my Performer1.1 app to be able to change the cursor shape in response to different modes in the simulation. As I understand it, since I'd have to use the GL cursor-routines (or X?) to do this, they can only be invoked in the draw proc. My question is what's the best way to handle changing the cursor shape? Should I make an empty node with a draw callback, where the node's draw traversal mask gets turned on only when I want to change cursors? Or is there a better way of handling this? Thanks for all suggestions. Kevin -- Kevin Russo russo@ait.nrl.navy.mil US Naval Research Lab Washington, DC From guest Wed Dec 15 12:03:04 1993 Date: Thu, 9 Dec 93 13:41:39 -0500 From: marrou@raider.vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9312091841.AA01728@raider.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: pfGetNodeBBox This topic has been touched upon before, but my problem is slightly different. I am using pfGetNodeBBox() on a particular vehicle model, trying to get the visual bounding box, and using the extremities for intersection testing and terrain clamping. However, the bounding box seems to be slightly different than actual. That is, the vehicle goes up a hill before it gets there! Can someone give me a quick hint? Here is the hierarchy, if it makes any difference: DCS: 0 Id: 918 Group: (null) Id: 8 DCS: TopMvmt Id: 873 Geode: (null) Id: 879 GeoSet: 0x143d85f0 GeoState: 0143d61c0 End GeoSet End Geode: 879 Geode: (null) Id: 885 GeoSet: 0x143db060 GeoState: 0143d61c0 End GeoSet End Geode: 885 DCS: Fulcrum Id: 875 Geode: (null) Id: 884 GeoSet: 0x143bb140 GeoState: 0143d61c0 End GeoSet End Geode: 884 DCS: TonCyl Id: 871 Geode: (null) Id: 877 GeoSet: 0x143baf10 GeoState: 0143d61c0 End GeoSet End Geode: 877 DCS: Bridge Id: 869 Geode: (null) Id: 880 GeoSet: 0x143d7210 GeoState: 0143d61c0 End GeoSet End Geode: 880 DCS: Scissor Id: 867 Geode: (null) Id: 887 GeoSet: 0x143d6230 GeoState: 0143d61c0 End GeoSet End Geode: 887 End DCS: 867 End DCS: 869 End DCS: 871 End DCS: 875 End DCS: 873 End Group: 8 End DCS: 918 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lance R. Marrou -- IST Visual Systems Lab -- E-mail: marrou@ist.ucf.edu From guest Fri Dec 10 04:25:51 1993 Message-Id: <9312101225.AA13570@ifr1.Luftfahrt.Uni-Stuttgart.DE> Date: Fri, 10 Dec 93 13:25:41 +0100 From: michael@ifr.luftfahrt.uni-stuttgart.de To: info-performer@sgi.sgi.com Subject: Wrong transformation for static coordinate systems in Performer 1.2 We recently installed the beta version of Performer 1.2 on our Indigo R4000 running 4.0.5F. When I tried to get an application running that I had developed with Performer 1.0 I experienced a severe problem. When I place an object into the scene with an SCS the object appears at an entirely wrong location. I found out that this only happens if the rotational part of the transformation is almost zero and the translation is not. If I specify an additional rotation of something like 0.01 deg the translational transformation will be ok. Is this a bug ? If yes is it already known ? I have provided a small code fragment that shows what I am doing. --- code fragment starts here ----------------- void init_stat_grid_3d(int index, Position* Pos, Rotation* Rot, int nx, int ny, int nz, float dx, float dy, float dz, float line_width, float red, float green, float blue, int *status) BEGIN pfGeode *geode; pfMatrix matrix; pfCoord coord; *status = OK; pfSetVec3(coord.xyz, Pos->x, Pos->y, Pos->z); pfSetVec3(coord.hpr, Rot->h, Rot->p, Rot->r); pfMakeCoordMat(matrix, &coord); StatObjTrans[index].earth_offset = pfNewSCS(matrix); /* load the database */ geode = grid_3d(nx,ny,nz,dx,dy,dz,line_width,red,green,blue); IF (geode != NULL) THEN pfAddChild(StatObjTrans[index].earth_offset, geode); ELSE *status = INITIALIZATION_ERROR; ENDIF IF (*status EQ OK) THEN pfAddChild(Scene, StatObjTrans[index].earth_offset); ENDIF return; END |----------------------------------------------------------------------| |Dipl.-Ing. Michael Paus | |University of Stuttgart, Inst. of Flight Mechanics and Flight Control | |Forststrasse 86, 70176 Stuttgart, Germany | |----------------------------------------------------------------------| |Phone: (+49) 711-121-1434 FAX: (+49) 711-634856 | |Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)| |----------------------------------------------------------------------| From aschaffe Fri Dec 10 21:12:41 1993 From: aschaffe (Allan Schaffer) Message-Id: <9312102112.ZM12772@holodeck.asd.sgi.com> Date: Fri, 10 Dec 1993 21:12:40 -0800 In-Reply-To: Kevin Russo "Cursor changes" (Dec 9, 3:49pm) References: <199312091549.PAA01685@midway> X-Mailer: Z-Mail (3.0B.1026 26oct93 MediaMail) To: Kevin Russo Subject: Re: Cursor changes Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Dec 9, 3:49pm, Kevin Russo wrote: > I want my Performer1.1 app to be able to change the cursor shape > in response to different modes in the simulation. As I understand > it, since I'd have to use the GL cursor-routines (or X?) to do this, > they can only be invoked in the draw proc. That's correct, you should only make direct GL calls (like defcursor, setcursor, etc in this case) from within the draw process. > My question is what's the best way to handle changing the cursor > shape? Should I make an empty node with a draw callback, where > the node's draw traversal mask gets turned on only when I want > to change cursors? Or is there a better way of handling this? Instead of using an empty node and worrying about traversal masks, ordering, etc. I would probably implement this by doing the call to defcursor() (to construct the new GL cursor) in a pipe-initialization callback, and then do the call to setcursor() in a channel-draw callback. See complex.c for an example of setting up the callbacks. Using complex.c as a base, you would add the defcursor() stuff in the OpenPipeline() function, and make calls to setcursor() from within DrawChannel(). Happy hacking, Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Mon Dec 13 06:10:09 1993 Date: Mon, 13 Dec 93 10:07:44 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9312131507.AA01423@ldsa.com> To: info-performer@sgi.sgi.com I am having a problem that I'm sure is goign to seem very basic judging from the level of questions I have seen here. I am running Performer 1.0 with a single processor Indigo2 Extreme as target platform. All my program does right now is load 2 flight format models, place them on the screen one above the other, and rotate them in opposite directions. When I run this program, (requesting 30hz) it has a very disturbing stutter. Viewing the stats, it appears to be switching between 30hz and something around 5hz. This is not consistant, and sometimes does not occur at all. Tech support suggested that I run as root, but this is not an option for me. I am going to doing much more ambitious displays with flight format models, and I want to get this resolved as soon as possible. One last detail. I am writing my code in ada with a set of bindings provided to me by Mr Embry at SGI. I expect that this is probably a common problem that some of you may have encountered, and solved. Thanks in advance. Mike Williams (mwilliam@ldsa.com) Loral Defense Systems - Akron From guest Mon Dec 13 07:25:15 1993 Message-Id: <9312131525.AA28858@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Mon, 13 Dec 93 10:07:44 EST." <9312131507.AA01423@ldsa.com> Date: Mon, 13 Dec 93 07:25:06 -0800 From: Jim Helman A single processor machine can't do realtime very well. But bouncing between 30Hz and 5Hz is absurd and running as root will not fix it (Performer sets non-degrading priorities, that's it). It could be anything from a gfx usage problem to a problem with ADA. Unfortunately, it's not a "common problem." And I don't see an easy path. Try to make it reproducible, i.e. steady 5Hz. And keep working with tech support. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 11:43:24 1993 Date: Mon, 13 Dec 93 15:41:13 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9312132041.AA01669@ldsa.com> To: info-performer@sgi.sgi.com Status: OR The pfChanPick command has a mode variable which id represented as a bitwise OR of five possible options. My header file only has a define for PFPK_M_ALL. Is this then my only option with Performer 1.0? I am going to use this command to allow the user to select flight format objects by clicking the mouse on them. Each model is loaded as a DCS node. What in the pfIsect structure is going to tell me what model was selected. I want to pass information ahead about what was chosen. I guess what I would expect is to have some unique identifier on each node as a add it to the scene. Then Performer could return this identifier to me to specify a particular node. That may be built in somewhere, but I don't see it. Thanx Mike Williams mwilliam@ldsa.com From guest Mon Dec 13 12:32:22 1993 Message-Id: <9312132032.AA29216@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Mon, 13 Dec 93 15:41:13 EST." <9312132041.AA01669@ldsa.com> Date: Mon, 13 Dec 93 12:32:15 -0800 From: Jim Helman Status: OR If you ware picking a single object, you probably just want the closest hit, which is the default if you do not OR PFPK_M_ALL into the mode. You can also OR in /* isect modes */ #define PFTRAV_IS_PRIM 0x01 /* report isects at poly level */ #define PFTRAV_IS_GSET 0x02 /* report isects at geosets */ #define PFTRAV_IS_GEODE 0x04 /* XXX - libpf report isects at geode nodes */ #define PFTRAV_IS_NORM 0x08 /* return normal */ #define PFTRAV_IS_CULL_BACK 0x10 /* ignore backfacing polygons */ #define PFTRAV_IS_CULL_FRONT 0x20 /* ignore frontfacing polygons */ 1.2 uniquely identifies the object intersected by a path through the scene graph. Unfortunately, 1.0/1.1 only provides the pfGeoSet. If your models are not instanced (i.e. the same subgraph or geoset does not exist under multiple DCSes) the pfGeoSet will provide a unique ID. If you need to retain instancing, you could switch to pfSegsIsectNode, use a preIntersection traversal callback on each DCS and a discriminator callback to log the current DCS. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 13 17:13:29 1993 From: "Wade Olsen" Message-Id: <9312131711.ZM29358@fnord.asd.sgi.com> Date: Mon, 13 Dec 1993 17:11:34 -0800 In-Reply-To: Kevin Russo "Cursor changes" (Dec 9, 3:49pm) References: <199312091549.PAA01685@midway> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: Kevin Russo , info-performer@sgi.sgi.com Subject: Re: Cursor changes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Dec 9, 3:49pm, Kevin Russo wrote: > Subject: Cursor changes > I want my Performer1.1 app to be able to change the cursor shape > in response to different modes in the simulation. As I understand > it, since I'd have to use the GL cursor-routines (or X?) to do this, > they can only be invoked in the draw proc. > > My question is what's the best way to handle changing the cursor > shape? Should I make an empty node with a draw callback, where > the node's draw traversal mask gets turned on only when I want > to change cursors? Or is there a better way of handling this? > >-- End of excerpt from Kevin Russo I think a better way would be to place a structure in shared memory containing all such info (e.g. wireframe mode, disable texturing, cursor shape). This structure should be allocated before pfConfig (i.e. before performer forks draw and cull processes) so all processes have a pointer to it. The structure could also contain a counter that was incremented after any data was changed. Then in the channel draw callback a local static counter can be compared to see if something has changed. Another option that I prefer is a little more complicated and addresses the issue of GUI's in a different way. I have a Motif/Performer example where the application process opens a window, creates the user interface, and handles all events. The tricky part is some GLX code that allows the app process to disconnect from the GLX widget and allow the draw process to connect to it. This example works with performer 1.1 but should be easy to port to 1.2. Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From aschaffe Tue Dec 14 18:20:07 1993 From: aschaffe (Allan Schaffer) Message-Id: <9312141820.ZM24236@holodeck.asd.sgi.com> Date: Tue, 14 Dec 1993 18:20:07 -0800 In-Reply-To: Jim Helman "" (Dec 13, 12:32pm) References: <9312132032.AA29216@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.0B.1026 26oct93 MediaMail) To: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Dec 13, 12:32pm, Jim Helman wrote: > > If you ware picking a single object, you probably just want the > closest hit, which is the default if you do not OR PFPK_M_ALL into > the mode. You can also OR in > > /* isect modes */ > #define PFTRAV_IS_PRIM 0x01 /* report isects at poly level */ > [...] Jim is correct. I would also add that there is a "bug" in 1.0, where PFPK_M_NEAREST (mentioned in the man page) isn't defined in pf.h It should be: #define PFPK_M_NEAREST 0 Since (foo | 0) equals foo, most people just ended up with PFPK_M_NEAREST anyways. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Tue Dec 14 18:30:21 1993 Date: Tue, 14 Dec 1993 21:29:45 -0500 From: William E Gerhard Message-Id: <199312150229.AA20926@stealth.afit.af.mil> To: info-performer Subject: unsubscribe From guest Tue Dec 14 21:40:46 1993 Date: Wed, 15 Dec 93 14:09:44 JST From: mizo@sgb.kobe.mhi.co.jp (Minori Mizoguchi) Return-Path: Message-Id: <9312150509.AA02007@sun4.sgb.kobe.mhi.co.jp> To: info-performer%sgi.com@kddlab.kddlabs.co.jp Subject: Performer 1.2 beta Reply-To: mizo@sgb.kobe.mhi.co.jp Is there any way we can get a beta version of Performer 1.2? Thanks, Minori Mizoguchi Mitsubishi Heavy Industries, Ltd. mizo@sgb.kobe.mhi.co.jp From aschaffe Tue Dec 14 22:03:48 1993 From: aschaffe (Allan Schaffer) Message-Id: <9312142203.ZM25539@holodeck.asd.sgi.com> Date: Tue, 14 Dec 1993 22:03:48 -0800 In-Reply-To: mizo@sgb.kobe.mhi.co.jp (Minori Mizoguchi) "Performer 1.2 beta" (Dec 15, 2:09pm) References: <9312150509.AA02007@sun4.sgb.kobe.mhi.co.jp> X-Mailer: Z-Mail (3.0B.1026 26oct93 MediaMail) To: mizo@sgb.kobe.mhi.co.jp Subject: Re: Performer 1.2 beta Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Dec 15, 2:09pm, Minori Mizoguchi wrote: > Is there any way we can get a beta version of Performer 1.2? The general answer is no; the beta sites are already well into the beta effort. Since we're not far from general (and well documented :-) ) release, you won't have to wait too long before 1.2. It's also a lot of work to support each site, so we like to keep the number small. As always, customers with unusual circumstances should get in touch with their marketing or sales contact. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Dec 15 08:36:30 1993 Message-Id: <9312151636.AA21725@sgi.sgi.com> Subject: IRIX 5.1 To: info-performer@sgi.sgi.com Date: Wed, 15 Dec 1993 17:35:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 656 From: Patrick Aschwanden Sender: paschwan@ifi.unizh.ch We got problems with the Performer 1.1 running on IRIX 5.1 . The Object-Files don't fit together. After compiling, we get following errors : /usr/bin/CC -ansi -D__EXTENSIONS__ -DREALITY -g -DDDBUG -I. -I/usr/include/Performer -I/usr/src/Performer/include -o complex4 complex4.o map.o mysgo.o env.o -L/usr/src/Performer/lib -L/usr/lib -L -L/f/paschwan/gnu/usr/local//usr/lib -lpf -lpr -lmpc -limage -lfm_s -lgl_s -lm -lfpe -lC -lc_s ld: Object file format error in: /usr/lib/libpf.a(pfProcess.o): cannot mix Elf and COFF objects. Any suggestions ?? Patrick Aschwanden paschwan@inf.ethz.ch Multi-Media-Lab, University of Zuerich From guest Wed Dec 15 08:55:49 1993 Date: Wed, 15 Dec 93 08:56:20 -0800 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9312151656.AA13211@bessie.cs.nps.navy.mil> To: Patrick Aschwanden , info-performer@sgi.sgi.com Subject: Re: IRIX 5.1 You can't mix files compiled on 4.0.5 and 5.X. As such you must recompile everything when you change operating systems. With the changes in the compiler, expect it to take an hour or two. The new compiler is stricter. Dave Dave Pratt pratt@cs.nps.navy.mil (408) 656-2865 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's. From guest Wed Dec 15 12:47:34 1993 Message-Id: <9312152047.AA21974@surreal.asd.sgi.com> To: marrou@raider.vsl.ist.ucf.edu (Lance Marrou) Cc: info-performer@sgi.sgi.com Subject: Re: pfGetNodeBBox In-Reply-To: Your message of "Thu, 09 Dec 93 13:41:39 EST." <9312091841.AA01728@raider.vsl.ist.ucf.edu> Date: Wed, 15 Dec 93 12:47:25 -0800 From: Jim Helman > That is, the vehicle goes up a hill before it gets there! Perhaps you are using pfNodeBSphere(node, sph, PFBMODE_PSYCHIC)? First, on nodes, you should use pfGetNodeBSphere(), not pfGetNodeBBox(), which is currently useless since it merely returns a bbox around the node's bsphere, i.e. you get a bounding cube! If you want a tight bound on the vehicle, you should apply pfuCalcBBox() once at db load time to the group under the DCS and then use the DCS matrix at frame time to transform the bounding box. If a looser bound is OK, forget pfuCalcBBox()*pfGetDCSMat() and use pfGetNodeBSphere() on the DCS. There's no way for Performer to anticipate where the vehicle will be. I suspect you are seeing something which you don't expect because of the box-around-sphere behavior. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 16 11:47:11 1993 X-Authentication-Warning: afrodite.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: afrodite.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: Precision in Performer... Date: Thu, 16 Dec 1993 20:46:09 +0100 From: Nils Thune I have some problems with unstable objects/views when the object position becomes rather large. As an example, if the position part of the object is P(556615.0013, 587501.1945, 10.0000), and the orientation part is O(47.5678, 0.0000, 0.0000) and the heading of the orientation part is incremented with a small delta angle each frame, then I get a very jerky image. The view matrix is usually a simple translation matrix. The view and/or object jumps around and does not seem to be fixed to each other. This is also true when the view matrix is the identity. for (;;) { ......... objPosDir.hpr[PF_H] += deltaAngle; // If the heading will never be > 360.0 ! pfDCSCoord(dcs, &objPosDir); // Position object pfMakeCoordMat(m2, &objPosDir); // Get object position pfMultMat(m1, viewMatrix, m2); // and add view offset pfChanViewMat(channel, m1); // and set the view. .......... } Now, if I scale the x and y part of the object position with 1/1000.0f then the jerkyness is gone. Is there something wrong with my eyes, should I set the view matrix in a different way, or is it Performer which can't handle such numbers? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Thu Dec 16 12:50:12 1993 Message-Id: <9312162048.AA11936@surreal.asd.sgi.com> To: Nils Thune Cc: info-performer@sgi.sgi.com Subject: Re: Precision in Performer... In-Reply-To: Your message of "Thu, 16 Dec 93 20:46:09 +0100." <199312161946.UAA04550@afrodite.cmr.no> Date: Thu, 16 Dec 93 12:48:37 -0800 From: Jim Helman I belive you are simply exceeding the limits of single precision floating point numbers. If your object is one unit large and you position the object at (x, y+1, z) and the eye point at (x, y, z) with x, y, z large enough so that in the FP representation (y+1) == y, then the position relative to the eye point (y+1)-y is going to suffer severe precision problems. Normally, single precision floating point should get you to around 1.0e7 before suffering one unit jerkiness, but it's plausible that intermediate calculations might cause a loss of precision earlier. One solution is to maintain double precision tile offsets, model the tiles near the origin and handle the translations yourself so that neither the DCS nor the ChanView translations get too large. Angles substantially outside the range of -360 to 360 can also cause problems, but you indicate your angles stay small. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Dec 16 16:34:26 1993 From: "Wade Olsen" Message-Id: <9312161633.ZM4081@fnord.asd.sgi.com> Date: Thu, 16 Dec 1993 16:33:27 -0800 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: A performer motif example Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 A few people have asked for the Performer/Motif example so here it is. The key point of this example is the application process handles all the x events for the GLX widget (and everything else). This was written for 1.0/1.1 so there will probably be a few changes to work with 1.2. To extract: save this message to a file. Run uudecode on it. Run "tar xvf " on the decoded tar file. Wade begin 644 performer_motif.tar M<&5R9F]R;65R7VUO=&EF+P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````#`P,#2P@ M=&AI2!I2!D;V5S('-O(&)Y(&]P96YI;F<@:71S"F]W;B!W:6YD;W&ES=&EN9R!'3%@@=VED9V5T(&-R96%T960@8GD@=&AE(&%P<&QI8V%T:6]N M"G!R;V-E2!S:6UP;&EF:65D+@H**B\*"B-I;F-L=61E(#QS=&1I;RYH M/@HC:6YC;'5D92`\7!E0H*"0D)"2\O(%1H:7,@R`B+6UP(BP@(BIM<%]M;V1E(BP@ M6')M;W!T:6]N4V5P07)G+"!.54Q,('TL"GT["@IS=&%T:6,@9FQO870@9&EA M;65T97(["0DO+R!$:6%M971E%]P;W,["0DO+R!# M=7)R96YT(&UO=7-E('!OF4["2\O($-UF4[ M"2\O('-H87)E9"!M96UOR!-3T1%7U=)4D5&4D%-12P@34]$15]415A455)%+"!.54U? M34]$15,@?3L*"G-T871I8R!S=')U8W0@9')A=U]M;V1E7W-TPH@("`@1TQ87TY/ M4DU!3"P@1TQ87T)51E-)6D4L("`)1TQ87TY/0T].1DE'+`H@("`@1TQ87TY/ M4DU!3"P@1TQ87UI325I%+"`@"4=,6%].3T-/3D9)1RP*("`@($=,6%].3U)- M04PL($=,6%]$3U5"3$4L"512544L"B`@("!'3%A?3D]234%,+"!'3%A?4D=" M+"`@(`E44E5%+`H@("`@1TQ87TY/4DU!3"P@1TQ87U=)3D1/5RP)1TQ87TY/ M3D4L"B`@("`P+"`P+"`P+`I].PH*"B\O($%N(%AT(&-A;&QB86-K(&9U;F-T M:6]N(&-A;&QE9"!W:&5N(&$@(F1R87<@;6]D92(@8G5T=&]N(&ES"B\O('1O M9V=L960N"@IS=&%T:6,@=F]I9"`*;6]D94-"*%=I9&=E="P@:6YT(&UO9&4L M(%AM5&]G9VQE0G5T=&]N0V%L;&)A8VM3=')U8W0@*B!C8BD*>PH@("`@9')A M=U]M;V1E2`](%A/<&5N1&ES<&QA>2AG;'A?:6YF;RT^9&ES<&QA>5]N86UE*3L* M("`@(%=I;F1O=R!G;'A?=VEN9&]W(#T@9VQX7VEN9F\M/GA7:6YD;W<["B`@ M("`*("`@(%A7:6YD;W=!='1R:6)U=&5S(&%T=')I8G5T97,["B`@("!81V5T M5VEN9&]W071TPH)("`@(&-O;F9I9UMI72YA%]W:6YD;W<[ M"@E]"@H)"0D)+R\@0V]N;F5C="!T:&4@1TP@8V]N=&5X="!T;R!T:&4*"0D) M"2\O($=,6'=I9&=E="!CPH@("`@PH@("`@("!I9B`H9')A=U]M;V1E'!O%]I;F9O"B\O('-T%]S:7IE M(#T@8V(M/G=I9'1H.PH)*G=I;E]Y7W-I>F4@/2!C8BT^:&5I9VAT.PH@("`@ M?0H*"0D)"2\O(%1H:7,@:&%P<&5NF5D+@H@("`@:68@*&-B+3YR96%S;VX@ M/3T@1VQX0U)?1TE.250I"B`@("!["@E$:7-P;&%Y("H@9&ES<&QA>2`](%AT M1&ES<&QA>2AW*3L*"5=I;F1O=R`@>%=I;F1O=R`](%AT5VEN9&]W*'2!S;R!D5]N86UE(#T@,#L*"6=L>%]I;F9O+3YX5VEN9&]W(#T@ M>%=I;F1O=SL*"@D)"0DO+R!296QE87-E(&5X8VQUPH) M=V]R:U]I9"`](%AT07!P061D5V]R:U!R;V,H87!P7V-O;G1E>'0L("A8=%=O M2D*("`@('L*"5AT4F5M M;W9E5V]R:U!R;V,H=V]R:U]I9"D["@H)"0D)+R\@268@=&AE2UW86ET M#L*("`@(&UO=7-E7WE?<&]S(#T@979E;G0M/GAB=71T;VXN M>3L*?0H*+R\@5&AIFEM+"`F87II;5]S:6XL("9A M>FEM7V-OFEM7W-I;B`J(&EN8VQ?8V]S.PH@("`@=FEE=U]P M;W-;,5T@/2!V:65W7V-E;G1EFEM7V-O MFEM.PH@("`@=FEE=U]D:7);,5T@/2!V:65W7VEN8VP["B`@ M("!V:65W7V1IPH@("`@:6YT(&YE M=U]X(#T@979E;G0M/GAM;W1I;VXN>#L*("`@(&EN="!N97=?>2`](&5V96YT M+3YX;6]T:6]N+GD["@H@("`@9FQO870@9'@@/2`H9FQO870I*&YE=U]X("T@ M;6]U%]P;W,I.PH@("`@9FQO870@9'D@/2`H9FQO870I*&YE=U]Y("T@ M;6]U5]P;W,I.PH*("`@(&UO=7-E7WA?<&]S(#T@;F5W7W@["B`@("!M M;W5S95]Y7W!O2X*("`@(&EF("A"=71T;VXQ M36%S:R`F(&5V96YT+3YX;6]T:6]N+G-T871E*0H@("`@>PH)9&ES=&%N8V4@ M*ST@+2AF86)S*&1I2`O(#$P,"XP*3L* M("`@('T*"@D)"0DO+R!2;W1A=&4@=&AE('9I97=E&UO M=&EO;BYS=&%T92D*("`@('L*"79I97=?87II;2`M/2!D>"`O(#(N,#L*"79I M97=?:6YC;"`M/2!D>2`O(#(N,#L*("`@('T*"@D)"0DO+R!4PH)9FQO870@9F]V7W@L(&9O=E]Y.PH)<&9'971# M:&%N1D]6*'1H94-H86YN96PL("9F;W9?>"P@)F9O=E]Y*3L*"@EF;&]A="!A M>FEM7W-I;BP@87II;5]C;W,["@EF;&]A="!I;F-L7W-I;BP@:6YC;%]C;W,[ M"@EP9E-I;D-OFEM7W-I;BP@)F%Z:6U?8V]S*3L* M"7!F4VEN0V]S*'9I97=?:6YC;"P@)FEN8VQ?"P@)GA?9G5D9V4L("9J=6YK*3L*"7!F4VEN0V]S*&9O=E]Y+"`F>5]F=61G M92P@)FIU;FLI.PH)>%]F=61G92`O/2`J=VEN7WA?F4["@H)=FEE=U]C96YT97);,%T@+3T*"2`@("`H87II M;5]C;W,@*B!D>"`J('A?9G5D9V4@*R!A>FEM7W-I;B`J("@M:6YC;%]S:6XI M("H@9'D@*B!Y7V9U9&=E*0H)"2H@9&ES=&%N8V4["@EV:65W7V-E;G1EFEM7W-I;B`J(&1X("H@>%]F=61G92`K(&%Z:6U?8V]S M("H@:6YC;%]S:6X@*B!D>2`J('E?9G5D9V4I"@D)*B!D:7-T86YC93L*"79I M97=?8V5N=&5R6S)=("T]"@D@("`@*"UI;F-L7V-O2`J(&1I5]F=61G93L*("`@('T*"B`@("!A9&IUF4H)B!A<'!?8V]N=&5X="P@(E!F36]T:68B+`H)"0D)(&]P=&EO M;G,L(%AT3G5M8F5R*&]P=&EO;G,I+`H)"0D)("9A4QE=F5L*%!&3D997U=!4DXI.PH@ M("`@=F]I9"`J(&%R96YA(#T@<&9'9713:&%R961!2!A%]I;F9O7W-TF5O9BAD$YG M:6YI=$-A;&QB86-K+`H)"2`@*%AT0V%L;&)A8VM0$YR97-I>F5#86QL8F%C:RP* M"0D@("A8=$-A;&QB86-K4')O8RER961R87=#0BP@,"D["B`@("!8=$%D9$5V M96YT2&%N9&QE"!B;W5N9#L*("`@('!F1V5T M3F]D94)";W@H9&%T82P@)B!B;W5N9"P@,"D["B`@("!P9E9E8S,@"D["B`@("!P9E-U8E9E8S,HF5;,ETI.PH@("`@9&ES=&%N8V4@ M/2!D:6%M971E2!F2D*>PH@("`@*G@@/2`P.PH@("`@*GD@/2`P.PI]"@IE>'1E"P@;&]N9R`J('DI"GL*("`@("IX(#T@ M*G=I;E]X7W-I>F4["B`@("`J>2`]("IW:6Y?>5]S:7IE.PI]"FEN*#0U+C`@ M+R`R("H@35]022`O(#$X,"DI.PH*("`@('!F0VAA;DYE87)&87(H=&AE0VAA M;FYE;"P@9&EA;65T97(@+R`Q,"XP+"!D:6%M971E Message-Id: <9312172121.AA06183@swlrgk> To: info-performer@sgi.sgi.com Status: OR Will IRIS Performer 1.2 make stereo easier" or "automatic"? Since stereo is usually rendered in 2 separate windows, will Performer allow a straight-forward way to update these windows? Will it use specific parameters, such as offsetting objects within the scene using pitch, roll, and yaw, to cause the stereo effects? Also - I am using StereoGraphics stereo glasses. Thank you, Stephen Joyce Raytheon Co. From guest Tue Dec 21 09:09:20 1993 From: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Message-Id: <9312211806.ZM7291@shark.paris.sgi.com> Date: Tue, 21 Dec 1993 18:06:21 +0100 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Cc: norbert@shark.paris.sgi.com Subject: Intersection beetwen bbox and nodes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi all, I have a simple question for all of us : How can i determine intersection between BBox and nodes or geoset ? In fact my question is more complex, i need to simulate a bomb explosion and i want to determine all objects that are affected by this explosion. Of course explosion area is a sphere. Any idea ? Thanks for your help. Norbert. -- +----------------------------------------------------------------+ | NN NN BBBBBB Country ID : IFR-340 | | NNN NN BB BB SGI Office Location : PARIS | | NNNN NN BBBBBB Name : Norbert BIANCHIN | | NN NNNN BB BB | | NN NNN BB BB E-mail Address : norbert@paris.sgi.com | | NN NN BBBBBB Fax Number : 33 1 34 88 80 76 | +----------------------------------------------------------------+ From guest Tue Dec 21 09:51:33 1993 Message-Id: <9312211751.AA23000@surreal.asd.sgi.com> To: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Cc: info-performer@sgi.sgi.com Subject: Re: Intersection beetwen bbox and nodes In-Reply-To: Your message of "Tue, 21 Dec 93 18:06:21 +0100." <9312211806.ZM7291@shark.paris.sgi.com> Date: Tue, 21 Dec 93 09:51:20 -0800 From: Jim Helman Determining all objects which are in or impinge upon a sphere is really a volume-volume intersection problem. You could create a spherical bristle of segments, but it would take a lot of them, probably too many, to give good coverage. Volume-volume intersections are on the list of things for a future release. However, since all the bounding and transform information is accessible, a user could always traverse the scene graph yourself and carry out the tests. If this is too much work, you can narrow things down quite a bit by using a bounding cylinder in pfSegsIsectNode() without any segments and specify a discriminator callback and PFTRAV_IS_GEODE in the mdoe. This will give you callbacks on all the pfGeodes whose bounding spheres potentially intersect the querying bounding cylinder. You could then test the pfGeoSets in the pfGeode more easily since you have the transformation in the pfIsect (pfHit in 1.2) structure handed to your discriminator. Then test the explosion sphere aginst the bounding box transformed by pfXformBox(). Currently, bounding cylinder testing is implemented only down to pfGeodes, but getting it down to the pfGeoSet level is currently has been mentioned as a must fix for 1.2. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From seppo@vision3d.helsinki.sgi.com Wed Dec 22 08:37:43 1993 From: "Seppo_Jarimo" Message-Id: <9312221835.ZM25975@vision3d.helsinki.sgi.com> Date: Wed, 22 Dec 1993 18:35:14 +0200 X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer Fatal (9): Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, Is this a known bug in Performer 1.1 ?: When trying to run Town or Village demo in an Onyx with 2GB memory and several GB's swap, one gets a message: Performer Fatal (9):pfInit: not enough space in swap, need 4096KB plus headroom, only found -2015150080KB Notice the "-" sign in front of the found swap space. Thanks, - Seppo Jarimo -- seppo@sgi.fi or seppo@helsinki.sgi.com Silicon Graphics Oy Tel: +358-0-4354 2071 Innopoli, Tekniikantie 12 Fax: +358-0-4354 3200 SF-02150 ESPOO SGI-mailstop: IFI-361 Finland From seppo@vision3d.helsinki.sgi.com Thu Dec 23 03:13:49 1993 From: "Seppo_Jarimo" Message-Id: <9312231316.ZM791@vision3d.helsinki.sgi.com> Date: Thu, 23 Dec 1993 13:16:45 +0200 In-Reply-To: Jim Helman "Re: Performer Fatal (9):" (Dec 22, 11:03am) References: <9312221903.AA01453@surreal.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: jimh@surreal Subject: Re: Performer Fatal (9): Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Jim, Thanks for your quick response. PFTMPDIR had nothing to do with it, but deleting the third swap file seen in the swap -l list below helped. So it is a kind of counter overflow type of bug. Merry Christmas, - Seppo Jarimo cypress 1% /etc/swap -l lswap path dev pri swaplo blocks free maxswap vswap 2 /var/tmp/.swap.virtual 128,278 2 0 0 0 0 80000 1 /dev/swap 128,273 0 0 524288 524288 524288 524288 3 /dev/dsk/dks4d4s1 128,1089 0 0 3928480 3928480 3928480 3928480 cypress 2% On Dec 22, 11:03am, Jim Helman wrote: > Subject: Re: Performer Fatal (9): > You should be able to run the town demo by setting PFTMPDIR > to /usr/tmp (or another temporary directory with 20-30MB > free). > > If the 2GB machine is being used for real Performer > development, I'd suggest getting Performer 1.2 as soon as > it's released. Or 1.2a72 if the user is SGI internal or a > customer you closely support. More test coverage on huge > machines would be nice. > > We don't have one that big, and as far as I know 1.1 was > never tested on a large system. Your message probably > indicates that a long is wrapping and the space allocation > is getting confused. Can you send the output of 'swap -l'? > > > rgds, > > -jim helman > > jimh@surreal.asd.sgi.com > 415/390-1151 > >-- End of excerpt from Jim Helman -- seppo@sgi.fi or seppo@helsinki.sgi.com Silicon Graphics Oy Tel: +358-0-4354 2071 Innopoli, Tekniikantie 12 Fax: +358-0-4354 3200 SF-02150 ESPOO SGI-mailstop: IFI-361 Finland From aschaffe Thu Dec 23 10:59:14 1993 Date: Thu, 23 Dec 93 10:59:14 -0800 From: aschaffe (Allan Schaffer) Message-Id: <9312231859.AA07806@holodeck.asd.sgi.com> To: info-performer Subject: Administrivia: Gone Fishin' Hello info-performer subscribers, Happy Holidays from the IRIS Performer group! I'll be out until January 4th and only occasionally checking email, so messages sent to info-performer-request may not be handled at the usual 30Hz. In my absence, the indomitable Jim Helman will keep an eye out for urgent administrative requests. You'll all be happy to know that a few of my new year's resolutions are to.. - update the Performer FAQ list again - make archives of info-performer available via ftp and of course, - write some more code samples for Performer 1.2 Happy hacking, Allan ---- Allan Schaffer Silicon Graphics aschaffe@sgi.com From jimh@surreal Thu Dec 23 11:19:19 1993 Message-Id: <9312231919.AA09953@surreal.asd.sgi.com> To: "Seppo_Jarimo" Cc: info-performer@sgi.sgi.com Subject: Re: Performer Fatal (9): In-Reply-To: Your message of "Thu, 23 Dec 93 13:16:45 +0200." <9312231316.ZM791@vision3d.helsinki.sgi.com> Date: Thu, 23 Dec 93 11:19:07 -0800 From: Jim Helman The problem was probably more than 2GB of swap. Either decreasing swap below 2GB or setting PFTMPDIR (which bypasses the entire swap allocation issue) should fix it under 1.1. The entire problem was created when IRIX 5.0 went to a strict memory reservation system which reserves sufficient swap even for unused portions of mmaps. Performer currently needs a single contiguous memory allocation. Usually, people who bought 1-2GB systems for Performer want to use as much as possible of it as shared memory, but we also don't want to completely lock out other programs. Hence the take half of everything compromise in 1.1. With 1.2 (release version, not in the betas) under IRIX 5.2 the problem goes away, because we're back to allocation on demand without reservation of the original mmap (MAP_AUTORESRV to mmap). 1.2 also has a routine pfSharedArenaSize to explicitly specify the desired size of the Performer shared memory mmap, but with of the AUTORESRV fix to IRIX, this shouldn't be required except on pre-5.2 systems or beta versions of 1.2. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Dec 27 07:39:25 1993 id AA18498; Mon, 27 Dec 93 10:38:31 -0500 Date: Mon, 27 Dec 93 10:38:29 -0500 From: bfl@cs.duke.edu (Brian Loss) Message-Id: <9312271538.AA15926@majors7.cs.duke.edu> To: info-performer@sgi.sgi.com Subject: Problem with GL calls in Performer 1.2 I am porting an application from Performer 1.0 to Performer 1.2 and have run into a slight problem. There is some code which draws a title screen which includes a title and a status bar indicating how much of a load has been completed. My problem is that the status bar does not show up properly. I draw it by drawing a closed line and then a rectangle. The code to draw the closed line works, but the code to draw the rectangle does not. Has anyone encountered such a problem. Here is some code: TPerfApp::DoTitle( const char *str, float status_bar ) { Matrix m; int xo, yo, xs, ys, nidX, midY; Boolean zstatus; float v[2]; // Figure out the center of the window pfGetPipeOrigin( fPipe, (long *) &xo, (long *) &yo ); pfGetPipeSize( fPipe, (long *) &xs, (long *) &ys ); midX = (xs / 2) + xo; midY = (ys / 2) + yo; // Save the projection and viewing matrices zstatus = getzbuffer( ); zbuffer( FALSE ); mmode( MPROJECTION ); getmatrix( m ); ortho2( xo, xs, yo, ys ); mmode( MVIEWING ); pfPushIdentMatrix( ); cpack( TTLBKGD ); clear( ); cpack( TTLFRGD ); fFonti24->Center( /* Print Title here */, midY + 200, midX ); ); if (str) fFonti24->Center( str, midY - 180, midX ); if (status_bar >= 0.0f) { cpack( 0xff0000ff ); v[0] = 425.0f; v[1] = 150.0f; bgnclosedline( ); v2f( v ); v[1] += 25.0f; v2f( v ); v[0] += 425.0f; v2f( v) ; v[1] -= 25.0f; v2f( v ); endclosedline( ); v[0] = 425.0f; v[1] = 150.0f; bgnpolygon( ); v2f( v ); v[1] += 25.0f; v2f( v ); v[0] += status_bar*425.0f; v2f( v ); v[1] -= 25.0f; v2f( v ); endpolygon( ); } swapbuffers( ); // Restore old projection and viewing matrices pfPopMatrix( ); mmode( MPROJECTION ); loadmatrix( m ); mmode( MVIEWING ); zbuffer( zstatus ); } // end DoTitle So, the code for the title and closed line work fine, but the code for the polygon does not work. I'm confused. I also tried a tmesh instead of a polygon and that didn't work either. Any help on this would be appreciated. aTdHvAaNnKcSe. Brian Loss _________________________________________________________________ Department of Computer Science, Duke University, Durham, NC 27706 Internet: bfl@cs.duke.edu UUCP: mcnc!duke!bfl _________________________________________________________________ From guest Tue Dec 28 06:22:49 1993 From: fouts@exacto.atlanta.sgi.com (Christopher Fouts) Message-Id: <9312280924.ZM866@exacto.atlanta.sgi.com> Date: Tue, 28 Dec 1993 09:24:20 -0500 In-Reply-To: bfl@cs.duke.edu (Brian Loss) "Problem with GL calls in Performer 1.2" (Dec 27, 10:38am) References: <9312271538.AA15926@majors7.cs.duke.edu> X-Face: YhB-P`"=w`PpC"Q\U50c{z,f1=9dickD?tmOz_y7x6ah0"98IIE9`Gs~)vRkgY8r^E*yXza*yz"zNNj_o7S)^E{7gO!dD Subject: Problem with GL calls in Performer 1.2 | | v[0] = 425.0f; v[1] = 150.0f; | bgnpolygon( ); | v2f( v ); v[1] += 25.0f; | v2f( v ); v[0] += status_bar*425.0f; | v2f( v ); v[1] -= 25.0f; | v2f( v ); | endpolygon( ); | } This polygon is backfaced. Try calling backface(FALSE) or reversing the order of the vertices. Evidently the GL initialization changed in 1.2 for I experienced a similar problem. -- Chris Fouts Email: fouts@atlanta.sgi.com Systems Engineer Phone: (404)-392-1333 Silicon Graphics Computer Systems Vmail: 5-8714 Atlanta, GA "What you see is real. What you smell is unfortunate." Tom Servo, Mystery Science Theatre 3000 From guest Tue Dec 28 08:18:21 1993 Date: Tue, 28 Dec 93 08:17:56 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9312281617.AA25792@tubes.asd.sgi.com> To: fouts@exacto.atlanta.sgi.com (Christopher Fouts), info-performer@sgi.sgi.com, bfl@cs.duke.edu (Brian Loss) Subject: Re: Problem with GL calls in Performer 1.2 References: <9312271538.AA15926@majors7.cs.duke.edu> >Evidently the GL initialization changed in 1.2 This is correct. We decided to go for speed at all costs since backface elimination can make a big difference. From guest Tue Dec 28 10:14:40 1993 id AA11270; Tue, 28 Dec 93 13:18:06 -0500 Date: Tue, 28 Dec 93 13:18:05 -0500 From: bfl@cs.duke.edu (Brian Loss) Message-Id: <9312281818.AA16435@majors7.cs.duke.edu> To: info-performer@sgi.sgi.com Subject: Re: Problem with GL calls in Performer 1.2 > From fouts@exacto.atlanta.sgi.com Tue Dec 28 09:23:37 1993 > Content-Type: text/plain; charset=us-ascii > Mime-Version: 1.0 > > Subject: Problem with GL calls in Performer 1.2 > | > | v[0] = 425.0f; v[1] = 150.0f; > | bgnpolygon( ); > | v2f( v ); v[1] += 25.0f; > | v2f( v ); v[0] += status_bar*425.0f; > | v2f( v ); v[1] -= 25.0f; > | v2f( v ); > | endpolygon( ); > | } > > This polygon is backfaced. Try calling backface(FALSE) or reversing the > order of the vertices. Evidently the GL initialization changed in 1.2 for > I experienced a similar problem. > > > -- > > Chris Fouts Email: fouts@atlanta.sgi.com > Systems Engineer Phone: (404)-392-1333 > Silicon Graphics Computer Systems Vmail: 5-8714 > Atlanta, GA > > "What you see is real. What you smell is unfortunate." > > Tom Servo, Mystery Science Theatre 3000 > > > > I totally missed that. Thanks. However, in my program's initizaliation, I make the following calls: pfCullFace( PFCF_OFF ); pfOverride( PFSTATE_CULLFACE, PF_ON ); and they did not seem to solve the problem (I don't call pfOverride with PFSTATE_CULLFACE again). However, when I made the vertices of my polygon in counterclockwise order, it shows up. Am I using pfOverride incorrectly? Brian Loss _________________________________________________________________ Department of Computer Science, Duke University, Durham, NC 27706 Internet: bfl@cs.duke.edu UUCP: mcnc!duke!bfl _________________________________________________________________ From guest Tue Dec 28 10:57:01 1993 Date: Tue, 28 Dec 93 10:56:00 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9312281856.AA26017@tubes.asd.sgi.com> To: bfl@cs.duke.edu (Brian Loss), info-performer@sgi.sgi.com Subject: Re: Problem with GL calls in Performer 1.2 >I totally missed that. Thanks. However, in my program's initizaliation, I >make the following calls: > > pfCullFace( PFCF_OFF ); > pfOverride( PFSTATE_CULLFACE, PF_ON ); > >and they did not seem to solve the problem (I don't call pfOverride with >PFSTATE_CULLFACE again). However, when I made the vertices of my polygon in >counterclockwise order, it shows up. Am I using pfOverride incorrectly? > This is the correct usage of pfOverride and should definitely work. Are you calling this in your pipe initialization function (pfInitPipe)? How about a code fragment or a gldebug trace? From guest Mon Jan 3 08:09:49 1994 id AA00987; Mon, 3 Jan 1994 15:01:00 +0300 Date: Mon, 3 Jan 1994 15:01:00 +0300 From: fperez@inisel.es (Francisco Perez Zarza) Message-Id: <9401031201.AA00987@inisel.es> To: info-performer@eunet.es Subject: PERFORMER information Dear Sir: We are interested about PERFORMER Product. Please, could you send us, information or FTP site about this? Our address: Francisco PEREZ ZARZA Sistemas Control Trafico Aereo CESELSA-INISEL, S.A. Ctra. de Loeches, 9. 28850 Torrejon de Ardoz MADRID SPAIN tel: 34-1-396 82 47 E-mail: fperez@inisel.es Thank you in advance. From guest Thu Jan 6 10:01:36 1994 Date: Thu, 6 Jan 94 09:57:30 PST From: lem@cod.nosc.mil (Lemuel L. Davis) Message-Id: <9401061757.AA15192@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Performer class(es)? I recently asked our local sales rep about the availability of Performer related classes from SGI. I was told that there are not currently any available. Is that true? Lem Davis lem@nosc.mil From guest Thu Jan 6 11:26:22 1994 Date: Thu, 6 Jan 94 11:25:44 -0800 From: mars@clubted.csd.sgi.com (David Marsland) Message-Id: <9401061925.AA28955@clubted.csd.sgi.com> To: lem@cod.nosc.mil (Lemuel L. Davis), info-performer@sgi.sgi.com Subject: Re: Performer class(es)? Cc: teched@clubted.csd.sgi.com An IRIS Performer class will be taught on Wednesday, Jan 19th at the SGI Expo East near Washington, DC. The class will be taught by David Marsland, a course developer from SGI Technical Education. The SGI Expo is being sponsored by PCI, and all inquiries and registration should go to PCI at 1-800-727-EXPO. Look for a course offered through SGI Technical Education in mid-94. Here's some more information: IRIS Performer 1.2 Class Outline Length: 1 day Target Audience: Developers, programmers, and project managers of visual simulation applications or other 3D graphics intensive applications Class Description: This class provides a fast-paced high-level overview of IRIS Performer 1.2. Demonstrations, lecture, and code examples will be used to cover the major features of Performer. Pre-requisites: Comfortable programming in C General 3D graphics visual simulation and GL background helpful Intro Performer Demos Overview Visual Simulation Application Requirements Loading Scene Databases from many file formats Performer visual simulation development environment - libpf Performer rendering library - libpr Performer Utilities Scene Graphs - Visual Database Hierarchy Traversal States Nodes Using the database Culling Drawing Intersections Visual Simulation Application Framework Initializing Loading Scene databases Setting up a Rendering Pipe Setting up a Channel - a view into a pipe Multiprocessing Simulation Loop Shared Memory Frame Rate Control Level of Detail Control Load Management Special Effects Earth/Sky Performer Rendering Library - libpr Overvie Geometry Graphics State System tasks Intersections Math Routines Performance tuning Graphics and System Utilization Statistics Database structuring /* David Marsland (415) 390-5326 "On Spaceship Earth * * MTS, Educational R&D, Graphics Programming there are no passengers, * * Silicon Graphics Computer Systems only crew." * * Internet: mars@csd.sgi.com Buckminster Fuller */ From guest Thu Jan 6 11:39:06 1994 From: "Bill Mannel" Message-Id: <9401061138.ZM16247@vaquero.csd.sgi.com> Date: Thu, 6 Jan 1994 11:38:55 -0800 In-Reply-To: mars@clubted (David Marsland) "Re: Performer class(es)?" (Jan 6, 11:25am) References: <9401061925.AA28955@clubted.csd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: mars@clubted.csd.sgi.com (David Marsland), lem@cod.nosc.mil (Lemuel L. Davis), info-performer@sgi.sgi.com Subject: Re: Performer class(es)? Cc: teched@clubted.csd.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 6, 11:25am, David Marsland wrote: > Subject: Re: Performer class(es)? > > An IRIS Performer class will be taught on Wednesday, Jan 19th at the > SGI Expo East near Washington, DC. The class will be taught by David > Marsland, a course developer from SGI Technical Education. The SGI Expo > is being sponsored by PCI, and all inquiries and registration should go > to PCI at 1-800-727-EXPO. should be Tuesday, Jan 18 ^^^^^ ;-) > > Look for a course offered through SGI Technical Education in mid-94. > > Here's some more information: > > IRIS Performer 1.2 Class Outline > > Length: 1 day > Target Audience: Developers, programmers, and project managers of > visual simulation applications or other 3D graphics intensive > applications > > Class Description: This class provides a fast-paced high-level overview > of IRIS Performer 1.2. Demonstrations, lecture, and code > examples will be used to cover the major features of Performer. > > Pre-requisites: Comfortable programming in C > General 3D graphics visual simulation and GL background helpful > > Intro > > Performer Demos > > Overview > Visual Simulation Application Requirements > Loading Scene Databases from many file formats > Performer visual simulation development environment - libpf > Performer rendering library - libpr > Performer Utilities > > Scene Graphs - Visual Database > Hierarchy > Traversal > States > Nodes > > Using the database > Culling > Drawing > Intersections > > Visual Simulation Application Framework > Initializing > Loading Scene databases > Setting up a Rendering Pipe > Setting up a Channel - a view into a pipe > Multiprocessing > Simulation Loop > Shared Memory > > Frame Rate Control > Level of Detail Control > Load Management > > Special Effects > Earth/Sky > > Performer Rendering Library - libpr > Overvie > Geometry > Graphics State > System tasks > Intersections > Math Routines > > Performance tuning > Graphics and System Utilization Statistics > Database structuring > > > /* David Marsland (415) 390-5326 "On Spaceship Earth * > * MTS, Educational R&D, Graphics Programming there are no passengers, * > * Silicon Graphics Computer Systems only crew." * > * Internet: mars@csd.sgi.com Buckminster Fuller */ >-- End of excerpt from David Marsland From guest Thu Jan 6 14:12:57 1994 Date: Thu, 6 Jan 94 14:14:09 -0800 From: goetzjr@gravy5.cs.nps.navy.mil (john goetz) Message-Id: <9401062214.AA05372@gravy5.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: Multiprocess Problem Status: OR I am working on a Performer loader which will work on a locally developed graphics language. I am using the Performer complex.c code and substituted my loader for the flt loader. When I initialize Performer and set pfMultiprocess(PFMP_APPCULLDRAW) the program runs fine. When I set pfMultiprocess(PFMP_DEFAULT) the program runs but my loaded image doesn't show up. I am running the program on a 4D/440 Reality Engine. If anyone can point me in a direction to find the error of my ways it would be greatly appreciated. John Goetz goetzjr@cs.nps.navy.mil From guest Thu Jan 6 16:48:02 1994 Message-Id: <9401070047.AA06258@surreal.asd.sgi.com> To: goetzjr@gravy5.cs.nps.navy.mil (john goetz) Cc: info-performer@sgi.sgi.com Subject: Re: Multiprocess Problem In-Reply-To: Your message of "Thu, 06 Jan 94 14:14:09 PST." <9401062214.AA05372@gravy5.cs.nps.navy.mil> Date: Thu, 06 Jan 94 16:47:53 -0800 From: Jim Helman Problems with multiprocessed pipeline configurations vs. APPCULLDRAW (one process) are usually caused by application code which was written without paying attention to multiprocessing issues. The first thing to check is that your loader is creating everything in shared memory. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Jan 7 01:32:38 1994 Message-Id: <9401070931.ZM14006@unknown.zmail.host> Date: Fri, 7 Jan 1994 09:31:46 +0000 In-Reply-To: "Re: Performer problem" (Dec 8, 11:40am) References: g<755350832WedGMT@gallery> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Performer problem Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 > > Hi > > Perhaps someone could help me with this > > There follows a description of my problem. > > I am using a Polhemus device, giving me xyz and azimuth, > elevation, and roll, to navigate around a virtual space. > I use the xyz as input to the pfChanView function, to set my > viewer position, and then use the azimuth elevation and roll (azr) > as input to pfChanViewOffsets, to supply me with viewer orientation. > I have a simple test object, which is a rectangular 3d object, with the top > coloured blue, the front green, and the rest white. The colour coding is to > ensure that I have a reference for navigation in the virtual world. So, a >typical test I > have done is to rotate the tracker around the x axis, which gives me my object > rotating the other way (as you might expect), with rotation going through all 360 degrees, > as I would have expected. Now, I decided to use the Performer earth sky model. I > find that it has several funny effects. First, it seems to rotate at about twice > the rate as the viewpoint (as referenced by my reference 3D object). Secondly, it seems > to sometimes swallow the 3D objects (the object sinks into the ground). > Now, as I have not defined the 3D objects as a DCS, it must therefore be static (and not moving), > so this means the ground moves ! > > Clearly something is wrong here. It could well be some aspect of Performer I do not understand. > Are there any known problems with the earth sky model ? I have an Onyx system with VTX graphics, > in case that is relavent. I have spent two days > trying to figure out if it is something I am doing wrong, so > thanks in advance for any help you can give. > > If the above is in any way unclear then please get back to me for clarification. > > Thanks > Richard Gallery > Philips Research Labs > Redhill > Surrey From guest Fri Jan 7 10:36:03 1994 To: info-performer@sgi.sgi.com Subject: Performer 1.2 Date: Fri, 7 Jan 94 19:35:49 CET From: "Infobyte S.R.L." Message-Id: <9401071935.aa07729@ax433.mclink.it> Hi all and happy new year. It's not more than a month I am reading this forum and it seems that Perfomer 1.2 is on the way to be released in a very short time. When it will become available? If it's not a very short time, what is needed to eventually become a beta testing site for it? Is there already an idea of its price? Thank you for any answer. Massimo Cuomo - Infobyte From guest Sun Jan 9 09:56:45 1994 Date: Sun, 9 Jan 94 12:56:31 EST From: jaydee@thor.ats.qc.ca (Jean Daigle) Message-Id: <9401091756.AA26709@thor.ats.qc.ca> To: info-performer@sgi.sgi.com Subject: Performer 1.2 beta conversion subtlety From the recently-posted Performer FAQ: > ------------------------------ > > Subject: -42- 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; > > ------------------------------ Is it pointed out anywhere that this fix _induces_ segmentation faults in Performer 1.2 code? I can't find any reference to this in the release notes. Has anyone else found that their freshly ported Performer 1.1 apps crash ingloriously? Perhaps the '/usr/src/Performer/src/tools/port1.2' conversion script should flag this situation with a comment somewhere in the neighbourhood of pfNewChan() calls. Cheers, Jean Daigle. ----------------------------------------------------------------- | Jean Daigle ATS AeroTechnologies Inc. | | Software Designer 1250 Boul Marie-Victorin | | St. Bruno, QC J3V 6B8 | | jaydee@ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 | ----------------------------------------------------------------- From guest Wed Jan 12 04:56:45 1994 Message-Id: <9401121256.AA03477@sgi.sgi.com> Date: Wed, 12 Jan 94 07:56:04 EST From: M904662P@ISOBB3.PWFL.COM To: info-performer@sgi.sgi.com, stefanm@munich.sgi.com Subject: Distinct Light Point Control of Cloned Nodes *** Resending note of 01/12/94 07:53 From: Marcus Rothstein Deutsche Aerospace (DASA), Munich, GERMANY Phone: 011-49-89-607-28312 FAX: 011-49-89-607-22491 ----------------------------------------------------------------------- Subject: Distinct Light Point Control of Cloned Nodes Our questions are: 1 - How can we clone a node (e.g. same type of aircraft) with distinct control over the aircraft's light point characteristics? example: 1. Aircraft on ground with light points off, and 2. Same type of aircraft in the air, light points on? 2 - Light point color.... the manual advises that the "actual light point color shall depend on the direction, shape, position, and fog." We experienced that the light points do not attenuate in fog conditions. Can you please advise why? We run Performer 1.2a72.Irix5 on an Onyx, Reality Engine 2, with 2 - 100 MHz processors, 64 Meg, and 2 RMs. Thank you, Marcus Rothstein Mail Address: Deutsche Aerospace, Luftfahrt, Munich, Germany Internet Address: rothstmd@pwfl.com ----------------------------------------------------------------------- From guest Wed Jan 12 08:48:03 1994 From: "Michael Jones" Message-Id: <9401120846.ZM14888@babar.asd.sgi.com> Date: Wed, 12 Jan 1994 08:46:32 -0800 In-Reply-To: M904662P@ISOBB3.PWFL.COM "Distinct Light Point Control of Cloned Nodes" (Jan 12, 7:56am) References: <9401121256.AA03477@sgi.sgi.com> X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: M904662P@ISOBB3.PWFL.COM, info-performer@sgi.sgi.com, stefanm@munich.sgi.com Subject: Re: Distinct Light Point Control of Cloned Nodes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 12, 7:56am, M904662P@ISOBB3.PWFL.COM wrote: > Subject: Distinct Light Point Control of Cloned Nodes :From: Marcus Rothstein Deutsche Aerospace (DASA), Munich, GERMANY :Phone: 011-49-89-607-28312 FAX: 011-49-89-607-22491 :----------------------------------------------------------------------- :Subject: Distinct Light Point Control of Cloned Nodes : :Our questions are: : : 1 - How can we clone a node (e.g. same type of aircraft) with distinct : control over the aircraft's light point characteristics? : : example: 1. Aircraft on ground with light points off, and : 2. Same type of aircraft in the air, light points on? The pfLightPoint nodes will be shared in cloned geometry, so that's not a solution. The true answer is to put a pfSwitch node above the light points, with as many pfLightPoint nodes attached to the pfSwitch as are needed to represent all the "parallel" light point states. Then after the clone, set one vehicles switch node to "ON" and the other to "OFF" as in the example above. More elaborate states would require more nodes attached to the pfSwitch node. : 2 - Light point color.... the manual advises that the "actual light : point color shall depend on the direction, shape, position, and fog." : : We experienced that the light points do not attenuate in fog : conditions. Can you please advise why? Because the person who wrote that part of the manual described the way it should be rather than the way it is. The fogging of pfLightPoints must be handled specially, since luminous objects like lights are visible at greater ranges than non-luminous ones such as runways. Versions of IRIS Performer up to now have not addressed this issue. This support has been added to IRIS Performer 1.2, however, and it's a feature you can look for in the upcoming release. P.S. Thanks for the umbrella. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Jan 12 10:42:10 1994 Date: Wed, 12 Jan 94 09:50:55 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401121750.AA21628@tubes.asd.sgi.com> To: M904662P@ISOBB3.PWFL.COM, stefanm@munich.sgi.com, info-performer@sgi.sgi.com Subject: Re: Distinct Light Point Control of Cloned Nodes > 1 - How can we clone a node (e.g. same type of aircraft) with distinct > control over the aircraft's light point characteristics? > > example: 1. Aircraft on ground with light points off, and > 2. Same type of aircraft in the air, light points on? Put the pfLightPoint node underneath a pfSwitch. Then when you call pfClone, the pfSwitch will be cloned, giving you independent control over the lightpoints. > > 2 - Light point color.... the manual advises that the "actual light > point color shall depend on the direction, shape, position, and fog." > > We experienced that the light points do not attenuate in fog > conditions. Can you please advise why? pfLightPoints will be fogged in the 1.2 release of Performer. From guest Thu Jan 13 09:11:28 1994 Date: Thu, 13 Jan 94 09:12:41 -0800 From: goetzjr@gravy3.cs.nps.navy.mil (john goetz) Message-Id: <9401131712.AA16465@gravy3.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: Texture Coordinates Is there an available algorithm that will automatically generate texture coordinates for Performer geosets (i.e. similiar to GL's texgen command) ? Thank You John Goetz goetzjr@cs.nps.navy.mil From guest Thu Jan 13 10:40:59 1994 Message-Id: <9401131840.AA09386@surreal.asd.sgi.com> To: goetzjr@gravy3.cs.nps.navy.mil (john goetz) Cc: info-performer@sgi.sgi.com Subject: Re: Texture Coordinates In-Reply-To: Your message of "Thu, 13 Jan 94 09:12:41 PST." <9401131712.AA16465@gravy3.cs.nps.navy.mil> Date: Thu, 13 Jan 94 10:40:34 -0800 From: Jim Helman > Is there an available algorithm that will automatically generate texture > coordinates for Performer geosets (i.e. similiar to GL's texgen command) ? Not per se. It could be a useful addition to the utlity library geoset construction routines, but most modelers can do this already. If your modeler doesn't, or you want dynamic texture coordinates generated for a special effect, you can call texgen yourself. At rendering time, you a node pre-draw callback to turn texgen on and then turn it off in the node's post-draw callback. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Jan 14 03:03:07 1994 Date: Fri, 14 Jan 94 11:02:51 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9401141102.AA04387@death.reading.sgi.com> To: info-performer Subject: Knut Question I think I know why Knuts textures disappear for a short time.... There must be two co-planar polygons, either in the same model or in adjacent LOD's during LOD Fade one that is textured, and one that isn't. One of the house.flt's in Performer town did this. Lots of surfaces do this if you turn off backfacing. ANgus "Imagine your witty quote here" From guest Sun Jan 16 14:54:21 1994 From: barham@gnarly.cs.nps.navy.mil (paul barham) Message-Id: <9401162220.AA09463@gnarly.cs.nps.navy.mil> Subject: pfFind functions in Performer 1.0 To: info-performer@sgi.sgi.com Date: Sun, 16 Jan 94 14:20:23 PST X-Mailer: ELM [version 2.3 PL11] Do the pfFind functions work in Performer 1.0? --- I have a structure (confirmed by pfDebugPrint) containing the following path to a DCS: /G_scene/G_veh/m60+a_copy1/__NPS_tEmP1/m60+a/High/Group 1/gun --- For brevity, here is the debug print of the node: (I started the debug print at /G_veh because the /G_scene structure is complex) 7:pfDCS 5690 0x14a740b0 { 7: path: /G_veh/m60+a_copy1/__NPS_tEmP1/m60+a/High/Group 1/gun 7: ctr: (0.012500, 3.223277, 0.294698) rad:1.736382 --- When I use the function, pfFindDCS with the path from above, I get the message: Performer Warning:pfFind() Node type pfGroup is not requested type. --- When I use the function, pfFindGroup with the path from above, the function returns successfully, finding: G_veh --- I know the path to be a unique one from the root scene node. Anyone have any ideas?? Thanks in advance, Paul T. Barham -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Paul T. Barham Computer Specialist Computer Graphics Research + + + + Naval Postgraduate School barham@cs.nps.navy.mil + + Computer Science Department, Code CS Spanagel Hall Room 311A + + Monterey, Calfornia 93943 (408)656-2253 (2814 fax)+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From guest Tue Jan 18 07:37:21 1994 From: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Message-Id: <9401181635.ZM2718@shark.paris.sgi.com> Date: Tue, 18 Jan 1994 16:35:38 +0100 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Cc: norbert@paris.sgi.com Subject: Memory allocation : when, where, how ? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, I need informations and precisions about memory allocation in Performer. What is the difference between : - pfMalloc(NULL) - pfMalloc(number, pfGetSharedArena()) - arena = pfGetSharedArena(); pfMalloc(number, arena); What is the best way to allocate memory in Performer ? When arena must be use in Performer ? Is there a difference between the objects in Performer (pfMaterial, pfList, pfFog, pfFrustum, pfChannel, pfGroup, pfGeode ...) and the way you allocate them ? When you are using Multi processing, what must be allocated in arena ? Thanks for your help. Norbert From guest Tue Jan 18 07:50:21 1994 From: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Message-Id: <9401181648.ZM2743@shark.paris.sgi.com> Date: Tue, 18 Jan 1994 16:48:29 +0100 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Cc: norbert@paris.sgi.com Subject: Billboard Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi performer's group Simple problem : I create a tree with a billboard. I have an explosion near this tree. I must remove a part of these tree. How can I found the index of a part of these tree (just to remove this part) ? How can I draw these tree without re-drawing the whole billboard ? Perhaps difficult to answer ? Thanks for your help Norbert. From guest Tue Jan 18 08:24:57 1994 Message-Id: <9401181624.AA04515@surreal.asd.sgi.com> To: norbert@shark.paris.sgi.com (Norbert BIANCHIN) Cc: info-performer@sgi.sgi.com Subject: Re: Billboard In-Reply-To: Your message of "Tue, 18 Jan 94 16:48:29 +0100." <9401181648.ZM2743@shark.paris.sgi.com> Date: Tue, 18 Jan 94 08:24:43 -0800 From: Jim Helman Since a typical billboarded tree is a rectangle made up of two triangles, you'll have trouble getting a convincing part of a tree using the existing texture and part of the geometry. You'll probably either want to create different geometry (e.g. a short quad for the tree trunk only) or a different texture (e.g. a broken tree) or both. It's not terribly efficient, but you could use one tree per pfBillboard and use a pfSwitch node or the draw traversal mask to pfBillboard to enable and disable the exploded version. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jan 18 08:36:58 1994 Date: Tue, 18 Jan 94 16:36:45 GMT From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9401181636.AA03021@death.reading.sgi.com> To: info-performer@sgi.sgi.com Subject: No Graphics Can I get a clue how to run Performer on a server for database queries ? ANgus "Imagine your witty quote here" From guest Tue Jan 18 22:07:10 1994 From: "Michael Jones" Message-Id: <9401180931.ZM12707@babar.asd.sgi.com> Date: Tue, 18 Jan 1994 09:31:49 -0800 In-Reply-To: angus@death.reading.sgi.com (Angus Henderson) "No Graphics" (Jan 18, 4:36pm) References: <9401181636.AA03021@death.reading.sgi.com> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: angus@death.reading.sgi.com (Angus Henderson), info-performer@sgi.sgi.com Subject: Re: No Graphics Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 18, 4:36pm, Angus Henderson wrote: > Subject: No Graphics :Can I get a clue how to run Performer on a server for :database queries ? This feature is a known omission from IRIS Performer. The planned method is to support the notion that calling pfMultipipe(0) would indicate that an application is just not interested in culling, drawing, or opening any pfPipes. Until then (this feature is not in IRIS Performer 1.2) the only approaches are pretty ugly: link without GL, see whats referenced, and build no-op stubs for each function. Then run with one pfpipe, but disable culling of the channel. Ugly. -- 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 Jan 18 22:07:19 1994 From: "Michael Jones" Message-Id: <9401180953.ZM12733@babar.asd.sgi.com> Date: Tue, 18 Jan 1994 09:53:30 -0800 In-Reply-To: norbert@shark.paris.sgi.com (Norbert BIANCHIN) "Memory allocation : when, where, how ?" (Jan 18, 4:35pm) References: <9401181635.ZM2718@shark.paris.sgi.com> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: norbert@shark.paris.sgi.com (Norbert BIANCHIN), info-performer@sgi.sgi.com Subject: Re: Memory allocation : when, where, how ? Cc: norbert@paris.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 18, 4:35pm, Norbert BIANCHIN wrote: > Subject: Memory allocation : when, where, how ? :I need informations and precisions about memory allocation in Performer. : :What is the difference between : : - pfMalloc(NULL) pfMalloc(size, NULL) means call malloc(size) : - pfMalloc(number, pfGetSharedArena()) : - arena = pfGetSharedArena(); pfMalloc(number, arena); pfMalloc(size, arenaAddress) means allocate from the specified shared memory arena. Using the pfGetSharedArena() function in the place of a variable reference is simply an alternate C-language coding idiom. Passing the value zero as the arenaAddress indicates that you want to use the normal C-library malloc() function to allocate from non-shared heap memory. If the arenaAddress argument is non-null, then it indicates the address of a shared memory arena from which allocation should happen. At startup, libpf establishes a shared memory arena for your (and it's) use. The address of this arena is returned by pfGetShared Arena(). :What is the best way to allocate memory in Performer ? malloc() if fine for unshared allocations. pfMalloc(xxx, arenaAddress) is _mandatory_ for successful multiprocessing if other processes must see the data you're allocating. Since free() must be used for malloc()ed memory and pfFree() for pfMalloc()ed, it seems safest to always use pfMalloc() and just pass a NULL arena pointer when you don't need a shared address space allocation. :When arena must be use in Performer ? When the allocated data will be referenced by multiple processes, such as the cull, draw, or intersection processes. The APP may instruct one of these to do something at memory location 700000 (by passing a pointer) but in the other process 700000 may have _NO RELATION WHATSOEVER_ to the APP's data. If shared memory is used, though, you're assured that whatever data pointer is returned by pfMalloc() will be at the same address in the other processes. :Is there a difference between the objects in Performer (pfMaterial, pfList, : pfChannel, pfGroup, pfGeode ...) and the way you allocate :them ? All of the libpf objects--pfChannel, pfGroup, pfGeode--are automatically allocated from the shared arena identified by pfGetSharedArena(). The libpr objects--pfMaterial, pfFog, pfFrustum--are allocated in the address space you specify in their pfNew() routine. :When you are using Multi processing, what must be allocated in arena ? Everything that will be referenced from more than one process. Here's the reference page for pfMalloc. You'll find quite a lot of important information in this page and in the IRIS Performer Programming Guide. Have you looked at either of them yet? pfMalloc(3pf) Silicon Graphics pfMalloc(3pf) NAME pfCalloc, pfRealloc, pfGetMallocArena, pfGetMallocSize, pfMalloc, pfFree - Allocate, query, and free memory C SPECIFICATION #include void* pfMalloc(size_t nbytes, void *arena); void* pfCalloc(size_t numelem, size_t elsize, void *arena); void* pfRealloc(void *ptr, size_t nbytes); void* pfGetMallocArena(void *ptr); long pfGetMallocSize(void *ptr); void pfFree(void *ptr); DESCRIPTION These routines provide a general method to allocate memory, either from the users heap (malloc) or from a shared memory arena (amalloc). In addition, these routines provide a reference counting mechanism used by IRIS Performer to efficiently manage memory. pfMalloc operates identically to malloc(3C), except that a shared memory arena may be specified to allocate the memory from. If arena is NULL, memory is allocated from the heap, otherwise memory is allocated from arena which must be a previously configured shared memory arena. Shared memory arenas can be created using acreate. pfCalloc and pfRealloc function just as their Unix counter- parts, except that they may use shared arenas. In all cases, a pointer to the allocated memory block is returned or NULL if there is not enough available memory. Memory allocated by pfMalloc/pfCalloc/pfRealloc has a special header that, among other things, provides a reference count. Reference counts are used to keep track of how many times a chunk of memory is referenced or instanced. All IRIS Performer libpr objects (prObject) are created with pfMalloc so their reference counts are updated by appropriate libpr routines. Examples of references follow: Example 1: tex = pfNewTex(NULL); /* Attach 'tex' to gstate0 and gstate1. */ pfGStateAttr(gstate0, PFSTATE_TEXTURE, tex); pfGStateAttr(gstate1, PFSTATE_TEXTURE, tex); /* The reference count of 'tex' is now 2. */ /* Remove 'tex' from gstate1. */ pfGStateAttr(gstate1, PFSTATE_TEXTURE, NULL); /* The reference count of 'tex' is now 1. */ Example 2: coords = (pfVec3*) pfMalloc(sizeof(pfVec3) * numVerts, arena); /* Attach 'coords' to non-indexed pfGeoSet, 'gset'. */ pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL); /* The reference count of 'coords' is now 1. */ Example 3: /* Attach 'gstate0' to 'gset' */ pfGSetGState(gset, gstate0); /* The reference count of 'gstate0' is now incremented by 1. */ pfFree frees the memory associated with ptr. It is an error to pfFree memory that was not allocated by pfMalloc/pfCalloc/pfRealloc and results are undefined if any method other than pfFree or pfDelete (see below) is used to free memory allocated by pfMalloc/pfCalloc/pfRealloc. pfFree does not honor the reference count of ptr. This means that you can free a chunk of memory that is still being used, i.e. - its reference count is > 0, with potentially disastrous results in the form of mysteri- ous memory trashing and segmentation violations. pfDelete however, does honor the reference count of ptr and will not delete any memory whose reference count is > 0. pfDelete returns -1 if ptr is not a pfMalloc pointer, TRUE if ptr was deleted, and FALSE other- wise. pfDelete is recommended if you are not sure of the reference count of a piece of memory. See the pfObject man page for more details on pfDelete. pfGetMallocArena returns the arena pointer which ptr was allocated from or NULL if ptr was allocated off the process heap. pfGetMallocSize returns the size in bytes of the memory referenced by ptr or -1 if ptr is not a pfMalloc pointer. SEE ALSO pfObject, acreate, malloc, calloc, realloc, free -- 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 Jan 18 22:02:45 1994 From: "Michael Jones" Message-Id: <9401181038.ZM12862@babar.asd.sgi.com> Date: Tue, 18 Jan 1994 10:38:48 -0800 In-Reply-To: elke@tyrann.atlas.de "alpha PFTR_HIGH_QUALITY with pf 1.1?" (Jan 18, 7:04pm) References: <9401182004.AA00467@tyrann.atlas.de> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: elke@tyrann.atlas.de, info-performer@sgi.sgi.com Subject: Re: alpha PFTR_HIGH_QUALITY with pf 1.1? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 18, 7:04pm, elke@tyrann.atlas.de wrote: > Subject: alpha PFTR_HIGH_QUALITY with pf 1.1? :1. Why do INTA or RGBA textures look as if they were quantised to 4 levels with :4-sample multisampling and to 8 levels with 8-sample multisampling????? :( Onyx RE2 with 2RM, Performer 1.1, IRIX 5.0.1 ) Since speed is the goal of nearly all IRIS Performer users, we made the default for all settable modes be those that run fastest on the fastest graphics machine, the RealityEngine. The texture subsystem in the RE (same in RE2) runs twice as fast for 16-bit textures as it does for 32-bit ones. It also supports two 16-bit high-speed versions if the normal 32-bit texture formats these are: RGBA as 8-8-8-8 quantized to 4-4-4-4, and, RGB as 8-8-8 quantized to 5-6-6 When these low-precision formats are used, the texture subsystem will run at twice the speed. The default in IRIS Performer is to cause incoming textures to be reformatted into these high-speed internal formats. The function pfTexFormat specifies how the texture image memory associated with tex is formatted. format is a symbolic token specifying which format to set and is PFTEX_INTERNAL_FORMAT, PFTEX_EXTERNAL_FORMAT, or PFTEX_FAST_DEFINE. type is a symbolic token specifying the format type appropriate to format. For PFTEX_INTERNAL_FORMAT and PFTEX_EXTERNAL_FORMAT its values are the same as GL format tokens but with a PFTEX_ prefix. (This last is from the man page) The default internal format is: PFTEX_RGB_5 or PFTEX_RGBA_4 but if you don't like the quality just call pfTexFormat and specify one of: PFTEX_RGBA_8 or PFTEX_RGB_12 for your textures. :2. Apparently PFTR_HIGH_QUALITY must be set with pfGStateMode or pfTransparency :in order to avoid this "quantised" alpha. Is there a way to set :this in Performer 1.1? This token does not exist in PF1.1. :I also looked for a similar method in gl but could not find it. The choices for transparency are blended or multi-sampled. These are the "high-quality" and "fast" modes. Set the desired mode directly using: PFTR_BLEND_ALPHA or PFTR_MS_ALPHA with pfTransparency(). -- 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 Jan 18 21:14:07 1994 Date: Tue, 18 Jan 94 11:14:11 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401181914.AA07579@tubes.asd.sgi.com> To: elke@tyrann.atlas.de, info-performer@sgi.sgi.com Subject: Re: alpha PFTR_HIGH_QUALITY with pf 1.1? >1. Why do INTA or RGBA textures look as if they were quantised to 4 levels with >4-sample multisampling and to 8 levels with 8-sample multisampling????? >( Onyx RE2 with 2RM, Performer 1.1, IRIX 5.0.1 ) Performer's default transparency mechanism uses msalpha() when multisampling is enabled. This is the fastest but will quantize the transparency levels. >2. Apparently PFTR_HIGH_QUALITY must be set with pfGStateMode or pfTransparency >in order to avoid this "quantised" alpha. Is there a way to set >this in Performer 1.1? This token does not exist in PF1.1. >I also looked for a similar method in gl but could not find it. >Can someone help me out here? The PFTR_HIGH_QUALITY token is not exposed in 1.1 but it does exist. In 1.1 its value is 2: pfTransparency(2); or pfGStateMode(gs, PFSTATE_TRANSPARENCY, 2); From guest Tue Jan 18 10:06:18 1994 via CASEnet for mail.germany.eu.net id AA16644; Tue, 18 Jan 94 19:05:55 +0100 Message-Id: <9401182004.AA00467@tyrann.atlas.de> To: info-performer@sgi.sgi.com Subject: alpha PFTR_HIGH_QUALITY with pf 1.1? Date: Tue, 18 Jan 94 19:04:52 -0100 From: elke@tyrann.atlas.de X-Mts: smtp Hallo, Performer experts! Questions: 1. Why do INTA or RGBA textures look as if they were quantised to 4 levels with 4-sample multisampling and to 8 levels with 8-sample multisampling????? ( Onyx RE2 with 2RM, Performer 1.1, IRIX 5.0.1 ) 2. Apparently PFTR_HIGH_QUALITY must be set with pfGStateMode or pfTransparency in order to avoid this "quantised" alpha. Is there a way to set this in Performer 1.1? This token does not exist in PF1.1. I also looked for a similar method in gl but could not find it. Can someone help me out here? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Atlas Elektronik Dept EZS2 Bremen Germany (elke@tyrann.atlas.de) From guest Tue Jan 18 16:48:15 1994 Date: Tue, 18 Jan 94 16:49:30 -0800 From: covingto@gravy2.cs.nps.navy.mil (james covington) Message-Id: <9401190049.AA07822@gravy2.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: Performer and Motif (again!) From guest Tue Jan 18 17:06:15 1994 Return-Path: Comments: The BITNET node taurus.bitnet will cease to exist as of March 1994. If you are still using the address user@taurus.bitnet please convert it to user@math.tau.ac.il Date: Wed, 19 Jan 94 03:06:08 +0200 From: wags@math.tau.ac.il Message-Id: <9401190106.AA17882@libra.math.tau.ac.il> To: info-performer@sgi.sgi.com Subject: DXF files into performer Hi, Does anyone here knwo of (or has ever written) anything that reads a DXF format file into performer, displays the model and enables you to walk through the scene ? I only need it for some tests, it does not have to be very fancy. Thanx. --wags. From guest Tue Jan 18 18:05:24 1994 Date: Tue, 18 Jan 94 18:06:42 -0800 From: covingto@elsie.cs.nps.navy.mil (james covington) Message-Id: <9401190206.AA17632@elsie.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: Performer and Motif(again!) Whoops! My last posting apparently lost its body. So here goes again: My thanks to all who replied to my earlier postings concerning mixing Performer and Motif. I found out finally what was causing the ERR_NOGRAPHICS error when I called GLXlink. In addition to the forbidden functions listed on the man pages for GLXwinset, you should also never call gversion when using the mixed model for GLX widgets and windows. I believe it shouldn't be necessary to use this call anyway, as you should be able to get any necessary graphics info by using GLXgetconfig. Correct me on this if I am wrong. Another problem has reared its head, though. I am having mixed results when trying to use the Iris Font manager library in a Motif/Performer application. When using IRIX 4.0.5G on a 4d/440 Reality Engine, the draw process stops after calling fminit(). If I recompile the same code on an Onyx Reality Engine using IRIX 5.0 the call, and all subsequent font manager routines seem to work fine. Any help? Again I am using Performer 1.0 with IRIX 4.0.5G and Performer 1.1 with the IRIX 5.0 system. Thanks. LT James Covington USN Naval Postgraduate School Monterey CA From guest Wed Jan 19 00:47:28 1994 Return-Path: Date: Wed, 19 Jan 94 15:31:32 +0900 From: wry@dimwit.dst.nk-exa.co.jp (Masahiko Yamanaka) Message-Id: <9401190631.AA02354@dimwit.dst.nk-exa.co.jp> To: info-performer%sgi.sgi.com@sgitokyo.nsg.sgi.com Reply-To: wry%dst.nk-exa.co.jp@sgi.sgi.com Subject: Is there no routine to find Geode under constructed tree? I wanted to use pfBillboard( a kind of pfGeode ). Models had been constructed with MultiGen. When I used pfBillboard, I did follows... pfBillboard *bboard = pfNewBboard; pfAddGSet( (pfGeode *)bboard, geoSet ); So, I had to find the geoSet from the top node of MultiGen data structure. And made a following routine. pfGeode * findGeode( pfNode *group ) { long n1 = pfGetNumChildren( group ); long i; for( i=0; i To: info-performer@sgi.sgi.com Subject: Multigen Flight Format For an upcoming project, I am going to have to both display (using Performer) and convert to an internal format a database received in the Multigen Flight V11 format. Two questions: - is that version of Flight supported by the Performer Multigen loader (and with which version of Performer)? - anybody knows where I can get a full description of the file format structure? --------------------------------------------------------------------- jfr@cae.ca -- J.F. Richard CAE Electronics Ltd Montreal, Canada --------------------------------------------------------------------- From guest Wed Jan 19 10:18:16 1994 Date: Wed, 19 Jan 1994 10:18:18 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199401191818.KAA16265@mail.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: Memory allocation : when, where, how ? I have also discovered that the Performer objects that must be shared among the multiple Performer processes (app, cull, draw) can also be allocated from _ANY_ shared memory, not just shared memory allocated by pfMalloc(). We are using a multi-process model that has a separate manager process that starts up our Performer application process via a fork() and an exec(). The manager process creates its own shared memory region (using std. Unix shared mem. fns., not pf ones and not SGI's usinit, etc. fns.) and makes it accessible to the Performer app process (I did not write that code, so I don't know the details of how this is done). Each of the other Performer processes (cull, draw) inherits access to our shared memory as well as the Performer shared memory. Our geometry data is stored in our own shared memory and when I create a geoset with vertex and normal data, I can just pass the pointer to our data in our shared memory without using pfMalloc and copying it into Performer's shared memory. I have successfully tested this with Performer 1.2 beta on IRIX 4.0.5 on a single CPU IRIS with MP modes of both APPCULLDRAW and APP_CULL_DRAW. Lew Hitchner Xtensory Inc. Scotts Valley, CA From guest Wed Jan 19 11:37:13 1994 From: "Sharon Fischler" Message-Id: <9401191123.ZM10216@rose.asd.sgi.com> Date: Wed, 19 Jan 1994 11:23:41 -0800 In-Reply-To: covingto@elsie.cs.nps.navy.mil (james covington) "Performer and Motif(again!)" (Jan 18, 6:06pm) References: <9401190206.AA17632@elsie.cs.nps.navy.mil> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: covingto@elsie.cs.nps.navy.mil (james covington), info-performer@sgi.sgi.com Subject: Re: Performer and Motif(again!) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 +>---- On Jan 18, 6:06pm, james covington wrote: > Subject: Performer and Motif(again!) ->Whoops! My last posting apparently lost its body. So here goes again: ->My thanks to all who replied to my earlier postings concerning mixing Performer ->and Motif. I found out finally what was causing the ERR_NOGRAPHICS error when ->I called GLXlink. In addition to the forbidden functions listed on the man ->pages for GLXwinset, you should also never call gversion when using the mixed ->model for GLX widgets and windows. I believe it shouldn't be necessary to use ->this call anyway, as you should be able to get any necessary graphics info ->by using GLXgetconfig. Correct me on this if I am wrong. There should be no problem calling gversion with GLX. However, there was a very old bug were calling gversion before the forks done in pfConfig() could cause strangeness, and I even now recall seeing it crop up with GLXLink. The fix was to call it after the pfConfig(), and this bug did get fixed in IRIX5. Are you running 5.0.X or 5.1? ->Another problem has reared its head, though. I am having mixed results when ->trying to use the Iris Font manager library in a Motif/Performer application. ->When using IRIX 4.0.5G on a 4d/440 Reality Engine, the draw process stops after ->calling fminit(). If I recompile the same code on an Onyx Reality Engine using ->IRIX 5.0 the call, and all subsequent font manager routines seem to work fine. ->Any help? We use the font library for our GUI in libpfutil and have no problems in being MP or running under GLX in both IRIX4 and IRIX5. Are you making all fm calls from the draw process, or are you using the font manager in other processes to? Do you only call fminit after pfConfig(), or do you ever call it before? srf. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Wed Jan 19 12:01:57 1994 Message-Id: <9401192001.AA14822@surreal.asd.sgi.com> To: wry%dst.nk-exa.co.jp@sgi.sgi.com Cc: info-performer Subject: Re: Is there no routine to find Geode under constructed tree? In-Reply-To: Your message of "Wed, 19 Jan 94 15:31:32 +0900." <9401190631.AA02354@dimwit.dst.nk-exa.co.jp> Date: Wed, 19 Jan 94 12:01:45 -0800 From: Jim Helman Hmmm... there appears to be code for pfFindGeode routine in every release of Performer so far. The pfFind routines retur the first node of the specified type (not subclass types) with the specified name. If you want a more general search, examine the code in 1.0/1.1: sample/pguide/trav.c or 1.2: libpfutil/trav.c. trav.c provides a general traversal that can be adapted to any purpose. The routine in the mail message has two problems. 1) It only returns the first geode it encounters. 2) It ANDs a PFTYPE_ token. To test for is-a-subclass, you want to AND with PFCLASS_ tokens. PFTYPE_ tokens should only be used to test for equality. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Jan 19 22:59:33 1994 Date: Wed, 19 Jan 94 23:00:07 -0800 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9401200700.AA01370@bessie.cs.nps.navy.mil> To: "Michael Jones" , info-performer@sgi.sgi.com, angus@death.reading.sgi.com (Angus Henderson) Subject: Re: No Graphics References: <9401181636.AA03021@death.reading.sgi.com> I beg to differ with Michael Jones, I had to do this for a DIS interface we did. Basiclly, what I did is not call pfFrame or pfSync in the main loop. As long as you don't laugh too much, here is my code (version 1.0, running 4.0.5 on an Extreme) that seems to work. I did open a 2D window using GL. /* This is the start of the world modeler. Usage world_mod [Network port] [database file] assumes port 3001 and database at ../namedb/dummydata.dat Thu Dec 9 00:34:51 PST 1993 - DRP - Created */ // cute method to share global varables without having multi defs #define __COMMON__ #define __COMMON_WM__ #include "tcpip.h" #include "G_data.h" #include "WM.h" #include "modem.h" #include #include #include #define ALL_MASK 0x0F #define LINE_LEN 80 /*terrain database stuff*/ pfScene *scene; pfGroup *root; main(int argc, char *argv[]) { int socket[10]; // the sockets that we are to connect to janus int jan = 0; //we are going to use only one janus int mess_type; int vid = 0; char messbuff[1023],arenaname[FILENAME_SIZE],terrain_file[FILENAME_SIZE], model_file[FILENAME_SIZE],ether_interf[FILENAME_SIZE]; char waitmsg[255]; int loopcnt = 0, ix = 0; float last_time = 0; float curtime,starttime; struct tms timebuffer; foreground(); /*make sure the program is started correctly*/ if(argc > 4){ printf("Usage: %s [Config file] [Network port] [database file]\n", argv[0]); exit(0); } //read the configuration file if((argc >= 2) && (argc <= 4)){ read_config_file(argv[1],model_file,terrain_file); } else{ read_config_file("Dummy",model_file,terrain_file); } /* ************************************************************ */ /* * STEP 1: Read the name database table that JANUS is also * */ /* * using. * */ /* ************************************************************ */ /* Initialize performer */ pfInit(); pfConfig(); //don't blank the screen blanktime(0); foreground(); set_up(); //Find the database file if(argc == 4){ strcpy(terrain_file,argv[3]); } printf("Using Terrain database %s\n",terrain_file); scene = pfNewScene(); if(strcmp("NONE",terrain_file)){ if ((root = LoadFlt(terrain_file)) == NULL) { printf("Unable to read the terrain datafile %s\n",terrain_file); pfExit(); exit(-1); } } else{ root = pfNewGroup(); } pfAddChild(scene, root); /* Set up the intersection mask for the root node */ pfNodeTravMask(root,PFTRAV_ISECT,ALL_MASK, PFTRAV_SELF|PFTRAV_DESCEND, PF_SET); pfSync(); /* Allocate the memory for the entity arrays, and set all to NOSHOW */ initialize_vehicle_arrays(); #ifdef TRACE cerr <<"Init veh arrays done\n"; #endif /* Read the dynamic models def file and constuct the tree */ setup_type_table(model_file); if (load_veh_data_file() == -1) // jxxl printf("Error in loading vehicle file data\n"); //zero out the clock pfInitClock(); // jxxl - removed arg of 0 - compile error starttime = times(&timebuffer) /(float)HZ; /************************************************************************/ /******************** Main Application Simulation Loop ******************/ while(TRUE){ /* if(!(loopcnt %10)) printf("Start of cycle %3d\n",loopcnt); */ loopcnt++; //handle the inputs process_inputs(); //Handle the DIS network stuff now //read the network parse_net_pdus(); /* Establish a time delta and then update last_time to now */ /* does not work on the extremes G_curtime = pfGetTime(); G_delta_time = G_curtime - last_time; last_time = G_curtime; */ curtime = times(&timebuffer) / (float)HZ; G_curtime = curtime - starttime;; G_delta_time = curtime - last_time; last_time = curtime; //move all of the network entities and myself update_entities(); //draw the 2D map drawmap(); } } void exitroutine() // That is all she wrote { void htl_range(),e2_range(); htl_range(); e2_range(); printf("Graceful exit. \n"); //kill the Janus Recieve process kill(L_Janus_pid,SIGKILL); net_close(); /* Exit performer processes */ pfExit(); exit(0); } int grnd_orient(pfCoord *posture) // This function set the Z location value and the pitch and roll values // once the X-Y position and heading are set. { pfIsect result; pfSeg segment; pfSeg *sp = &segment; /* make a ray looking "down" at terrain */ PFCOPY_VEC3(segment.pos, posture->xyz); segment.pos[Z] += 1000.0f; PFSET_VEC3(segment.dir, 0.0f, 0.0f, -1.0f); pfNormalizeVec3(segment.dir); segment.length = 5000.0f; //printf("IN %10.2f %10.2f %10.2f\n", // segment.pos[X],segment.pos[Y],segment.pos[Z]); /* find intersection with terrain */ result.node = NULL; if ( pfSegsIsectNode(root, &sp, 1, PFTRAV_IS_PRIM|PFTRAV_IS_NORM, ALL_MASK, NULL, &result, NULL) ) { pfXformPt3(result.point, result.point, result.xform); pfXformPt3(result.normal, result.normal, result.xform); pfNormalizeVec3 ( result.normal ); posture->xyz[Z] = result.point[PF_Z]; if (result.flags & PFIS_NORM) { pfVec3 head, head90; float sh, ch; float dotp; pfSinCos(posture->hpr[HEADING], &sh, &ch); head[0] = -sh; head[1] = ch; head[2] = 0.0f; dotp = PFDOT_VEC3(head, result.normal); posture->hpr[PITCH] = pfArcCos(dotp) - 90.0f; head90[0] = ch; head90[1] = sh; head90[2] = 0.0f; dotp = PFDOT_VEC3(head90, result.normal); head90[2] = 0.0f; dotp = PFDOT_VEC3(head90, result.normal); posture->hpr[ROLL] = 90.0f - pfArcCos(dotp); #ifdef DEBUG cerr << "GRND_ORIENT POSTURE X = " << posture->xyz[X] << " Y = " << posture->xyz[Y] << " Z = " << posture->xyz[Z] << endl; cerr << " H = " << posture->hpr[X] << " P = " << posture->hpr[Y] << " R = " << posture->hpr[Z] << endl; #endif return TRUE; } else return FALSE; } else return FALSE; } NOTE: I took ous some of the Network / other stuff code to focus on the database issues. 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 Jan 19 23:06:02 1994 Date: Wed, 19 Jan 94 23:07:20 -0800 From: pratt@bessie.cs.nps.navy.mil (david pratt) Message-Id: <9401200707.AA01379@bessie.cs.nps.navy.mil> To: ignazio@zorro.melbourne.sgi.com (Ignazio Ranno), info-performer@sgi.sgi.com Subject: Re: Getting Node info from IsectNode I had the same type of problem trying to blow up buildings. To get around the performer 1.0 limitations on returning intersections, here is what I did: When you read in the piece of database, put a intersection call back in. The call back stores the address of the node as it is being traversed. Make sure it is a global so you can get it. At traversal time, when the node is traversed - the address will be stored. When an intersection is detected, stop the traversal. At this time, the address of the last traversed node will be stored and you can use that for the display node. 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 Thu Jan 20 00:46:36 1994 Message-Id: <9401200846.AA19517@surreal.asd.sgi.com> To: pratt@bessie.cs.nps.navy.mil (david pratt) Cc: info-performer Subject: Re: Getting Node info from IsectNode In-Reply-To: Your message of "Wed, 19 Jan 94 23:07:20 PST." <9401200707.AA01379@bessie.cs.nps.navy.mil> Date: Thu, 20 Jan 94 00:46:33 -0800 From: Jim Helman Dave's suggestion is good. But mark the code for removal when you port to 1.2. 1.2 provides a full path in the intersection return structure, which is faster than having lots of node callbacks invoked. Note that you really only need callbacks for those nodes with multiple parents. If your geometry is not instanced in the scene graph (or the intancing has been pfFlattened), you can walk the up the scene graph using pfGetParent(). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jan 20 07:22:25 1994 Message-Id: <9401201517.ZM3813@unknown.zmail.host> Date: Thu, 20 Jan 1994 15:17:02 +0000 In-Reply-To: "Infobyte S.R.L." "Performer 1.2" (Jan 7, 7:35pm) References: <9401071935.aa07729@ax433.mclink.it> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Performer 1.2 and Softimage Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi Perhaps somebody knows of any work going on into a SoftImage Loader for Performer, and also, when is the Performer 1.2 release date? Thanks Richard Galelry From guest Wed Jan 19 22:04:20 1994 From: ignazio@zorro.melbourne.sgi.com (Ignazio Ranno) Message-Id: <9401201606.ZM21449@zorro.melbourne.sgi.com> Date: Thu, 20 Jan 1994 16:06:58 -0500 X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Getting Node info from IsectNode Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hello I am trying to write a little app/demo which is able to display which part of the database one is currently above. The GetZHPR routine was useful however I am having a little difficulty trying to work out which Node I am currently above. I was planning to use the "Name " of the NODE in the Multigen database as an indicator of where I was. However this doesn't seem as easy as I initially thought. Thanks for all your help. I'm still using performer 1.1. -- ________ 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 Jan 20 14:08:56 1994 Message-Id: <9401202208.AA22058@mithras.boston.sgi.com> To: info-performer@sgi.sgi.com Subject: ["Eric Lebel": Performer/SoftImage] Reply-To: dpy@sgibos.boston.sgi.com Date: Thu, 20 Jan 1994 17:08:45 -0500 From: David Youatt ------- Forwarded Message Date: Thu, 20 Jan 1994 16:54:58 -0500 From: "Eric Lebel" To: dpy@sgi.sgi.com Subject: Performer To copy of the softimage translator to Performer contact this guy : Gideon@zkm.de -- ___ .....[4 m.. -.- ^ Eric. Team Leader User Interface, Video... eric@softimage.qc.ca ------- End of Forwarded Message -- David Youatt, dpy@sgi.com, 508/562-4800 x353 From guest Thu Jan 20 14:57:49 1994 From: "Michael Jones" Message-Id: <9401201457.ZM18105@babar.asd.sgi.com> Date: Thu, 20 Jan 1994 14:57:18 -0800 In-Reply-To: Richard Gallery "Re: Performer 1.2 and Softimage" (Jan 20, 3:17pm) References: <9401071935.aa07729@ax433.mclink.it> <9401201517.ZM3813@unknown.zmail.host> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: Richard Gallery , info-performer@sgi.sgi.com Subject: Re: Performer 1.2 and Softimage Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 20, 3:17pm, Richard Gallery wrote: > Subject: Re: Performer 1.2 and Softimage :Perhaps somebody knows of any work going on into :a SoftImage Loader for Performer, and also, when is :the Performer 1.2 release date? One of our customers in Germany is working on such a loader, but we've been unable to contact him for several months as he's on some kind of Teutonic Walkabout. There will be no SoftImage loader shipped with IRIS Performer 1.2, however as soon as one becomes available it could be posted to this mailing list. Is there anyone who knows what SoftImage files look like who'd like to increase their fame by creating and donating a loader? -- 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 Sat Jan 22 13:36:31 1994 Date: Sat, 22 Jan 94 13:36:20 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401222136.AA28064@tubes.asd.sgi.com> To: barham@gnarly.cs.nps.navy.mil (paul barham), info-performer@sgi.sgi.com Subject: Re: pfFind functions in Performer 1.0 >Do the pfFind functions work in Performer 1.0? In short, no. In 1.0 and 1.1 pfFind works for paths whose depths are <= 2. Otherwise only the second node in the path will be matched, e.g. - pfFindGroup(/G_scene/G_veh/m60+a_copy1/__NPS_tEmP1/m60+a/High/Group 1/gun) will always return the group G_veh. There is no workaround other than to traverse the scene and find the node yourself. > >--- >I have a structure (confirmed by pfDebugPrint) containing the following path >to a DCS: > >/G_scene/G_veh/m60+a_copy1/__NPS_tEmP1/m60+a/High/Group 1/gun > >--- >For brevity, here is the debug print of the node: >(I started the debug print at /G_veh because the /G_scene structure is > complex) > > 7:pfDCS 5690 0x14a740b0 { > 7: path: /G_veh/m60+a_copy1/__NPS_tEmP1/m60+a/High/Group 1/gun > 7: ctr: (0.012500, 3.223277, 0.294698) rad:1.736382 > >--- >When I use the function, pfFindDCS with the path from above, I get the message: > >Performer Warning:pfFind() Node type pfGroup is not requested type. > >--- >When I use the function, pfFindGroup with the path from above, the function >returns successfully, finding: > >G_veh > > >--- >I know the path to be a unique one from the root scene node. > From guest Mon Jan 24 00:36:20 1994 Message-Id: <9401240836.AA17466@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Re: No Graphics In-Reply-To: Your message of "Wed, 19 Jan 94 23:00:07 PST." <9401200700.AA01370@bessie.cs.nps.navy.mil> Date: Mon, 24 Jan 94 00:36:03 -0800 From: Jim Helman > I beg to differ with Michael Jones, I had to do this for a DIS interface > we did. Basiclly, what I did is not call pfFrame or pfSync in the main loop. Performer always opens a noport() window for the vertical sync clock at pfConfig time. I'm not positive, but I don't think this will fly on a server. For 1.2 or later we plan to fix it so that a Performer database conversion application can run without any graphics whatsoever. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Jan 24 09:16:34 1994 From: "Michael Jones" Message-Id: <9401240916.ZM5344@babar.asd.sgi.com> Date: Mon, 24 Jan 1994 09:16:19 -0800 In-Reply-To: Jim Helman "Re: No Graphics" (Jan 24, 12:36am) References: <9401240836.AA17466@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: No Graphics Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jan 24, 12:36am, Jim Helman wrote: > Subject: Re: No Graphics : :> I beg to differ with Michael Jones, I had to do this for a DIS interface :> we did. Basiclly, what I did is not call pfFrame or pfSync in the main loop. : :Performer always opens a noport() window for the vertical :sync clock at pfConfig time. I'm not positive, but I don't :think this will fly on a server. For 1.2 or later we plan :to fix it so that a Performer database conversion :application can run without any graphics whatsoever. : :-jim helman My reputation is saved ;-) Actually, what I meant is what Jim's getting at above. When the original questioner asked about "intersections on a server," I took that to mean something different than "an intersection server." Since being too literal in communication is one of my common mistakes, I just went with the flow when the always wise Dr. David Pratt, PhD, Marine, mentioned his success, thinking that the questioner would clarify if needed. What does this mean? If you have an SGI "server" (machine with *no* graphics HW or SW) then IRIS Performer is not going to be happy when you call pfConfig() -- no doubt about it. I want to change this attitude, and the idea of calling pfMultipipe(0) to indicate your no-graphics-whatsoever intentions seems like the best way to me. Look for this (or a better) mechanism in the future. Stubbing the GL calls is the only way until this happens. If you want to use an SGI graphic workstation as an "intersection server" then you are home free. Dave Pratt provides all the instructions that you will need to do this now. Thanks to Dave Pratt and Jim Helman for delving into the facts out of such an innocent question. -- 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 Jan 25 07:08:28 1994 Message-Id: <9401251508.AA23571@sgi.sgi.com> To: info-performer@sgi.sgi.com Subject: flickering on RealityEngine Date: Tue, 25 Jan 1994 16:08:42 +0100 From: Patrick Aschwanden Sender: paschwan@ifi.unizh.ch I have a little rendering problem with polygons which are close together and far away from the eye point. It seems like Performer cannot decide which polygon is visible. (Even the fog - stuff doesn't work on the RE2) The strange thing is, that everything works fine on a machine with VGX-graphics. Did I forget some initializations which for the Reality Engine or are there problems of synchronisation or HW - problems or ???? I hope anyone can give me a hint in the right direction. PS: I am running on a Onyx with Irix5.1 with Performer 1.0 (compiled on Irix4.x) -Patrick Aschwanden From guest Thu Jan 27 06:38:24 1994 Date: Thu, 27 Jan 94 09:42:12 -0500 From: bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Message-Id: <9401271442.AA06268@ gizmo.lasc.lockheed.com> To: info-performer@sgi.sgi.com Subject: Perfly GUI Separation Is there a quick way to separate perfly's GUI so it will appear on a remote system's screen while the main graphics still appears on the local machine? I'm running Performer 1.2beta on an Onyx RE2 with IRIX 5.1.1.2. -- Barry W. Webb bwebb@gizmo.lasc.lockheed.com From guest Thu Jan 27 06:28:48 1994 From: "Ran Yakir" Message-Id: <9401271627.ZM953@amcor.bvr.co.il> Date: Thu, 27 Jan 1994 16:27:42 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: culling control thru pre/post callbacks Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi all ! I'm trying to get into the culling process and add some other culling types. So far I succeeded doing that in the pre-culling function. The problem is that my culling stuff takes a lot of time, and I would like to perform it for those nodes that passed the culling test (i.e. were not culled out). Does anybody know how can I tell, while in the post culling callback, if the node was culled out or not ? Thanks Ran Yakir From guest Thu Jan 27 10:39:18 1994 Date: Thu, 27 Jan 94 10:38:57 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401271838.AA03353@tubes.asd.sgi.com> To: info-performer@sgi.sgi.com, "Ran Yakir" Subject: Re: culling control thru pre/post callbacks >I'm trying to get into the culling process and add some other culling >types. >So far I succeeded doing that in the pre-culling function. The problem is >that my culling stuff takes a lot of time, and I would like to perform >it for those nodes that passed the culling test (i.e. were not culled out). >Does anybody know how can I tell, while in the post culling callback, if the >node was culled out or not ? Unfortunately 1.0/1.1 are pretty weak with regards to the cull callbacks and can't easily do what you want if at all. 1.2 is much better and allows you to: 1. Replace default Performer culling with your own through pfCullResult() called in the preCull callback. 2. Query the result of the cull in the postCull callback through pfGetCullResult(). From guest Thu Jan 27 10:55:02 1994 Date: Thu, 27 Jan 94 10:54:52 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401271854.AA03398@tubes.asd.sgi.com> To: info-performer@sgi.sgi.com, bwebb@gelac.lasc.lockheed.com (Barry W. Webb) Subject: Re: Perfly GUI Separation >Is there a quick way to separate perfly's GUI so it will appear on a >remote system's screen while the main graphics still appears on the >local machine? I'm running Performer 1.2beta on an Onyx RE2 with >IRIX 5.1.1.2. I have seen this work so I know it's possible and it's relatively easy to do. You'll need to create another pfPipe (use pfMultipipe) so you can have a separate GL window for the GUI. Pass this extra pipe to epfInitGUI and you should be all set but as I recall, there may be some problems initializing the font manager that you'll have to figure out. To summarize: pfMultipipe(2); pfConfig(); pfInitPipe(pfGetPipe(1), initGUIPipe); pfInitGUI(pfGetPipe(1)); void initGUIPipe(pfPipe *p) { /* Open a connection to the graphics server on a remote machine */ dglopen(); winopen(""); } Let us know how it turns out. From guest Thu Jan 27 19:18:09 1994 Message-Id: <9401280318.AA10961@surreal.asd.sgi.com> To: Patrick Aschwanden Cc: info-performer@sgi.sgi.com Subject: Re: flickering on RealityEngine In-Reply-To: Your message of "Tue, 25 Jan 94 16:08:42 +0100." <9401251508.AA23571@sgi.sgi.com> Date: Thu, 27 Jan 94 19:18:01 -0800 From: Jim Helman > I have a little rendering problem with polygons which are close together > and far away from the eye point. It seems like Performer cannot decide which > polygon is visible. You don't say how far apart the polygons are in depth, but effective Z buffer resolution drops as range increases. So while a 1 cm separation may look fine at a few meters, it won't at a few kilometers, and you'll have Z buffer "fighting". If you are rendering nearly co-planar polygons, consider using a pfLayer to render them. But use them sparingly, under 1.1 on RealityEngine there is a substantial performance penalty on pixel fill rates for both the "base" and "decal" polygons. 1.2 will by default use another mechanism (displacepolygon) which doesn't have this problem. But, I'm not sure why it would appear any worse than on a VGX. Are you sure the near/far clip ranges are the same. VGX has 24 bit Z. RE has 24 or 32 bit Z, depending on your msconfig. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Jan 28 08:57:48 1994 Date: Fri, 28 Jan 1994 11:57:38 -0500 From: John C Vanderburgh Message-Id: <199401281657.AA21749@stealth.afit.af.mil> To: info-performer@sgi.sgi.com Subject: Rendering in the overlay planes I'd like to render some text in the overlay planes on a (four-processor) 4D/440 VGXT from within a Performer 1.2 (Beta) application. 1. Does the pfInitGfx() call configure the overlay/underlay planes? (I assume it doesn't...) 2. Do I need to use the GL "overlay(n)" call prior to pfInitGfx() in order to configure n bitplanes for the overlay planes? (I tried this...) 3. Assuming that I can get past configuring some overlay planes, would I render in them via my "draw" callback? I'm not having much luck... Thanks in advance, John Vanderburgh (Air Force Institute of Technology -- jvanderb@afit.af.mil) From guest Fri Jan 28 14:04:55 1994 Date: Fri, 28 Jan 94 16:00:34 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9401282200.AA16297@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Re: Rendering in the overlay planes >From: John C Vanderburgh >Subject: Rendering in the overlay planes > > I'd like to render some text in the overlay planes on a (four-processor) > 4D/440 VGXT from within a Performer 1.2 (Beta) application. > > 1. Does the pfInitGfx() call configure the overlay/underlay planes? > (I assume it doesn't...) Any configuration of GL stuff for your window needs to be done in the callback from your pipe initialization callback, initFunc as in /* From the man page for pfInitPipe */ pfNewPipe(pfPipe *pipe, void (*initFunc)(pfPipe* pipe)) ^^^^^^^^ Do any settings for the window here... > 2. Do I need to use the GL "overlay(n)" call prior to pfInitGfx() in > order to configure n bitplanes for the overlay planes? > (I tried this...) Since you are on a multi-process machine, if you try this (or any other GL function) from any process other than the draw process, the result is undefined. Thus the reason for the function pointer passed to pfInitPipe(). Even if you weren't on a multi-process machine, you should do GL functions only in the proper places (in the draw callback or the function callback in pfInitPipe() etc)... > 3. Assuming that I can get past configuring some overlay planes, would > I render in them via my "draw" callback? Once everthing is set up, you can use the draw callback to draw your stuff into the overlay planes. I would suggest, however, that you check Sharon Fischler's response (in the Frequently Asked Questions) about drawing in the overlay... You suffer significant performance hits for switching from drawmode(NORMALDRAW) to drawmode(OVERLAY), and it is actually better to stay in NORMALDRAW and draw all your stuff over the performer graphics in a post draw callback for EACH frame. If you do have stuff that is always staying up there (not changing much or at all) you may want to switch to drawmode(OVERLAY)... > I'm not having much luck... Hope this helps! >John Vanderburgh >(Air Force Institute of Technology -- jvanderb@afit.af.mil) aaron@dseg.ti.com Aaron Hightower Voice: (214)575-6759 Visualization and Simulation Technology Department FAX: (214)575-6779 Texas Instruments Home: (214)517-9245 From guest Sat Jan 29 10:30:41 1994 From: "Stephen Joyce {75069}" Message-Id: <9401291749.AA13820@swlrgk> To: jimh@surreal, paschwan@ifi.unizh.ch Subject: Re: flickering on RealityEngine Cc: info-performer@sgi.sgi.com Speaking of near/far clip ranges, what are good values for setting these to with the Performer GUI? I am looking at a MultiGen flight data base and experience problems with the changing of levels of detail. Thanks Steve Joyce shj@swl.msd.ray.com From guest Sat Jan 29 10:30:36 1994 From: "Stephen Joyce {75069}" Message-Id: <9401291751.AA13831@swlrgk> To: info-performer@sgi.sgi.com Subject: Near/Far Clip Planes Cc: shj%swl@swlrgk.msd.ray.com Speaking of near/far clip ranges, what are good values for setting these to with the Performer GUI? I am looking at a MultiGen flight data base and experience problems with the changing of levels of detail. Thanks Steve Joyce shj@swl.msd.ray.com From guest Sat Jan 29 12:07:53 1994 Message-Id: <9401292007.AA08458@surreal.asd.sgi.com> To: "Stephen Joyce {75069}" Cc: paschwan@ifi.unizh.ch, info-performer@sgi.sgi.com Subject: Re: flickering on RealityEngine In-Reply-To: Your message of "Sat, 29 Jan 94 12:49:07 EST." <9401291749.AA13820@swlrgk> Date: Sat, 29 Jan 94 12:07:42 -0800 From: Jim Helman For best Z resolution and to eliminate invisible geometry (e.g. in heavy fog), you want to set the near clip as far away as practical and the far clip as near as practical. What's practical depends on the range within which you need to view objects. With heavy fog, you can bring in the far clip. In an flight simulator, you can push out the near clip compared with say a building walkthrough. The near/far clip ranges do not affect our LOD calculation. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sun Jan 30 17:53:21 1994 Return-Path: Date: Mon, 31 Jan 94 10:30:48 +0900 From: wry@dimwit.dst.nk-exa.co.jp (Masahiko Yamanaka) Message-Id: <9401310130.AA00764@dimwit.dst.nk-exa.co.jp> To: info-performer%sgi.sgi.com@sgitokyo.nsg.sgi.com Reply-To: wry%dst.nk-exa.co.jp@sgi.sgi.com Subject: Can I get all the new features of ver.1.2? Is there the document which contains all of the new features of Performer1.2 and is available now? From guest Tue Feb 1 14:51:35 1994 From: m218822@fltsim.MDC.COM (Bill Balloni) Message-Id: <9402012144.AA03862@fltsim.MDC.COM> Subject: Dynamic Database Loading/Paging. To: info-performer@sgi.sgi.com Date: Tue, 1 Feb 1994 15:44:34 -0600 (CST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1173 I am interested in the subject of loading a database for rendering by Performer in a "demand paged" fashion. I have limited experience with Performer but realize that database loading can be controlled at the user's application level (as opposed to other visual packages). I anticipate needing to deal with databases that are 1GB and over in size. Obviously, the memory required for this database is prohibitive (and damned expensive!). I envision being able to keep a region of the database (say all data within a 20km radius) in memory. The rest would remain on the disk. As is needed, data would be read from disk in a demand paged manner. This would allow smaller memory sizes but (probably) require significant application complexity to support. Has anyone addressed this problem? What are the hows and whys regarding this approach ("don't bother" may be the majority response but I hope not). If you have some information or an opinion I would love to here from you. Thanks, Bill Balloni McDonnell Douglas Aerospace St. Louis, MO Flight Simulation Facility email: balloni@fltsim.MDC.COM From guest Tue Feb 1 18:09:34 1994 Date: Tue, 1 Feb 1994 18:07:58 -0800 (PST) From: Michael Macedonia Subject: Re: Dynamic Database Loading/Paging. To: Bill Balloni Cc: info-performer@sgi.sgi.com, dave pratt In-Reply-To: <9402012144.AA03862@fltsim.MDC.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Feb 1994, Bill Balloni wrote: > > Has anyone addressed this problem? What are the hows and whys regarding > this approach ("don't bother" may be the majority response but I hope not). > If you have some information or an opinion I would love to here from you. > > Thanks, > > Bill Balloni McDonnell Douglas Aerospace St. Louis, MO > Flight Simulation Facility > email: balloni@fltsim.MDC.COM Contact Dr. Dave Pratt at pratt@cs.nps.navy.mil. He addressed this problem already in NPSNET. Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From guest Wed Feb 2 06:08:25 1994 Date: Wed, 2 Feb 94 09:06:27 EST From: elkins@degas.nswc.navy.mil (Les Elkins b40 x43850) Message-Id: <9402021406.AA01668@degas.nswc.navy.mil> To: info-performer@sgi.sgi.com Subject: Color changes Hello... I'm in the process of learning how to use Performer, and to that end have written a loader to read some 3D objects I've had lying around on a disk. The loader reads the files and constructs GeoStates based on the materials data, then reads each polygon into a GeoSet, then ties the appropriate GeoState to it. I then set the color of each geoset to white, stick all of the geosets in a file under a single pfGroup, add these to a scene, and things seem to work fine. However, when I load a .flt file into the same scene and add it into the scene graph, the objects read by my loader sometimes turn grey or black. Most often, but not always, this happens when the object from the .flt file changes LOD (I'm usually loading in esprit.flt). The object read by the .flt loader, of course, looks fine... I've looked into the flight loader source, but don't see any 'smoking guns' pointing to things I might be stepping on. I'm probably not initializing something correctly in my ignorance, but could someone give me any hints as to what to look for? I'm running Performer 1.0 on a Crimson w/VGXT, under IRIX 4.0.5J. If more info is needed to give a diagnosis, please let me know. Thanks in advance, Les Elkins elkins@degas.nswc.navy.mil From guest Wed Feb 2 09:39:45 1994 From: "Marc SIMON Presales support" Message-Id: <9402021857.ZM814@girl.paris.sgi.com> Date: Wed, 2 Feb 1994 18:57:15 +0100 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Questions about Perf1.2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I have some questions about features of GL vs PERFORMER. - Is there a way in Performer to manage pagination of texture like in GL . - For managing the pfLayer i read that Perf1.2 uses DisplacePolygon, but if i well remember displace polygon modify the Z value of a polygon by a factor calculated by the use of the polygon orientation, and this factor is 0.0 if the polygon as its normal oriented direct to the viewer.So for coplanar polygon in front of the viewer it will no works fine Is'it right ??? Is there a way to avoid this ??? - Is there a way to store informations on every nodes of the hierarchy ?? - I heard that Performer sorts the polygons before the drawing to optimise the graphics (Especially mode transitions).But what kind of sorting Performer uses .. Is it only to group polygons with the same textures to avoid Texbind ??? - My last question is not especially for Performer guys, in fact it seems that the GL call "msmask()" is very slow . Is it right ??? Thanks in advance smarc@paris.sgi.com Marc SIMON From guest Wed Feb 2 11:57:11 1994 Message-Id: <9402021955.AA05477@sgi.sgi.com> Date: 2 Feb 94 14:01:00 EST From: "Scott Davidson" Subject: 1.0 to 1.1 compatability To: "info-performer" We're working with the University of Pennsylvania to build a Performer loader of Peabody geometry. The loader is fairly basic but we're concerned about loader compatability between Performer 1.0 and 1.1. Are there any show-stoppers between 1.1 and 1.0 that we should be worried about. Thanks, Scott Davidson NAWCTSD From guest Wed Feb 2 13:12:57 1994 Message-Id: <9402022112.AA01988@surreal.asd.sgi.com> To: "Scott Davidson" Cc: "info-performer" Subject: Re: 1.0 to 1.1 compatability In-Reply-To: Your message of "02 Feb 94 14:01:00 EST." <9402021955.AA05477@sgi.sgi.com> Date: Wed, 02 Feb 94 13:12:54 -0800 From: Jim Helman > Are there any show-stoppers between 1.1 and 1.0 that we should be > worried about. 1.0 and 1.1 are identical in terms of API and functionality, except for the following bug fixes listed in the release notes. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 What follows is a brief description of bugs that were found in IRIS Performer 1.0 and fixed in 1.1. This chapter lists the problems with the IRIS Performer libraries, libpr and libpf, and with the shared memory configurations. "libpr" Floating point exceptions can cause severe and mysterious performance degradation. pfNotifyLevel levels of PFNFY_DEBUG and PFNFY_INFO enable floating point exceptions so the application is alerted to this potentially disastrous situation. In 1.0, underflows were not trapped and consequently caused some problems. In 1.1, underflows are trapped. pfFilePath would exit with a FATAL error if it was called twice. Applying a back-sided material which had a color mode (pfMtlColorMode), would set the GL lmcolor mode. Since IrisGL does not support lmcolor for back-sided materials, this could have caused front-sided materials to use an improper lmcolor mode. Intersection caching for non-indexed quads was broken and could case a core dump when intersection with pfGeoSets of this type. pfGetCurState returned a pfGeoState which was the top of the state stack rather than the current pfState. pfGetCurGState returned a pfGeoState which was the top of the state stack rather than the most recently applied pfGeoState. "libpf" Perhaps the most heinous bug in 1.0, pfInitGfx on RealityEngines would call lsetdepth(0x0, 0x0), essentially disabling zbuffering. combinLODs() in the MultiGen .flt converter (in file hier.c) did not set the LOD center of combined LODs. This would result in strange LOD behavior for LODs which were not modelled about the origin. pfClone()'ed pfSequences were not updated by pfFrame so they essentially did not work. Intersections with pfSequences could sometimes turn them off (PFSEQ_STOP). collide.c was shipped with a hardwired intersection mode which turned off intersection caching, substantially reducing intersection performance. pfFlatten()'ed pfLightPoints were broken for multiprocessing modes when the application and cull processes were separate. From guest Wed Feb 2 13:13:04 1994 From: "Michael Jones" Message-Id: <9402021313.ZM2054@babar.asd.sgi.com> Date: Wed, 2 Feb 1994 13:13:02 -0800 In-Reply-To: "Scott Davidson" "1.0 to 1.1 compatability" (Feb 2, 2:01pm) References: <9402021955.AA05477@sgi.sgi.com> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: "Scott Davidson" , "info-performer" Subject: Re: 1.0 to 1.1 compatability Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Feb 2, 2:01pm, Scott Davidson wrote: > Subject: 1.0 to 1.1 compatability :We're working with the University of Pennsylvania to build a Performer :loader of Peabody geometry. This "Peabody" is a file format? (or is it Mr. Peabody of Sherman and Peabody fame ;-) :The loader is fairly basic but we're :concerned about loader compatability between Performer 1.0 and 1.1. :Are there any show-stoppers between 1.1 and 1.0 that we should be :worried about. There were no changes of note between 1.0 and 1.1; certainly none that would effect geometry. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Thu Feb 3 02:22:31 1994 Date: Thu, 3 Feb 94 02:23:54 -0800 From: goetzjr@gravy3.cs.nps.navy.mil (john goetz) Message-Id: <9402031023.AA20662@gravy3.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: pfCylinders I am trying to model circular foot pads on uneven terrain. I create several segments extending from the bottom of the foot pad, all of which are long enough to always intersect with the ground. I then call: pfCylAroundSegs(cyl, segment, nsegs); and change the parameters of the pfCylinder as follows: pfSetVec3(cyl->center, foot_data[leg].foot_xyz[2], foot_data[leg].foot_xyz[0], foot_data[leg].foot_xyz[1]); // conversion from GL coordinates cyl->halfLength = 3.0f; cyl->radius = 22.5f; The halfLength puts the end of the pfCylinder at the bottom of the foot pad. I then perform the intersection testing: /* find intersection with terrain */ isect = pfSegsIsectNode(G_dirt, segment, nsegs, PFTRAV_IS_PRIM| PFTRAV_IS_CULL_BACK|PFTRAV_IS_NORM, TERRAIN_MASK, cyl, result, NULL); hoping that the pfCylinder will tell me when the foot pad touches the ground, then using the "result" data to contour the foot pad to the ground. When contact was detected the data was as follows: ground height 0.50 cyl center 195.424 -109.000 12.585 cyl axis 0.000 0.000 -1.000 cyl radius 22.500 cyl halflength 3.000 The bottom of the pfCylinder should be at 9.585 which should not be intersecting with the ground yet. Can somebody please explain? Thank You. John Goetz goetzjr@cs.nps.navy.mil From guest Thu Feb 3 09:58:46 1994 Message-Id: <9402031758.AA14808@surreal.asd.sgi.com> Date: Thu, 3 Feb 94 10:18:28 EST From: mwilliam@ldsa.com (Micheal J. Williams) Subject: Static backgrounds (fwd for mwilliam@ldsa.com) To: info-performer@sgi.sgi.com I need to know if there is a way to draw static background with GL and let Performer handle moving models without requiring me to redraw the background every frame. I have a dataset composed of evenly spaced elevation posts. I display this elevation data as either wire frame, or shaded polgons during the draw callback. I load flight format models into Performer, and let it manage those. Currently, I am redisplaying my terrain with each frame. The dataset is 500x500 posts, and this display is taking most of my time. I was hoping to find some way of drawing this terrain only once (since it does not move reletive to the eyepoint), but have just the models redrawn every frame. I originally wanted to load the terrain matrix into either a geoset, or geode but I had very little luck doing so. I am working on an Indigo2 Extreme running Performer 1.0. I am writing my code in Ada (serious pain), but I would actually prefer replies using 'C'. Thanks Mike Williams mwilliam@ldsa.com From guest Fri Feb 4 00:11:10 1994 Return-Path: Message-Id: <9402040602.AA07986@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Subject: Re: Performer 1.2 and Softimage In-Reply-To: Your message of "Thu, 20 Jan 1994 14:57:18 PST." <9401201457.ZM18105@babar.asd.sgi.com> Cc: hasimoto@iml.mkhar.sharp.co.jp Date: Fri, 04 Feb 1994 15:02:29 +0900 From: Takeshi Hashimoto Status: OR Oh... I've read just now the mails about Softimage.... We are using Softimage and Performer. I made simple Softimage loader to Performer, by modifying Softimage DKit. It can read only triangulated meshes. I think reading triangulated mesh data is easy, but reading texture,material and animation data is difficult. Anyone who are interested in reading Softimage datas to Performer, please mail me or this mailing list. I want more information to make the loader powerful. --- //\\ (O O) \o/ hasimoto@iml.mkhar.sharp.co.jp WOW From guest Fri Feb 4 13:03:54 1994 Date: Fri, 4 Feb 1994 13:04:32 -0800 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199402042104.NAA06929@mail.netcom.com> To: info-performer@sgi.sgi.com Subject: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ??? Cc: mdgood@netcom.com, ptinker@netcom.com, vmatt@netcom.com Status: OR Performers, We currently run different versions of Performer on different IRIS hosts (on my main workstation I have 1.2 beta installed with 1.0 sitting in separate directories, e.g., /usr/include/Performer_1_0, etc.). Also, we may soon be using different SGI hosts running different IRIX versions. I've been trying to find a clean way to identify what version of IRIX and what version of Performer I am compiling/linking from and executing from for use in Imakefiles and compiler #ifdef's. Up until recently I did this by manually editing my Imakefiles or Makefiles. I was hoping there might be some default environment variables set, or some global pre-processor define's a la __sgi, __unix, host_mips, etc. For the IRIX version I realize I can do something cute with "uname" in my .cshrc file to set my own env. variable that will tell me what version of IRIX I'm running, e.g.: setenv __IRIX_VERSION `uname -r` With a little further kludgey processing I can fix up this env. variable to use in Imakefiles and #define's for C or C++ files (note, cpp #ifdef's can only use integer values not something like 4.0.5). But, I'd rather not rely on expecting a login user to have such a .cshrc kludge. Is there something better? As far as Performer versions, I've thought of a couple of hacks. One is to use some #define'd value that's declared in version 1.2 but not in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in Imakefiles and source files. Alternately, I though of another kludge such as, set pf_vers_date \\`grep Date /usr/include/Performer/pf.h` setenv __PF_VERSION `echo $pf_vers_date[2]` For now I'm requiring myself to explicitly use a -D on my imake command line that I test for in the Imakefile which creates a compiler -D define in my Makefile that I can test for in my source code (whew!!!). This also seems risky and depends on explicit user action rather than something built in. Is there something better? Lew Hitchner Xtensory Inc. Scotts Valley, CA From aschaffe Fri Feb 4 19:28:47 1994 From: aschaffe (Allan Schaffer) Message-Id: <9402041928.ZM18173@holodeck.asd.sgi.com> Date: Fri, 4 Feb 1994 19:28:46 -0800 In-Reply-To: hitchner@netcom.com (Lew Hitchner) "IRIX and Performer version nos. for Makefiles and compiler #ifdefs ???" (Feb 4, 1:04pm) References: <199402042104.NAA06929@mail.netcom.com> X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: hitchner@netcom.com (Lew Hitchner) Subject: Re: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ??? Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Feb 4, 1:04pm, Lew Hitchner wrote: > As far as Performer versions, I've thought of a couple of hacks. One > is to use some #define'd value that's declared in version 1.2 but not > in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in > Imakefiles and source files. Alternately, I though of another kludge > such as, > > set pf_vers_date \\`grep Date /usr/include/Performer/pf.h` > setenv __PF_VERSION `echo $pf_vers_date[2]` In 1.2's /usr/include/Performer/pr.h there is defined: #define PF_MAJOR_VERSION 1 #define PF_MINOR_VERSION 2 That will at least distinguish 1.2 from 1.0/1.1, and I expect it to stick around for later releases too. Offhand I can't think of an easy way to distinguish 1.0 from 1.1.. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Mon Feb 7 02:38:04 1994 Date: Mon, 7 Feb 94 11:42:02 +0100 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9402071042.AA20826@scl> To: info-performer@sgi.sgi.com Subject: Performer & TDI Explore Status: OR Bonjour ... Is there anybody trying to use TDI explore 3.02 scene and data base in Performer or interrested in ? (same question with Inventor !) Merci et bienvenue ------------------------------------------------------------------------------ = Cedric GAUTIER - SYSECA (SDA) a Thomson Company - Tel: (33)(1) 49 11 75 47 = = 315 Bureaux de la Colline 92213 St-Cloud FRANCE - Fax: (33)(1) 49 11 71 10 = = Virtual Image Group (3D Simulation/Virtual Reality) - email: gce@syseca.fr = ------------------------------------------------------------------------------ From guest Mon Feb 7 09:02:21 1994 Message-Id: <9402071633.ZM11368@unknown.zmail.host> Date: Mon, 7 Feb 1994 16:33:12 +0000 In-Reply-To: "Richard Gallery" "Re: Performer problem" (Jan 7, 9:31am) References: g<755350832WedGMT@gallery> <9401070931.ZM14006@unknown.zmail.host> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: dxf format Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi My reason for asking about dxf format is that I have got some 3D models, not designed in Autocad, which can be written to dxf. Also, I have been told that there will be a dxf file format loader for Performer quite soon. So I would appear to have a quick route from my models to dxf to Performer. However if dxf has basic limitations like not knowing about texture, or material specification, or has an incomplete colour space, then I don't want to know about it (I can write my own converter anyway in that case). Any information you have would be useful. I have looked at an Aoutocad manual, but it is several years old, and in any case I have the impression of being overwhelmed with information that does'nt appear relevant from reading it. Thanks Richard Galelry From guest Mon Feb 7 11:36:14 1994 Message-Id: <9402071936.AA19954@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com Subject: Re: Static backgrounds (fwd for mwilliam@ldsa.com) In-Reply-To: Your message of "Thu, 03 Feb 94 10:18:28 EST." <9402031758.AA14808@surreal.asd.sgi.com> Date: Mon, 07 Feb 94 11:36:04 -0800 From: Jim Helman > I need to know if there is a way to draw static background with > GL and let Performer handle moving models without requiring me to redraw > the background every frame. One way to do this is to keep a copy of the rendered scene, including Z, in another buffer, e.g. the left stereo buffer, and then do a rectcopy() to blat it do your working buffer where you render the models. In Performer, you'd use the draw process callbacks for issuing the GL commands to make this happen. For best performance, you need the rectcopy source and destination positions to be the same (hence the use of a coincident buffer) but I think the Z copy rate may still limit you to a relatively low frame rate (20Hz?) unless the window is fairly small. srf knows more about this than I do. Perhaps, she'll comment. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Feb 8 11:17:36 1994 From: Steve Elkins Message-Id: <199402081917.LAA13724@eos.arc.nasa.gov> To: info-performer@sgi.sgi.com Status: OR To : info-performer From : S. Elkins Subject : Machine hang and logout. We are running a flight simulation based on the perfly demo from Performer 1.0/1.1. The simulation is running on a 2cpu ONYX RE2 with 2 rm boards, and IRIX 5.1.1.3. The problem is that after a random amount of time, anywhere from a few seconds to several hours, the graphics lock up and the system logs us out. The SYSLOG shows either : unix: WARNING: RE pipe 0: FIFO timeout - or - unix: WARNING: RE pipe 0: lightweight deactivation timed out when the hang/logout problem occurs. We have two ONYX systems and this problem occurs on both of them. Is this a problem with Performer 1.0/1.1 or something else? Has anyone else had a problem with systems locking up? Thanks for any information reguarding this problem. S. Elkins spelk@eos.arc.nasa.gov Sterling Software - NASA Ames Division From guest Tue Feb 8 17:16:20 1994 From: "Sharon Fischler" Message-Id: <9402081716.ZM2597@rose.asd.sgi.com> Date: Tue, 8 Feb 1994 17:16:10 -0800 In-Reply-To: Steve Elkins "" (Feb 8, 11:17am) References: <199402081917.LAA13724@eos.arc.nasa.gov> X-Mailer: Z-Mail (3.1b.0 21jan94 MediaMail) To: Steve Elkins , info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR +>---- On Feb 8, 11:17am, Steve Elkins wrote: > Subject: onyx hang problem ->To : info-performer ->>From : S. Elkins ->Subject : Machine hang and logout. -> ->We are running a flight simulation based on the perfly demo from ->Performer 1.0/1.1. The simulation is running on a 2cpu ONYX RE2 with ->2 rm boards, and IRIX 5.1.1.3. -> ->The problem is that after a random amount of time, anywhere from a few ->seconds to several hours, the graphics lock up and the system logs us out. ->The SYSLOG shows either : -> ->unix: WARNING: RE pipe 0: FIFO timeout - or - ->unix: WARNING: RE pipe 0: lightweight deactivation timed out -> ->when the hang/logout problem occurs. We have two ONYX systems and this ->problem occurs on both of them. Good information. It would also be helpful to know 1) does this only happen when you run as root? 2) are you doing anything to isolate CPUs? 3) the output of hinv Thanx! srf. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Tue Feb 8 18:42:35 1994 Message-Id: <9402090244.AA21429@Crazypete.AI.SRI.COM> To: "Sharon Fischler" Cc: Steve Elkins , info-performer@sgi.sgi.com In-Reply-To: Your message of "Tue, 08 Feb 1994 17:16:10 PST." <9402081716.ZM2597@rose.asd.sgi.com> Date: Tue, 08 Feb 1994 18:44:17 -0800 From: Stephen Lau Status: OR ->The problem is that after a random amount of time, anywhere from a few ->seconds to several hours, the graphics lock up and the system logs us out. ->The SYSLOG shows either : -> ->unix: WARNING: RE pipe 0: FIFO timeout - or - ->unix: WARNING: RE pipe 0: lightweight deactivation timed out -> We have a 4 process Onyx 4E2 and we had a similar problem. The fix was to upgrade our boards to the latest rev. Hope this helps. Upgrading to the latest version of IRIX, 5.1.1.3 or 5.2 didn't help. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "No, no, not Orwellian, HUXLEY! SRI International | Brave New World." 333 Ravenswood Ave., Menlo Park, CA. 94025| - George Coates, "Box Conspiracy: (415) 859-2925 (415) 326-6200| An Interactive Sho" ------------------------------------------------------------------------------- From guest Tue Feb 8 20:08:03 1994 From: "Wade Olsen" Message-Id: <9402082008.ZM5928@fnord.asd.sgi.com> Date: Tue, 8 Feb 1994 20:08:00 -0800 In-Reply-To: aschaffe@holodeck (Allan Schaffer) "Re: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ???" (Feb 4, 7:28pm) References: <199402042104.NAA06929@mail.netcom.com> <9402041928.ZM18173@holodeck.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: aschaffe (Allan Schaffer), hitchner@netcom.com (Lew Hitchner) Subject: Re: IRIX and Performer version nos. for Makefiles and compiler #ifdefs ??? Cc: info-performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Feb 4, 7:28pm, Allan Schaffer wrote: > Subject: Re: IRIX and Performer version nos. for Makefiles and compiler #i > On Feb 4, 1:04pm, Lew Hitchner wrote: > > As far as Performer versions, I've thought of a couple of hacks. One > > is to use some #define'd value that's declared in version 1.2 but not > > in version 1.0, e.g., PFMP_CULLoDRAW, and then test via #ifdef in > > Imakefiles and source files. Alternately, I though of another kludge > > such as, > > > > set pf_vers_date \\`grep Date /usr/include/Performer/pf.h` > > setenv __PF_VERSION `echo $pf_vers_date[2]` > > In 1.2's /usr/include/Performer/pr.h there is defined: > > #define PF_MAJOR_VERSION 1 > #define PF_MINOR_VERSION 2 > > That will at least distinguish 1.2 from 1.0/1.1, and I expect it to > stick around for later releases too. Offhand I can't think of an > easy way to distinguish 1.0 from 1.1.. > > Allan > > > -- > Allan Schaffer > Silicon Graphics > aschaffe@sgi.com > >-- End of excerpt from Allan Schaffer In the makefile you can have this to tell if your on irix4.* or irix5.* and set flags accordingly. #if SVR4 # Its IRIX5... #else # Its IRIX4... #endif -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Wed Feb 9 06:18:39 1994 From: kotto@caeg.rmi.de Date: Wed, 9 Feb 94 14:31:45 +0100 Message-Id: <9402091331.AA02803@caeg> To: srf@sgi.sgi.com Subject: Machine hang and logout Cc: info-performer@sgi.sgi.com, spelk@eos.arc.nasa.gov, lau@ai.sri.com Reply-To: kotto%caeg.uucp@Germany.EU.net > ->unix: WARNING: RE pipe 0: FIFO timeout - or - > ->unix: WARNING: RE pipe 0: lightweight deactivation timed out > > We have a 4 process Onyx 4E2 and we had a similar problem. The fix > was to upgrade our boards to the latest rev. Hope this helps. Upgrading > to the latest version of IRIX, 5.1.1.3 or 5.2 didn't help. Upgrading to the latest rev level didn't help on our Onyx. Yesterday we got a new GE10 and the logout still occurs. gfxinfo tells us : 12 GE (GE10 rev. 0x7/011) 4 RM4 boards (rev. 00112/00112/00112/00112) According to our local SGI tech support this is the latest rev. Currently we run only Performer based programmes on this machine. I can not tell whether any pure GL progam could do the same. We don't run as root and don't isolate processors. Klaus ---------------------------------- | Klaus Otto, CAE Electronics GmbH | | kotto%caeg.uucp@Germany.EU.net | ---------------------------------- From guest Wed Feb 9 05:53:09 1994 id AA12750; Wed, 9 Feb 94 08:51:02 EST Message-Id: <9402091351.AA12750@cvbnet.CV.COM> From: Gregory Smith x4431 5-2 Subject: Re: onyx hang To: srf@rose (Sharon Fischler) Date: Wed, 9 Feb 94 8:50:08 EST Cc: info-performer@sgi.sgi.com In-Reply-To: <9402081716.ZM2597@rose.asd.sgi.com>; from "Sharon Fischler" at Feb 8, 94 5:16 pm Mailer: Elm [revision: 70.85] Status: OR > > +>---- On Feb 8, 11:17am, Steve Elkins wrote: > > Subject: onyx hang problem > ->To : info-performer > ->>From : S. Elkins > ->Subject : Machine hang and logout. > -> > ->We are running a flight simulation based on the perfly demo from > ->Performer 1.0/1.1. The simulation is running on a 2cpu ONYX RE2 with > ->2 rm boards, and IRIX 5.1.1.3. > -> > ->The problem is that after a random amount of time, anywhere from a few > ->seconds to several hours, the graphics lock up and the system logs us out. > ->The SYSLOG shows either : > -> > ->unix: WARNING: RE pipe 0: FIFO timeout - or - > ->unix: WARNING: RE pipe 0: lightweight deactivation timed out > -> > ->when the hang/logout problem occurs. We have two ONYX systems and this > ->problem occurs on both of them. > We had the same issue with our onyx. The problem was caused by a bad ( out of rev ) RM4 board. Ask to have your board levels checked and replaced if necessary. From guest Thu Feb 10 05:13:07 1994 Message-Id: <9402101301.ZM17856@unknown.zmail.host> Date: Thu, 10 Feb 1994 13:01:02 +0000 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: 3D Studio Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi Are there any plans to do a 3DS (from Autodesk) loader for Performer. I have some 3DS models that I would like to read into a Performer application. I have approached Autodesk about access to the file format, but they appear reluctant to release this (I appreciate the need to guard proprietary information). So, anyone else done this/thinking of it, any feedback would be appreciated. Thanks Richard Gallery From guest Thu Feb 10 07:30:55 1994 Date: Thu, 10 Feb 94 10:29:37 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9402101529.AA05760@ldsa.com> To: info-performer@sgi.sgi.com I noticed a comment in the code of complex.c which says: /* * These enables should be set to reflect to majority of the * database. If modt geometry is not textured, then texture * should be disabled. However, you then need to change the * FLIGHT-format file reader. (pfflt.c) */ In my database, none of my flight format models are textured. What performance increase could I get by making this modification? Has anybody done this? I have not meddled in the workings of pfflt.c. Does this require a lot of work, or just a change to a pfEnable call? Thanks Mike Williams LORAL Defense Systems mwilliam@ldsa.com From guest Thu Feb 10 08:39:43 1994 Message-Id: <9402101639.AA22708@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Feb 1994 11:40:07 -0500 To: info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: DEM, DLG data and Performer Has anyone written a converter/loader for DEM data or DLG data from the USGS? I am fairly new to the data and to performer so I don't know exactly what would be required or even if it is possible to directly load DEM data into performer. If not, is anyone familiar with programs for the SGI that allow you to view and explore the DEM data? Explorer might be a possibility, but I don't know very much about Explorer either. Any ideas or suggestions? Thanks, John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From guest Thu Feb 10 11:35:55 1994 Date: Thu, 10 Feb 94 16:55:47 GMT From: arnaud@thomson-dsi.fr (AST ) Message-Id: <9402101655.AA04385@thodsic.cergy.thomson-dsi.fr> To: info-performer@sgi.sgi.com Subject: 3D Studio Hello, > Are there any plans to do a 3DS (from Autodesk) loader for Performer ... It is possible to get from Autodesk a 3DS toolkit (include files + libraries). (Autodesk will ask you to sign a confidential agreement first ! ). This toolkit provides C function calls to create 3DS files. There is unfortunately no API for reading 3DS files. This would be of little use, but there is a hack: the documentation that comes with the toolkit describes how a 3DS binary file is structured and how information is stored. You can therefore write your own routines to extract the information you need and convert it to Performer geosets. If there is a easier way, please let us know... ---------------------------- Christophe Delepine arnaud@cergy.thomson-dsi.fr THOMSON-CSF PARIS ---------------------------- From aschaffe Sat Feb 12 06:21:59 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9402120621.ZM17689@holodeck.asd.sgi.com> Resent-Date: Sat, 12 Feb 1994 06:21:59 -0800 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) Resent-To: info-performer-dist Message-Id: <199402121410.PAA05836@sgi_nils.cmr.no> X-Authentication-Warning: sgi_nils.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: sgi_nils.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Subject: pfDelete.... Date: Sat, 12 Feb 1994 15:10:50 +0100 From: Nils Thune Part of my scene consist of a pfGeode with a gset. The vertices, colors and normals in the gset has been allocated with pfMalloc(..., NULL); and added to the gset with pfGSetAttr(...); When I call pfDelete(myGeode); will it deallocate the gset itself and all the memory used by the user supplied vertices, colors and normals (allocated by pfMalloc(...), and hence should have a ref count)? Or, do I have to add a pfDeleteFunc to gset which then should delete verices, etc.? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Mon Feb 14 11:20:57 1994 Date: Mon, 14 Feb 1994 09:28:48 -0800 (PST) From: Michael Macedonia Subject: performer crash on crimson To: info-performer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Having problems running an app using performer 1.0 on a Crimson RE. It crashes every time. Runs fine on our challenge machines, Indigos, etc. Question: are there any known problems running performer on Crimson's ? Thanks, Mike Macedonia From aschaffe Tue Feb 15 04:20:07 1994 From: aschaffe (Allan Schaffer) Message-Id: <9402150404.ZM27438@holodeck.asd.sgi.com> Date: Tue, 15 Feb 1994 04:04:25 -0800 In-Reply-To: Michael Macedonia "performer crash on crimson" (Feb 14, 9:28am) References: X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: Michael Macedonia Subject: Re: performer crash on crimson Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Feb 14, 9:28am, Michael Macedonia wrote: > > Having problems running an app using performer 1.0 on a Crimson RE. > It crashes every time. Runs fine on our challenge machines, Indigos, etc. > > Question: are there any known problems running performer on Crimson's ? There aren't any general incompatibilities with Crimsons. Being a Crimson RE, I assume you're running IRIX 4.0.5G or H. Do you get any error or warning messages? (in the shell, console window, or /usr/adm/SYSLOG) There are a few bugs that could cause core dumps in 1.0, (pfFlatten on a zero-length pfGeoSet, intersections with pfSwitches that were "off", and intersections with non-indexed quads). The FAQ list hasn't been updated for a while, but it does contain a list of all the bugs I knew of when it was put together. Also, the libgl on each of the Indigo-series machines is wildly different than the libgl for RE, so you should verify that you are compiling with the shared libraries. (both performer and libgl). Or, try compiling on the Crimson. I couldn't quite infer from your message whether the crash was the application or the entire graphics pipe -- if the latter, a test case to the hotline would be the fastest way to get bugs filed & track it down. If the application is crashing, a stack trace from dbx would be the way to go. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Feb 17 07:06:14 1994 Date: Thu, 17 Feb 94 08:32:49 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9402171332.AA02011@ldsa.com> To: info-performer@sgi.sgi.com Has anybody done any work in developing a way to load DTED elevation into Performer? I have elevation tiles which are very similar to DTED which I need to load. John Templeton at SGI thought that it was very likely that this work would have been done already. If anyone has done this, I would be interested in seeing how it was done. Along with this, I need to model a lighthouse type rotating light. I am using Performer 1.0 on an Indigo2 Extreme, so I don't have the pfLightSource from the 1.2 beta version. I have not been hiving much luck in modeling local light sources. Again, I would appreciate any advice on how this may best be accomplished. Thanks Mike Williams mwilliam@ldsa.com From guest Thu Feb 17 23:48:33 1994 From: Robert Webb Message-Id: <199402180748.AA14301@godzilla.cgl.citri.edu.au> Subject: Performer questions To: info-performer@sgi.sgi.com Date: Fri, 18 Feb 1994 18:48:21 +1100 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2181 Howdy all, I have a few Performer questions for anyone who feels like helping out: - The Performer documentation we have describes a function pfGlobalGState(), but this function does not seem to actually exist (and there is no prototype for it in the header file). How do I set up global pfGeoState defaults without it? - In one of our applications at least, the culling does not work properly. Objects suddenly vanish before they leave the viewing frustrum. Any ideas why this could be? We are not changing any of the GeoSets or other data in the hierarchy after it has been initially set up. - I've read the pfLight man page and I'm still not sure how to position lights properly. It says that for lights like the sun, which have a fixed position in the world, pfLightOn() should be called every frame with only the viewing transformation on the matrix stack. I understand the concept, but how do I actually do it? Performer does all the drawing and transformations for you so do I need some sort of call-back to call pfLightOn() at the right moment? If I set up lights in a pfGeoState with: pfGStateAttr(gstate, PFSTATE_LIGHTS, lights); and associate this with a pfGeoSet, then is that the same as using pfLightOn() with the modelling transformations for that GeoSet on the stack? That is, will the lights then move with the object like lights on a car? Or does this simply use the lights but not affect their position? Do you still need to call pfLightOn()? Again I would like to use pfGlobalGState() to define global non-moving lights, but this is unavailable. - Ultimately it would be nice if pfGeoStates could be attached to any node, and inherited by children. A pfGroup which holds all the various geometry nodes for an object could then define materials etc. for all its children, without each pfGeoSet having to do this itself to override the global state. Does every little pfGeoSet really need its own pfGeoState? If so, is this efficient provided consecutive children use the same pfGeoState? Many thanks to anyone who answers any of these questions. -- Rob. (webb@godzilla.cgl.citri.edu.au) From guest Fri Feb 18 05:03:55 1994 Date: Fri, 18 Feb 94 13:03:02 GMT Message-Id: <223.9402181303@prsun11z.prl.philips.co.uk> To: info-performer@sgi.sgi.com Subject: 3D studio to IRIS Performer ? Status: OR Hi there! I want to read 3D studio format files into IRIS Performer. Does anyone now what's the best way of doing that? Has anyone tried it already? Please send your comments to: ukrsefe@prl.philips.co.uk Thanx! Dr. Vassilis Seferidis From guest Fri Feb 18 09:09:52 1994 Date: Fri, 18 Feb 94 09:10:04 -0800 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9402181710.AA16892@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: RE: Performer questions On Fri, 18 Feb 1994 18:48:21 +1100 (EDT) Robert Webb writes: >- In one of our applications at least, the culling does not work properly. > Objects suddenly vanish before they leave the viewing frustrum. Any ideas > why this could be? We are not changing any of the GeoSets or other data in > the hierarchy after it has been initially set up. I assume you are using Performer 1.0 because we had the same problem. Ours occurred when we scaled a pfDCS with pfDCSScale. This was useful for instancing our data set. A once-defined box from a procedure for creating pfGeoSets could be scaled to the particular task. Some of our boxes vanished before the edge of our frustum. We tested and found that the problem got worse with more scaling. On Fri, 16 Jul 93 18:41:18 -0700 Jim Helman writes: > There is a culling bug for scaled DCSes > which was fixed in Release 1.1. 1.1 only > was released for IRIX 5.0. Our work-around was to scale the data-points as the pfGeoSet was created. However, in the example coloredbox.c all points are statically defined. Therefore the points must be dynamically allocated: static pfGeoSet *MakePalmGSet( float scale, pfGeoState *gstate) { void *arena; int i; pfVec3 *scaled_scoords; pfGeoSet *gset; static pfVec3 scoords[] = {{-2.00f,-.50f, 3.75f }, { 2.00f,-.50f, 3.75f }, { 2.00f, .50f, 3.75f }, {-2.00f, .50f, 3.75f }, {-1.25f,-.75f, 0.00f }, { 1.75f,-.75f, 0.00f }, { 1.75f, .75f, 0.00f }, {-1.25f, .75f, 0.00f }, { 2.00f,-.68f, 1.00f }, { 2.00f, .68f, 1.00f }}; static ushort svindex[] = {0, 1, 2, 3, /* front */ 0, 3, 7, 4, /* left */ 4, 7, 6, 5, /* back */ 1, 8, 9, 2, /* right */ 8, 5, 6, 9, /* right/bottom */ 3, 2, 6, 7, /* top */ 0, 4, 5, 1}; /* bottom */ static pfVec3 snorms[] = {{ 0.000f, 0.000f,-1.000f}, { 0.981f, 0.000f, 0.196f}, { 0.000f, 0.000f, 1.000f}, {-1.000f, 0.000f, 0.000f}, {-0.707f, 0.000f, 0.707f}, { 0.000f,-0.998f,-0.067f}, { 0.000f, 0.998f,-0.067f}}; static ushort snindex[] = {0, 1, 2, 3, 4, 5, 6}; static ushort scindex[] = {20, 20, 20, 20, 20, 20, 10, 0, 0, 10, 10, 0, 20, 5, 15, 20, 5, 0, 10, 15, 20, 20, 10, 10, 20, 0, 0, 20}; arena = pfGetSharedArena(); scaled_scoords = (pfVec3 *)pfMalloc( sizeof( pfVec3[8] ), arena ); for( i = 0; i < 8; i++ ) PFSCALE_VEC3( scaled_scoords[i], scale, scoords[i] ); gset = pfNewGSet( arena ); pfGSetCtabMode( gset, PF_ON ); pfGSetAttr( gset, PFGS_COORD3, PFGS_PER_VERTEX, scaled_scoords, svindex ); pfGSetAttr( gset, PFGS_NORMAL3, PFGS_PER_PRIM, snorms, snindex ); pfGSetAttr( gset, PFGS_COLOR4, PFGS_PER_VERTEX, NULL, scindex ); pfGSetPrimType( gset, PFGS_QUADS ); pfGSetNumPrims( gset, 7 ); pfGSetGState( gset, gstate ); return( gset ); } Hope this is useful. Of course 1.2 (hopefully) comes out in March and all of this will be obsolete. :^) From guest Sun Feb 20 15:30:17 1994 From: Robert Webb Message-Id: <199402202329.AA18526@godzilla.cgl.citri.edu.au> Subject: Re: Performer questions To: info-performer@sgi.sgi.com Date: Mon, 21 Feb 1994 10:29:50 +1100 (EDT) In-Reply-To: <9402181710.AA16892@niesten.arc.nasa.gov> from "William Briggs" at Feb 18, 94 09:10:04 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1359 > On Fri, 18 Feb 1994 18:48:21 +1100 (EDT) > Robert Webb writes: > > >- In one of our applications at least, the culling does not work properly. > > Objects suddenly vanish before they leave the viewing frustrum. Any ideas > > why this could be? We are not changing any of the GeoSets or other data in > > the hierarchy after it has been initially set up. > > I assume you are using Performer 1.0 because we had the same problem. > Ours occurred when we scaled a pfDCS with pfDCSScale. This was useful > for instancing our data set. A once-defined box from a procedure for > creating pfGeoSets could be scaled to the particular task. Some of our > boxes vanished before the edge of our frustum. We tested and found that > the problem got worse with more scaling. > > On Fri, 16 Jul 93 18:41:18 -0700 > Jim Helman writes: > > > There is a culling bug for scaled DCSes > > which was fixed in Release 1.1. 1.1 only > > was released for IRIX 5.0. Thanks for the advice, but we aren't using any pfDCS nodes at all! Only pfSCS nodes. We are using Performer 1.0 though. Is there an easy way to show the bounding boxes in performer? Or does anyone have code to do this? Maybe the boxes somehow aren't being created correctly, but this seems unlikely. -- Rob. (webb@godzilla.cgl.citri.edu.au) From guest Mon Feb 21 02:31:25 1994 Message-Id: <9402211031.AA01045@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Re: Performer questions In-Reply-To: Your message of "Mon, 21 Feb 94 10:29:50 +1100." <199402202329.AA18526@godzilla.cgl.citri.edu.au> Date: Mon, 21 Feb 94 02:31:19 -0800 From: Jim Helman > > On Fri, 16 Jul 93 18:41:18 -0700 > > Jim Helman writes: > > > > > There is a culling bug for scaled DCSes > > > which was fixed in Release 1.1. 1.1 only > > > was released for IRIX 5.0. > > Thanks for the advice, but we aren't using any pfDCS nodes at all! > Only pfSCS nodes. pfSCSes were affected as well, but for performance, are usually pfFlattened out of the scene graph by run time. Generally, it's best to avoid run-time scales, especially non-uniform ones, becuase they require rescaling or renormalization of normals in the gfx pipe. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Feb 23 03:36:30 1994 Date: Wed, 23 Feb 94 13:35:26 +0200 From: rany@bvr.co.il (Ran Yakir) Message-Id: <9402231135.AA01002@rea1.bvr.co.il> To: info-performer@sgi.sgi.com Subject: draw callbacks bug in performer 1.2 Hi I'm using Performer 1.2 beta, and experiencing the following problem : When assigning a post draw callback for a node, without assigning a pre draw callback (sending NULL), the post draw callback is called at the beginning of the pfDraw, regardless of everything, and before the actual drawing of that node take place. When assigning both post draw and pre draw callbacks, everything works fine. Are you aware of that ? I can compose a small example if needed. Thanks Ran Yakir __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Wed Feb 23 09:44:53 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9402231744.AA03320@tubes.asd.sgi.com> Subject: Re: draw callbacks bug in performer 1.2 To: guest (Ran Yakir) Date: Wed, 23 Feb 94 9:44:38 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9402231135.AA01002@rea1.bvr.co.il>; from "Ran Yakir" at Feb 23, 94 1:35 pm X-Mailer: ELM [version 2.3 PL8] > > Hi > > I'm using Performer 1.2 beta, and experiencing the following problem : > When assigning a post draw callback for a node, without assigning a > pre draw callback (sending NULL), the post draw callback is called at the > beginning of the pfDraw, regardless of everything, and before the actual > drawing of that node take place. > When assigning both post draw and pre draw callbacks, everything works fine. > Are you aware of that ? > I can compose a small example if needed. > Which beta do you have? I believe this bug has been fixed in the latest beta which is 94. Sorting was only disabled if you had a preDraw callback. A simple workaround is to assign a dummy preDraw callback or to install the newest beta. From guest Fri Feb 25 08:56:25 1994 From: Renee Strong Message-Id: <9402251656.AA06101@pat.mdc.com> Subject: bounding boxes To: info-performer@sgi.sgi.com Date: Fri, 25 Feb 94 10:56:13 CST X-Mailer: ELM [version 2.3 PL11] I have performer 1.0 running on a personal IRIS. If I understand the documentation right, using pfNodeBBox with the pfBox NULL and the matrix NULL should have performer create a bounding box for me. I am getting back all zeros in the pfBox structure. I am trying to get performer to create a bounding box around a pfGeode. The pfGeode is not attached to a pfDCS or anything else for that matter. What am I doing wrong??? pfGeode *geode; pfBox *bbox = NULL; geode = loadModel(); if (!geode) return(NULL); pfNodeBBox(geode, bbox, NULL, PFN_BMODE_STATIC); cout << "bbox->min:"<min[0]<min[1]<min[2]<<"\n"; cout << "bbox->max:"<max[0]<max[1]<max[2]<<"\n"; Thanks Renee Strong renee@pat.mdc.com From guest Tue Mar 1 06:36:30 1994 From: Bernd Froehlich Message-Id: <9403011337.AA07820@viswiz.gmd.de> Subject: point in bounding volume test To: info-performer@sgi.sgi.com Date: Tue, 1 Mar 94 15:37:19 MET Status: OR two questions: 1. what is the best way to do a point in bounding box/bounding sphere test with Performer? I have a hierarchical scene graph with DCSs attached to each inner and leaf node. I thought about using pfSegsIsectNode with a zero length segment but I think this won't help because it actually computes the intersection of the line segment with the bounding spheres or triangles. And if the line segment is a point it will never return an intersection. 2. We are working on a stereo-application using quad buffers. There are two channels attached to a pipe which are linked together as a channel group. The draw callback switches left- and rightbuffers. The left and right eye view are set using pfChanViewMat(chanLeft, LeftEyeView); pfChanViewMat(chanRight, RightEyeView); and the frustum by pfMakePerspFrust( chanLeft, xminl, xmaxl, yminl, ymaxl ); pfFrustAspect(chanLeft, PFFRUST_CALC_VERT, TableAspect); pfFrustNearFar( chanLeft, Z_Near, Z_Far ); pfMakePerspFrust( chanRight, xminr, xmaxr, yminr, ymaxr ); pfFrustAspect(chanRight, PFFRUST_CALC_VERT, TableAspect); pfFrustNearFar( chanRight, Z_Near, Z_Far ); The view matrices and frustra are updated for every frame and this seems to be a problem. Everything works fine if pfMultiprocess(PFMP_APPCULLDRAW) or pfMultiprocess(PFMP_APP_CULLDRAW) is set, but using pfMultiprocess(PFMP_DEFAULT) causes a flickering view. The objects are moving correctly only the view is flickering. We kept the view matrices constant which doesn't help. Then we kept the frustra constant, only changing the view matrices which also doesn't help. Only if you keep the viewing matrices and the frustra constant then it works. Seems that the viewing information is not mp safe? It would be possible to keep the viewing matrices constant and to transform the objects into a fixed viewing coordinate system, but the viewing frustra have to be changed for each frame in our application. I had already a short discussion with Michael Jones and he wrote: >This is a multiprocessing problem. Use "passthrough" data and you >will be ok. Look and the pfPassChanData() man page for details on >this. Your data is changing before you use it. Shouldn't be the viewing information automatically copied into passthrough-buffers if I call pfFrame? So is it a bug or not? What should I put into passthrough data? I can't put the pfChannel itself into passthrough data. It is possible to do the stuff with GL-calls and pass-through data inside the draw callback but this is not the way it should be. Bernd bernd@viswiz.gmd.de ------------------------------------------------------------------------- Bernd Froehlich Scientific Visualization Dept. GMD Schloss Birlinghoven D-53757 St. Augustin Germany ------------------------------------------------------------------------- From guest Tue Mar 1 10:35:06 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403011834.AA24698@tubes.asd.sgi.com> Subject: Re: Performer questions To: guest (Robert Webb) Date: Tue, 1 Mar 94 10:34:43 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199402180748.AA14301@godzilla.cgl.citri.edu.au>; from "Robert Webb" at Feb 18, 94 6:48 pm X-Mailer: ELM [version 2.3 PL8] > - The Performer documentation we have describes a function pfGlobalGState(), > but this function does not seem to actually exist (and there is no prototype > for it in the header file). How do I set up global pfGeoState defaults > without it? This is a mistake in the documentation. The routine does not exist. You set up global default by calling normal libpr routines such as pfApplyMtl(), pfEnable() etc. > - In one of our applications at least, the culling does not work properly. > Objects suddenly vanish before they leave the viewing frustrum. Any ideas > why this could be? We are not changing any of the GeoSets or other data in > the hierarchy after it has been initially set up. Print out the scene with pfDebugPrint and make sure your bounding boxes are reasonable. > - I've read the pfLight man page and I'm still not sure how to position lights > properly. It says that for lights like the sun, which have a fixed position > in the world, pfLightOn() should be called every frame with only the viewing > transformation on the matrix stack. I understand the concept, but how do I > actually do it? Performer does all the drawing and transformations for you > so do I need some sort of call-back to call pfLightOn() at the right moment? Call pfLightOn in your draw callback set by pfChanDrawFunc(). > If I set up lights in a pfGeoState with: > pfGStateAttr(gstate, PFSTATE_LIGHTS, lights); > and associate this with a pfGeoSet, then is that the same as using > pfLightOn() with the modelling transformations for that GeoSet on the stack? > That is, will the lights then move with the object like lights on a car? Or > does this simply use the lights but not affect their position? Do you still > need to call pfLightOn()? Yes, Yes, No, No. > Again I would like to use pfGlobalGState() to define global non-moving > lights, but this is unavailable. You do not need this. Just call pfLightOn and you have defined a global non-moving light. > - Ultimately it would be nice if pfGeoStates could be attached to any node, > and inherited by children. A pfGroup which holds all the various geometry > nodes for an object could then define materials etc. for all its children, > without each pfGeoSet having to do this itself to override the global state. > Does every little pfGeoSet really need its own pfGeoState? If so, is this > efficient provided consecutive children use the same pfGeoState? On the surface this seems like a nice concept but it is contrary to Performer doctrine and will never happen. Inheritance in a scene graph causes more problems than it is worth because you have to potentially examine large portions of the scene graph to decide how to draw something. It's like a deep C++ hierarchy where you have to chase a chain of 15 constructors to see what's going on. With the pfGeoSet/pfGeoState combination we know immediately how to draw a chunk of geometry (except for transforms) and we can use this information to efficiently sort geometry by mode and add other optimizations. pfGeoSets can share pfGeoStates at little or no cost. Believe me, the pfGeoSet/pfGeoState combination is pretty damn efficient. From jrohlf@tubes Tue Mar 1 11:25:59 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403011925.AA25209@tubes.asd.sgi.com> Subject: Re: pfDelete.... To: aschaffe (Nils Thune) Date: Tue, 1 Mar 94 11:25:57 PST Cc: info-performer-dist In-Reply-To: <199402121410.PAA05836@sgi_nils.cmr.no>; from "Nils Thune" at Feb 12, 94 3:10 pm X-Mailer: ELM [version 2.3 PL8] > > Part of my scene consist of a pfGeode with a gset. The vertices, colors and > normals in the gset has been allocated with pfMalloc(..., NULL); and added to > the gset with pfGSetAttr(...); > > When I call pfDelete(myGeode); will it deallocate the gset itself and all the > memory used by the user supplied vertices, colors and normals (allocated by > pfMalloc(...), and hence should have a ref count)? Yes. You do not normally need to bother with reference counts. pfMalloc'ed arrays are automatically reference-counted by the pfGeoSet. If an array is referenced by multiple geosets, it will not be deleted until the last geoset which references it is deleted. > > Or, do I have to add a pfDeleteFunc to gset which then should delete verices, > etc.? pfDeleteFunc is only for deleting user data specified by pfUserData. From guest Tue Mar 1 13:41:49 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403012141.AA25676@tubes.asd.sgi.com> Subject: Re: Questions about Perf1.2 To: guest (Marc SIMON Presales support) Date: Tue, 1 Mar 94 13:41:36 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9402021857.ZM814@girl.paris.sgi.com>; from "Marc SIMON Presales support" at Feb 2, 94 6:57 pm X-Mailer: ELM [version 2.3 PL8] > I have some questions about features of GL vs PERFORMER. > > - Is there a way in Performer to manage pagination of texture like > in GL . 1.2 Performer supports the following GL concepts: 1. Texture idle through pfIdleTex() 2. Query whether a texture is loaded or not through pfIsTexLoaded() Other GL features such as subtexload will be supported in the release following 1.2 which will be OpenGL based. Expect sophisticated texture management in 1.3 or 2.0 or whatever we call it. > - For managing the pfLayer i read that Perf1.2 uses > DisplacePolygon, but if i well remember displace polygon modify the Z > value of a polygon by a factor calculated by the use of the polygon > orientation, and this factor is 0.0 if the polygon as its normal oriented > direct to the viewer.So for coplanar polygon in front of the viewer it > will no works fine > Is'it right ??? Is there a way to avoid this ??? This is a correct evaluation of a fundamental flaw in displacepolygon(). The OpenGL version will solve this problem by adding an offset in addition to the scale. Remember that you can use stencil-based decaling in Performer by calling pfLayerMode(layer, PFDECAL_BASE_STENCIL). We may even change the default back to stencil since many people have had problems with displacepolygon-type decaling. > - Is there a way to store informations on every nodes of the > hierarchy ?? In 1.2, all libpr and libpf objects including nodes have a data pointer accessed through pfUserData. Thus you can attach the structure of your choice to any object. > - I heard that Performer sorts the polygons before the drawing to > optimise the graphics (Especially mode transitions).But what kind of > sorting Performer uses .. Is it only to group polygons with the same > textures to avoid Texbind ??? We have a sorting hierarchy that includes sorting by texture but we also sort by matrix, by material, and by transparency. The sorting hierarchy may differ between machines and releases. > - My last question is not especially for Performer guys, in fact > it seems that the GL call "msmask()" is very slow . Is it right ??? I don't know. We use msmask for fade LOD and it doesn't seem to be very slow. Of course the term "slow" is relative to the number of times you call it per frame. From aschaffe Tue Mar 8 09:22:58 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080922.ZM24348@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:22:57 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: Kevin Russo Message-Id: <199403012345.XAA16581@midway> To: info-performer@sgi.sgi.com Subject: Re: Performer questions >> - In one of our applications at least, the culling does not work properly. >> Objects suddenly vanish before they leave the viewing frustrum. Any ideas >> why this could be? We are not changing any of the GeoSets or other data in >> the hierarchy after it has been initially set up. > > Print out the scene with pfDebugPrint and make sure your bounding > boxes are reasonable. I found that for linestrips, anyway, Performer only checks if the first point or so of the lineseg is in the viewing frustum, regardless of the bounding box. Perhaps this little speed enhancing trick is at work in other types of GeoSets? I overcame it by installing a node pre-cull callback like this: node_cull_pre_cb() { pfCullResult(PFIS_ALL_IN); return PFTRAV_CONT; } It was most frustrating to watch my trajectory line segments disappear any time the origin wasn't in view. Kevin From aschaffe Tue Mar 8 09:24:24 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080924.ZM24355@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:24:24 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Wed, 2 Mar 94 10:51:18 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9403021551.AA15802@cae.ca> To: info-performer@sgi.sgi.com Subject: Perf. on PIs A quick question: will Performer run on a 4D/35? (I guess it depends at least in part on whether IRIX 4.x can be installed on a PI). ------------------------------------------------------------------ J.F. Richard jfr@cae.ca CAE Electronics Ltd Montreal, Canada ------------------------------------------------------------------ From aschaffe Tue Mar 8 09:24:34 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080924.ZM24361@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:24:34 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <9403021903.AA07973@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Mar 1994 14:03:57 -0500 To: info-performer@sgi.sgi.com From: barrus@merl.com (John W. Barrus) Subject: WTK, Performer, and dVS/dVISE We are working on some virtual environment apps and are considering using a commercial package to avoid rewriting things that have already been done elsewhere. Some tools we are currently looking at include WorldToolKit from Sense8 Corp and dVS/dVISE from Division. I would be interested in hearing experiences of others using these systems. I assume that people on this mailing list are for the most part writing their own, but if anyone has any experience with either of the two packages listed, please let me know what you think. We are most concerned about: - Overhead (overall speed, graphics speed, code size, etc.) - Tech Support - Flexibility Any testimonials or flames? Thanks, John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From aschaffe Tue Mar 8 09:24:48 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080924.ZM24367@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:24:48 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: aschaffe (Allan Schaffer) Message-Id: <9403022147.ZM6489@holodeck.asd.sgi.com> Date: Wed, 2 Mar 1994 21:47:57 -0800 In-Reply-To: jfr@cae.ca (Jean-Francois Richard) "Perf. on PIs" (Mar 2, 10:51am) References: <9403021551.AA15802@cae.ca> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: jfr@cae.ca (Jean-Francois Richard) Subject: Re: Perf. on PIs Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Mar 2, 10:51am, Jean-Francois Richard wrote: > > A quick question: will Performer run on a 4D/35? (I guess it > depends at least in part on whether IRIX 4.x can be installed > on a PI). Yes to both. Currently released software for that configuration is IRIX 4.0.5 and Performer 1.0; IRIX 5.2 and Performer 1.2 coming soon. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From aschaffe Tue Mar 8 09:25:04 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080925.ZM24377@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:25:03 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <199403032216.OAA00484@archimedes.chinalake.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: Gauges in Performer... Status: OR Hello all! I'l like to use some simple gauges within Performer to do things like the airspeed indicator in dogfight. I know that GL windows can be open in Performer, but how does one go about defining a gauge that can be manipulated by outside data? jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Dude Internet: jan@archimedes.nwc.navy.mil Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA Naval Air Warfare Center kc6uth@kc6uth.ampr.org -Weapons Division [44.17.2.6] From aschaffe Tue Mar 8 09:25:31 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080925.ZM24384@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:25:31 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer From: jrohlf@tubes (John Rohlf) Message-Id: <9403072011.AA06905@tubes.asd.sgi.com> Subject: Re: point in bounding volume test To: guest (Bernd Froehlich) Date: Mon, 7 Mar 94 12:11:01 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403011337.AA07820@viswiz.gmd.de>; from "Bernd Froehlich" at Mar 1, 94 3:37 pm X-Mailer: ELM [version 2.3 PL8] > 2. We are working on a stereo-application using quad buffers. > There are two channels attached to a pipe which are linked together as > a channel group. The draw callback switches left- and rightbuffers. > > The left and right eye view are set using > > pfChanViewMat(chanLeft, LeftEyeView); > pfChanViewMat(chanRight, RightEyeView); > > and the frustum by > > pfMakePerspFrust( chanLeft, xminl, xmaxl, yminl, ymaxl ); > pfFrustAspect(chanLeft, PFFRUST_CALC_VERT, TableAspect); > pfFrustNearFar( chanLeft, Z_Near, Z_Far ); > > pfMakePerspFrust( chanRight, xminr, xmaxr, yminr, ymaxr ); > pfFrustAspect(chanRight, PFFRUST_CALC_VERT, TableAspect); > pfFrustNearFar( chanRight, Z_Near, Z_Far ); > > The view matrices and frustra are updated for every frame and this > seems to be a problem. > > Everything works fine if pfMultiprocess(PFMP_APPCULLDRAW) or > pfMultiprocess(PFMP_APP_CULLDRAW) is set, but using > pfMultiprocess(PFMP_DEFAULT) causes a flickering view. > The objects are moving correctly only the view is flickering. > We kept the view matrices constant which doesn't help. > Then we kept the frustra constant, only changing the view matrices > which also doesn't help. > Only if you keep the viewing matrices and the frustra constant > then it works. Seems that the viewing information is not mp safe? > > It would be possible to keep the viewing matrices constant and to > transform the objects into a fixed viewing coordinate system, but the > viewing frustra have to be changed for each frame in our application. > > I had already a short discussion with Michael Jones and he wrote: > > >This is a multiprocessing problem. Use "passthrough" data and you > >will be ok. Look and the pfPassChanData() man page for details on > >this. Your data is changing before you use it. > > Shouldn't be the viewing information automatically copied > into passthrough-buffers if I call pfFrame? So is it a bug or not? > What should I put into passthrough data? I can't put the > pfChannel itself into passthrough data. It is possible to do > the stuff with GL-calls and pass-through data inside the > draw callback but this is not the way it should be. I had a flickering problem with my own stereo application. It turned out to be an MP-related bug with caused only the left buffer to be updated. Barring an unlikely bug, Performer's viewing parameters are MP-safe so I would concentrate on your application. First characterize the flickering: - close each eye and see if only 1 of the left/right buffers is being updated. - close each eye and see if both buffers are being updated but 1 of the buffers has a bogus viewing transform. - put printf's in your draw callback and print out the viewing and projection matrices and the current left/right buffer to make sure you are toggling them. You can also send me your code and I will check it out. From aschaffe Tue Mar 8 09:08:05 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403080908.ZM24254@holodeck.asd.sgi.com> Resent-Date: Tue, 8 Mar 1994 09:08:04 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Tue, 8 Mar 94 10:26:14 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403081626.AA12825@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Display lists I have a quick question (hopefully); would there be any problem using display lists in the draw process of Performer? I'm planning to use genobj() makeobj() closeobj() and callobj(). Is genobj() necessary (IE is Performer using the GL maintained display lists?) Thanks in Advance, _ Aaron Hightower - aaron@dseg.ti.com | | . Visualization & Simulation __| |___ Technology Development, TI \ =/=/ Voice: (214)575-6759 \X / / FAX: (214)575-6779 \ ( \/ From guest Tue Mar 8 09:48:20 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403081748.AA09121@tubes.asd.sgi.com> Subject: Re: Display lists To: aschaffe (Aaron M. Hightower) Date: Tue, 8 Mar 94 9:48:10 PST Cc: iris-performer@sgi.sgi.com In-Reply-To: <9403081626.AA12825@skips.dseg.ti.com>; from "Aaron M. Hightower" at Mar 8, 94 10:26 am X-Mailer: ELM [version 2.3 PL8] Status: OR > > I have a quick question (hopefully); would there be any problem using > display lists in the draw process of Performer? I'm planning to use genobj() > makeobj() closeobj() and callobj(). Is genobj() necessary (IE is Performer > using the GL maintained display lists?) There only restriction is that you must make all obj calls in the draw process - don't try to create an object in the APP etc. The only GL display lists that Performer deals with are those created for pfGeoSets when you specify the COMPILE_GL mode to pfGSetDrawMode. For this reason genobj() is recommended so you don't collide with these objects. From guest Tue Mar 8 10:05:25 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403081805.AA09155@tubes.asd.sgi.com> Subject: Re: Performer questions To: aschaffe (Kevin Russo) Date: Tue, 8 Mar 94 10:05:14 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199403012345.XAA16581@midway>; from "Kevin Russo" at Mar 1, 94 11:45 pm X-Mailer: ELM [version 2.3 PL8] Status: OR > >> - In one of our applications at least, the culling does not work properly. > >> Objects suddenly vanish before they leave the viewing frustrum. Any ideas > >> why this could be? We are not changing any of the GeoSets or other data in > >> the hierarchy after it has been initially set up. > > > > Print out the scene with pfDebugPrint and make sure your bounding > > boxes are reasonable. > > I found that for linestrips, anyway, Performer only checks if the first > point or so of the lineseg is in the viewing frustum, regardless of > the bounding box. Perhaps this little speed enhancing trick is at work > in other types of GeoSets? > > I overcame it by installing a node pre-cull callback like this: > node_cull_pre_cb() { pfCullResult(PFIS_ALL_IN); return PFTRAV_CONT; } > > It was most frustrating to watch my trajectory line segments disappear > any time the origin wasn't in view. I'd like to get to the bottom of this. We don't do anything special for linestrips or any other pfGeoSet type. If you are able, send me an application and/or database which illustrates the problem and I'll find out what's going on. Also, send me the following information: 1. Which Performer release are you running? 2. What application: perfly or custom? 3. What multiprocessing model? 4. What culling mode (pfChanTravMode)? N.B.: There is an easier way than using pfCullResult(PFIS_ALL_IN); described above. Call pfNodeTravMask(node, PFTRAV_CULL, 0, PFTRAV_SELF, PF_SET); With a cull mask of 0, the node will be not be cull-tested and will be automatically accepted. From guest Tue Mar 8 11:26:05 1994 Date: Tue, 8 Mar 94 14:28:26 EST From: jfr@cae.ca (Jean-Francois Richard) Message-Id: <9403081928.AA12292@cae.ca> To: info-performer@sgi.sgi.com Subject: .flt version on Perf. 1.0 Status: OR According to the Performer 1.0 documentation, the supplied Multigen loader supports Version 10 .flt files, while some of the previous mail on this list claims that V11 is supported. I am currently trying to load a V11 Multigen database. It loads properly into perfly under Performer 1.2a94 (a beta release) but causes a segmentation fault in the Performer 1.0 perfly, which leads me to believe that my .flt loader only supports V10. How can I tell? None of the files in /usr/src/Performer/src/pfflt seem to specifiy a .flt version number (while under Performer 1.2, comments in hier.c clearly state that it is for a V11 .flt database). If there is a V11 loader for Performer 1.0, and I don't have it, how can I get it? ---------------------------------------------- J.F. Richard jfr@cae.ca CAE Electronics Ltd ---------------------------------------------- From guest Wed Mar 9 07:08:19 1994 From: "Marc SIMON Presales support" Message-Id: <9403091623.ZM14799@girl.paris.sgi.com> Date: Wed, 9 Mar 1994 16:23:08 +0100 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: "Dynamic LOD" Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Is anybody in the performer worlds heard about a soft from the M.I.T. named BRUSH , that could manage automatically Level Of Detail with a unique description of the model (No multiple instance of the 3D model ), and the soft reduce the number of polygons according to the distance between eyes and the object. Any informations will be very helpfull. smarc@paris.sgi.com From guest Fri Mar 11 08:29:47 1994 Date: Fri, 11 Mar 94 11:28:21 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9403111628.AA06926@ldsa.com> To: info-performer@sgi.sgi.com The pfBillboard seems to be fairly simple, but I cannot get even a simple one to display. Does someone have a snipit of code where they create a billboard. A billboard with a single white polygon would be sufficient. What I am trying is like a series of telephone poles. I create a geoset for the pole, and try to create multiple billboards of the pole. I don't see the problem. I am running Performer 1.0 on an Indigo2 with IRIX 4.0. Mike Williams mwilliam@ldsa.com (216)796-8644 From guest Fri Mar 11 11:25:12 1994 Message-Id: <9403111924.AA05623@surreal.asd.sgi.com> To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Fri, 11 Mar 94 11:28:21 EST." <9403111628.AA06926@ldsa.com> Date: Fri, 11 Mar 94 11:24:29 -0800 From: Jim Helman Try turning off backface culling, perhaps they are backwards? I think the 1.0 man page may have been incorrect about the orientation. Here's a code fragment. Note that the code is inefficient in that it only has one billboard polygon per pfBillboard node. Several pfGeoSets would per pfBillboard be better. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 pfVec2 STexCoords[] ={{0.0f, 0.0f}, {1.0f, 0.0f}, {0.0f, 1.0f}, {1.0f, 1.0f}}; pfVec3 SVertCoords[] ={{-0.5f, 0.0f, 0.0f}, { 0.5f, 0.0f, 0.0f}, {-0.5f, 0.0f, 1.0f}, { 0.5f, 0.0f, 1.0f}}; long PrimLens[] = { 4 }; long seed = 0xe58a3e61; pfGroup *MakeBills(pfGroup *where, char **texNames, long nBills, float *sizes) { void *arena = pfGetSharedArena(); pfTexture *tex[MAX_BILL_TEX]; pfTexEnv *tenv; pfGroup *group; long i,j; pfBox bbox; float xorigin, yorigin; float xrange, yrange; pfCoord c; pfGeode *geode; char filepath[256]; long nVerts = 4; long nTex = 0; srand48(seed); pfGetNodeBBox(where, &bbox, NULL); xorigin = bbox.min[0]; yorigin = bbox.min[1]; xrange = bbox.max[0] - bbox.min[0]; yrange = bbox.max[1] - bbox.min[1]; tenv = pfNewTEnv(arena); /* pfTEnvMode(tenv, PFTE_DECAL); */ for (i = 0 ; texNames[i] != NULL ; i++) { tex[i] = pfNewTex(arena); if (!pfFindFile(texNames[i], filepath, R_OK)) { fprintf(stderr, "WARNING: unable to find texture file \"%s\"\n", texNames[i]); return NULL; } if (!pfLoadTexFile(tex[i], filepath)) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "couldn't find %s\n", texNames[i]); pfTexRepeat(tex[i], PFTEX_WRAP, PFTEX_CLAMP); nTex++; } if (nTex == 0) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "no textures for billboards\n"); group = pfNewGroup(); for(i = 0, j = 0 ; i < nBills && j < 10 * nBills ; j++) { float p, r; pfCoord pos; pfVec4 *colors; pos.xyz[0] = drand48() * xrange + xorigin; pos.xyz[1] = drand48() * yrange + yorigin; pfSetVec3(pos.hpr, 0.0f, 0.0f, 0.0f); if (GetZPR((pfNode *)where, &pos, &pos.xyz[2], &p, &r)) { long k; pfVec3 *verts; pfGeoSet *gset; pfGeoState *gst; pfBillboard *bill; float size; pfVec3 *posarr; size = (drand48() * 0.5f + 0.5f) * sizes[i%nTex]; verts = (pfVec3 *)pfMalloc(sizeof(pfVec3)*nVerts, arena); for (k = 0 ; k < nVerts ; k++) pfScaleVec3(verts[k], size, SVertCoords[k]); colors = (pfVec4 *)pfMalloc(sizeof(pfVec4), arena); pfSetVec4(colors[0], 0.6f * drand48(), 0.4 + 0.4 * drand48(), 0.0f, 1.0f); gset = pfNewGSet(arena); pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, NULL); pfGSetAttr(gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, STexCoords, NULL); pfGSetAttr(gset, PFGS_COLOR4, PFGS_PER_PRIM, colors, NULL); pfGSetPrimLengths(gset, PrimLens); pfGSetPrimType(gset, PFGS_TRISTRIPS); pfGSetNumPrims(gset, 1); gst = pfNewGState(arena); pfGStateAttr(gst, PFSTATE_TEXTURE, tex[i%nTex]); pfGStateAttr(gst, PFSTATE_TEXENV, tenv); pfGStateMode(gst, PFSTATE_ALPHAFUNC, PFAF_NOTEQUAL); pfGStateMode(gst, PFSTATE_ALPHAREF, 0); pfGStateMode(gst, PFSTATE_ENLIGHTING, 0); /* pfGStateMode(gst, PFSTATE_TRANSPARENCY,PFTR_ON); */ pfGSetGState(gset, gst); bill = pfNewBboard(); pfAddGSet(bill, gset); pfBboardPos(bill, 0, pos.xyz); pfAddChild(group, bill); i++; } } if (i < nBills) fprintf(stderr, "Only planted %d billboards\n", i); return group; } From guest Sat Mar 12 18:53:19 1994 Message-Id: <9403130253.AA04421@wavefront.wti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 12 Mar 1994 22:51:34 -0500 To: info-performer@sgi.sgi.com From: marc@wti.com (Marc Roth) Subject: Information on Use of Performer with Wavefront's Advanced Visualizer I have several clients who are interested in any information from people who are currently using Performer with The Advanced Visualizer. ANY information on translators, performance, etc. would be greatly appreciated. Thanks in advance. Marc Roth (703)241-8878 marc@wavefront.wti.com From aschaffe Wed Mar 16 02:17:18 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403160217.ZM20193@holodeck.asd.sgi.com> Resent-Date: Wed, 16 Mar 1994 02:17:17 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <9403141401.AA06478@sgi.sgi.com> Date: Mon, 14 Mar 1994 08:03:48 -0600 From: lechnerr@adadv1.mdc.com To: guest Subject: G Dimming X-Vms-To: SMTP%"guest@holodeck.asd.sgi.com" Status: OR I'm looking for the most efficient way to simulate G Dimming (slowly blacking out the display given a percentage intensity) for a fixed wing aircraft simulation with Performer. Any suggestions? MDTS Rob Lechner From guest Mon Mar 14 05:20:24 1994 To: info-performer@sgi.sgi.com Subject: Audio Systems Date: Mon, 14 Mar 94 14:20:09 CET From: "Infobyte S.R.L." Message-Id: <9403141420.aa11998@ax433.mclink.it> Hi all, we are looking for a 3D sound system that can work on ONYX machines in VR applications. We already have Paradigm Simulation AudioWorks, but we are looking for an alternative source. We have some information from Crystal River Egineering (Convolvotron, Acoustetron, ecc.), but it seems that their systems work only for headphones, instead we need ambient output (4 or more loudspeakers). Has anyone heard of or, better than all, experienced such a system? Thank you in advance for any information. Massimo Cuomo - Infobyte - mc9258@mclink.it From guest Mon Mar 14 06:46:57 1994 Date: Mon, 14 Mar 94 15:45:32 +0100 From: binni@avocado.mpib-tuebingen.mpg.de (Sabine Dartsch) Message-Id: <9403141445.AA25491@avocado> To: info-performer@sgi.sgi.com Subject: forms - library Does anybody have experience in binding the Performer (1.2) with the forms - library ??? Whenever I try to do it I get the error message, that all forms - functions I used are "unresolved". Thanks in advance. =============================================================================== Sabine Dartsch --- binni@cabbage.mpib-tuebingen.mpg.de ------------------------------------------------------------------------------- Max - Planck Institut fuer | Spemannstr. 38 biologische Kybernetik | 72076 Tuebingen, Germany ------------------------------------------------------------------------------- Phone: +49-7071-601.xxx FAX: -49 7071 601575 Office: xxx=602 Secretary: xxx=601 =============================================================================== From guest Mon Mar 14 08:03:02 1994 Date: Mon, 14 Mar 94 08:02:53 -0800 From: ib@ivan (Ivan Bach) Message-Id: <9403141602.AA25501@ivan.asd.sgi.com> To: binni@avocado.mpib-tuebingen.mpg.de (Sabine Dartsch), info-performer@sgi.sgi.com Subject: Re: forms - library The forms library comes with some sample programs, such as a scientific calculator. Can you build and run those sample programs on your system? Specify the option -v on the cc command line. That will give you detailed information about how your program is compiled and linked. Then specify the option -v on the cc command line you use to compile and link your Peformer program. Are -L options and the forms library specified the same way in both cases? If not, please make necessary changes. Enter: printenv to check the setting of environment variables. Is the environment you use to build sample forms programs the same as the environment you use to build Peformer programs? The account you are using may be customized. That customization may be causing the problem you reported. Try to use an uncustomized account, an account that uses default settings. Ivan Bach, ib@sgi.com From guest Wed Mar 16 13:00:37 1994 Message-Id: <199403162059.VAA10749@godemine.cmr.no> X-Authentication-Warning: godemine.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: godemine.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Cc: thune@cmr.no Subject: Triangel problems... Date: Wed, 16 Mar 1994 21:59:50 +0100 From: Nils Thune Status: OR Hi! My config: HW - Indigo2 Extreme SW - Performer 1.2 Problem: I'm creating a geometry node with one geoemtry set, which is a set with independent triangles (a geoemetry state ++ is also attached). This geometry is a set with coplanar triangles, representing an oil spill, where z = 1.0. I'm using an Earth Sky model were the ground height is set to 0.0. Now, if the z value for the oil spill is set to 0.0, the zbuffer gets messed up as expected. With z = 1.0, things get better, but the problem is that when these triangles are drawn, they now flicker randomly on and off like they are not double buffered or their Z value still is messed up (whole triangles dissapears and the ground/water shines through the oil spill at random spots). If my view point is close to z = 1.0 things are not that bad (only a few triangles, 10 out of 1000, flicker on and off), but moving up to z = [50 - 500] almost 50% percent turn on and off every frame. I have tried a lot of things like setting the lsetdepth, near and far plane is 1 and 5000, etc. but notting seems to help. I should add that models loaded with the FLT loader and added to the same scene (a boat floating around in the oil spill) behaves fine, so there must be something that I'm doing wrong here. Any help are highly appreciated! - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Wed Mar 16 17:34:10 1994 Date: Wed, 16 Mar 94 17:33:52 PST From: penafiel@guild.rdd.lmsc.lockheed.com (Hugo Penafiel) Message-Id: <9403170133.AA05579@guild.rdd.lmsc.lockheed.com> To: thune@cmr.no Subject: Re: Triangle problems... Cc: info-performer@sgi.sgi.com thune@cmr.no wrote: ============== > If my view point is close to z = 1.0 things are not that bad (only a few > triangles, 10 out of 1000, flicker on and off), but moving up to z = [50 - > 500] almost 50% percent turn on and off every frame. > I have tried a lot of things like setting the lsetdepth, near and far plane is > 1 and 5000, etc. but notting seems to help. ============== This problem sounds a lot like one we were puzzling over. The problem is due to the fact that the Z-buffering is suffering from numerical round off problems. The way to "fix" it is by setting your near clipping plane to something larger than what you are using now (try 5, 10 or 15 and see what happens). There is no magic number that will make it go away forever. "The solution is left as an exercise for the reader." So definitely experiment with many values to see what works for you. Hugo Penafiel email: penafiel@guild.rdd.lmsc.lockheed.com Lockheed Missiles & Space Co. Research & Development Division Palo Alto, CA From guest Wed Mar 16 19:23:37 1994 Date: Wed, 16 Mar 94 19:22:38 PST From: lee@igate1.hac.com (Craig A. Lee) Message-Id: <9403170322.AA06378@igate1.hac.com> To: info-performer@sgi.sgi.com SUBSCRIBE From guest Fri Mar 18 09:41:24 1994 Message-Id: <199403181740.SAA19706@godemine.cmr.no> X-Authentication-Warning: godemine.cmr.no: Host localhost didn't use HELO protocol X-Authentication-Warning: godemine.cmr.no: thune owned process doing -bs To: info-performer@sgi.sgi.com Subject: Calling pfDraw twice.... Date: Fri, 18 Mar 1994 18:40:50 +0100 From: Nils Thune How can one render objects in the pfScene to the same frame number when the objects are located in different parts of the view frustrum, separated by a delta view voulme in which objects should not be rendered? | NearPlane=1.0 FarPlane=100.0 NearPlane=500.0 FarPlane=10000.0 | | | | | | | | | | ----> |-------------------------------------------------------------------- | | | | | | | | | | | Draw objects No drawing Draw objects View direction and viewplane Basically I want to do the following: 0. Clear channel. 1. Cull scene against the view volume defined by near=1.0, far=100.0. 2. Draw the objects which were not culled, i.e. the display list. 3. Cull scene against the view volume defined by near=500.0, far=10000.0 4. Draw the new objects which were not culled, i.e a new display list. 5. Swap buffers, and start over at 0. How can this be done? - Nils -------------------------------- Nils Thune Advanced Computing Christian Michelsen Research Fantoftvegen 38 N-5036 Fantoft, Bergen, Norway Email: thune@cmr.no Phone: 55 574040 Phone: 55 574355 (Direct) Fax : 55 574041 -------------------------------- From guest Fri Mar 18 16:03:48 1994 Date: Fri, 18 Mar 94 14:55:37 CST From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403182055.AA15472@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Using shared arenas Is there any problem with using shared memory arenas under Performer? IE: usinit() in addition to pfDataPool(). I am experiencing problems with pfDataPools when using shared memory also. Just curious if there is any conflict that I should be aware of. More generally: What is the best way to share memory between non-related processes in Performer without having to link with Performer on both processes. In other words, one process is a performer process, and another is just doing messages and things of that nature.. Thanks for any help, _ Aaron Hightower - aaron@dseg.ti.com | | Visualization & Simulation __| |___ Technology Development, TI \ * / <--- Plano, TX! Voice: (214)575-6759 \_ / FAX: (214)575-6779 \ ( \/ From guest Mon Mar 21 07:13:53 1994 From: susi@avocado.mpib-tuebingen.mpg.de (Susanne Huber) Message-Id: <9403211513.AA04860@avocado> Subject: Real-Time Simulation To: info-performer@sgi.sgi.com Date: Mon, 21 Mar 94 16:13:17 MEZ X-Mailer: ELM [version 2.3 PL8] Status: OR I'm working on an autonomous navigation system based on the optical flow. (Onyx RE^2, Performer 1.2) Until now the algorithm, which is computing the next heading direction isn't a real-time algorithm. I have the feeling that Performer gets in trouble with the synchronisation, if the application lasts a lot longer (here ca. 2 seconds) than the framerate. Does anybody have experience whether Performer can handle those applications which last longer than the FrameRate? Or is it perhaps better to use Inventor for this problem? Or the other way round: synchronisation starts with the call to pfSync(). Does the synchronisation sleep after the call to pfFrame until pfSync is called again? If that is true, I could call the appliation before calling pfSync or after calling pfFrame, and there wouldn't be any synchronisation problems? Thanks in advance Susanne H. -- ---------------------------------------------------------------- Susanne Huber Max-Planck-Institut f"ur Biologische Kybernetik Spemannstr. 38 72076 Tuebingen e-mail: susi@spinach.mpib-tuebingen.mpg.de ---------------------------------------------------------------- From guest Mon Mar 21 09:49:55 1994 From: "pierre VERCRUYSSE" Message-Id: <9403211749.ZM4960@cathy.rennes.sgi.com> Date: Mon, 21 Mar 1994 17:49:45 +0100 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: performer 1.2preMR Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi I try to install the performer 1.2preMR (alpha 150) on an Indigo 2 with Irix 5.2MR and Performer 1.2 a94. The inst tools say me that this versions is an older one than the alpha 94 ? Have you an idea ? pierre@rennes.sgi.com From guest Mon Mar 21 10:24:37 1994 Date: Mon, 21 Mar 94 13:02:01 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9403211802.AA11421@ldsa.com> To: info-performer@sgi.sgi.com I am using Performer 1.0 with an Indigo Extreme running Irix 4.0 . This fog is implemented over a very simple data base with some pfLightPoints, and some simple polygon geosets. My problem is that the fog only seems to be applied to the polygons. The lightpoints continue to shine through the fog at any distance. I am applying the fog in the EarthSky model similar to the way it is done in perfly. I am using black as the fog color to simulate night-time conditions. Is there a setting I missed which makes fog apply to lights? I have considered replacing my LightPoints with small polygons to avoid the 1 pixel maximum for lightpoints on this system. If I have emissive polygons will they also shine through the fog? Any help on this is appreciated. Mike Williams mwilliam@ldsa.com (216) 796-8644 From guest Mon Mar 21 10:31:17 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403211830.AA05004@tubes.asd.sgi.com> Subject: Re: performer 1.2preMR To: guest (pierre VERCRUYSSE) Date: Mon, 21 Mar 94 10:30:58 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403211749.ZM4960@cathy.rennes.sgi.com>; from "pierre VERCRUYSSE" at Mar 21, 94 5:49 pm X-Mailer: ELM [version 2.3 PL8] > > > Hi > > I try to install the performer 1.2preMR (alpha 150) on an Indigo 2 with Irix > 5.2MR and Performer 1.2 a94. The inst tools say me that this versions is an > older one than the alpha 94 ? > > Have you an idea ? > > pierre@rennes.sgi.com > This is as result of changing internal version numbers between releases. We used to have silly numbers but now use human-recognizable numbers. Alpha 94 used 1008404916 while 151 uses 1008000151 and inst sees that 151 is < 404916 so it complains. The solutions are to "set neweroverride on" while installing or to "versions -remove performer_dev; versions -remove performer_eoe;" before installing a151. From guest Mon Mar 21 11:55:31 1994 From: aaron@skips.dseg.ti.com (Aaron M. Hightower) Message-Id: <9403211950.AA01461@skips.dseg.ti.com> Subject: Re: Real-Time Simulation To: iris-performer@sgi.sgi.com Date: Mon, 21 Mar 94 13:50:06 CST X-Mailer: ELM [version 2.3 PL0] Status: OR > From: susi@avocado.mpib-tuebingen.mpg.de (Susanne Huber) > > Until now the algorithm, which is computing the next heading > direction isn't a real-time algorithm. > I have the feeling that Performer gets in trouble with the > synchronisation, if the application lasts a lot longer (here ca. 2 seconds) > than the framerate. > -- from the pfConfig man page: Each pfPipe has a cull and draw stage which may be configured as either one or two processes. The intersection stage is independent of any pfPipe and may run in the same process as the application process or as a process by itself. In the latter case, the user may further multiprocess intersection traversals through any IRIX multiprocessing mechanism such as fork, sproc, or m_fork. -- It seems that what you may be able to do is create a user-defined intersection process that handles the high compute-intensive heading determination, and places the result in shared memory (EG ViewState->myHeading)... -- from the pfIsectFunc man page: Within the intersection callback, the user may further multiprocess intersection queries through any IRIX multiprocessing mechanism such as fork, sproc, or m_fork. All of these processes may call pfSegsIsectNode in parallel. When the intersection function is in a separate process, it will run asynchronously with the rest of the rendering pipeline. Specifically, if the intersection function takes more than a frame time, the rendering pipeline will not be affected. -- > > Does anybody have experience whether Performer can handle those applications > which last longer than the FrameRate? > Or is it perhaps better to use Inventor for this problem? There is more information in pfIsectFunc man page that you definitely want to check out. > Or the other way round: synchronisation starts with the call to > pfSync(). Does the synchronisation sleep after the call to pfFrame > until pfSync is called again? > If that is true, I could call the appliation before calling pfSync or > after calling pfFrame, and there wouldn't be any synchronisation > problems? Hope this helps! _ Aaron Hightower - aaron@dseg.ti.com | | . Visualization & Simulation __| |___ Technology Development, TI \ =/=/ Voice: (214)575-6759 \X / / FAX: (214)575-6779 \ ( \/ From guest Tue Mar 22 10:13:55 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403221813.AA12562@tubes.asd.sgi.com> Subject: Re: Performer questions To: aschaffe (Kevin Russo) Date: Tue, 22 Mar 94 10:13:46 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199403012345.XAA16581@midway>; from "Kevin Russo" at Mar 1, 94 11:45 pm X-Mailer: ELM [version 2.3 PL8] > > > >> - In one of our applications at least, the culling does not work properly. > >> Objects suddenly vanish before they leave the viewing frustrum. Any ideas > >> why this could be? We are not changing any of the GeoSets or other data in > >> the hierarchy after it has been initially set up. > > > > Print out the scene with pfDebugPrint and make sure your bounding > > boxes are reasonable. > > I found that for linestrips, anyway, Performer only checks if the first > point or so of the lineseg is in the viewing frustum, regardless of > the bounding box. Perhaps this little speed enhancing trick is at work > in other types of GeoSets? > > I overcame it by installing a node pre-cull callback like this: > node_cull_pre_cb() { pfCullResult(PFIS_ALL_IN); return PFTRAV_CONT; } > > It was most frustrating to watch my trajectory line segments disappear > any time the origin wasn't in view. Are you using pfDCSs? Your release has a bug where bounding volumes for pfDCSes are not properly updated as the pfDCS changes. Do you have a test database? From guest Tue Mar 22 14:16:18 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222216.AA14422@tubes.asd.sgi.com> Subject: Re: Using shared arenas To: guest (Aaron M. Hightower) Date: Tue, 22 Mar 94 14:16:11 PST Cc: iris-performer@sgi.sgi.com In-Reply-To: <9403182055.AA15472@skips.dseg.ti.com>; from "Aaron M. Hightower" at Mar 18, 94 2:55 pm X-Mailer: ELM [version 2.3 PL8] > > Is there any problem with using shared memory arenas under Performer? > IE: usinit() in addition to pfDataPool(). An interaction is possible since pfNewDPool sets up some usconfig parameters that will be inherited by your usinit but these default are almost always reasonable: usconfig(CONF_INITUSERS, MAXDPUSERS); /* up to MAXDPUSERS users */ usconfig(CONF_ARENATYPE, US_GENERAL); /* allow unrelated processes */ usconfig(CONF_LOCKTYPE, US_NODEBUG); /* fastest locks */ Also, you may have trouble mapping datapools to the same virtual address if you have your own usinit arenas that aren't shared by everyone. Perhaps jimh could comment on this? > More generally: What is the best way to share memory between non-related > processes in Performer without having to link with Performer on both > processes. usinit and usgetinfo/usputinfo are what datapools use so this method should be OK. From guest Tue Mar 22 15:02:38 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222233.AA14442@tubes.asd.sgi.com> Subject: Re: Real-Time Simulation To: guest (Susanne Huber) Date: Tue, 22 Mar 94 14:33:04 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403211513.AA04860@avocado>; from "Susanne Huber" at Mar 21, 94 4:13 pm X-Mailer: ELM [version 2.3 PL8] Status: OR > I'm working on an autonomous navigation system based on the optical > flow. (Onyx RE^2, Performer 1.2) > > Until now the algorithm, which is computing the next heading > direction isn't a real-time algorithm. > I have the feeling that Performer gets in trouble with the > synchronisation, if the application lasts a lot longer (here ca. 2 seconds) > than the framerate. > > Does anybody have experience whether Performer can handle those applications > which last longer than the FrameRate? > Or is it perhaps better to use Inventor for this problem? > The application process must call pfFrame to trigger the rendering for a new frame. If your processing takes 2 secs then you are limited to a rendering rate of .5Hz since you are only providing a new eyepoint every 2 seconds. It sounds like what you want is eyepoint extrapolation or "dead reckoning" which is used for systems like DIS which receive positional updates at long intervals. "Dead reckoning" is non-trivial and I don't have any references for you. Extrapolation is trivial but will require that you spawn another process which will handle your processing. As soon as you remove your processing from Performer's APP process, the APP can easily keep up with the frame rate and extrapolate the eyepoint. > Or the other way round: synchronisation starts with the call to > pfSync(). Does the synchronisation sleep after the call to pfFrame > until pfSync is called again? > If that is true, I could call the appliation before calling pfSync or > after calling pfFrame, and there wouldn't be any synchronisatione > problems? When you run in LOCK or FLOAT mode, pfSync will sleep the APP process until the next frame boundary. pfFrame triggers the culling and drawing of a new frame and does not sleep although it may not return immediately. From guest Tue Mar 22 15:02:22 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403222236.AA14451@tubes.asd.sgi.com> Subject: Re: your mail To: guest (Micheal J. Williams) Date: Tue, 22 Mar 94 14:36:32 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <9403211802.AA11421@ldsa.com>; from "Micheal J. Williams" at Mar 21, 94 1:02 pm X-Mailer: ELM [version 2.3 PL8] > > I am using Performer 1.0 with an Indigo Extreme running Irix 4.0 . > This fog is implemented over a very simple data base with some > pfLightPoints, and some simple polygon geosets. > > My problem is that the fog only seems to be applied to the polygons. > The lightpoints continue to shine through the fog at any distance. > I am applying the fog in the EarthSky model similar to the way it is > done in perfly. In 1.0 pfLightPoints are not fogged. In 1.2 they are fogged but the fog onset and opaque ranges are modified by the values passed to pfLPointFogScale. This allows lightpoints to shine through fog more than non-emissive surfaces. > If I have emissive polygons will they also shine through the fog? > Any help on this is appreciated. Unfortunately not. I think this is really a GL issue but if it doesn't get resolved in the GL then we will handle it in Performer in a future release. From guest Tue Mar 22 16:40:06 1994 Date: Tue, 22 Mar 94 18:36:31 CST From: reedwhit@skips.dseg.ti.com (Reed Whittington) Message-Id: <9403230036.AA15998@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Extrapolation This is an easy way to extrapolate for non uniform position updates. It works if you know the velocity, accel, and frame rate. /* * vehicle.h - public interface to vehicle.c */ #ifndef _VEHICLE_H_ #define _VEHICLE_H_ #include "xformer.h" #include "ex_comm.h" #define DEFAULT_MODEL_ID 30 /* vehicle entity object */ typedef struct Vehicle_s { Base_vehicle_t dis; /* information in from data pool (DIS) */ pfDCS *dcs; /* parent dcs */ pfNode *model_root; /* root to cloned visual model */ pfCoord coord; /* current position and direction */ double dt; /* delta time since last frame */ pfuSmoke *smoke; /* each vehicle will have a smoke model */ pfuSmoke *fire; /* each vehicle will have a fire model */ } Vehicle_t; /* vehicle.c */ extern pfGroup* vehLoadLibrary(char *vehicle_dat); extern void vehCheckIsect(void); extern void vehProcess(void); #endif /* * extrapolate a new coord based on the last coord and the * current dis entity state. */ static void vehExtrapolate( Vehicle_t* veh ) { /* extrap xyh hpr */ veh->coord.xyz[PF_X] = (veh->dis.lin_vel_xyz[PF_X] * veh->dt) + veh->coord.xyz[PF_X]; veh->coord.xyz[PF_Y] = (veh->dis.lin_vel_xyz[PF_Y] * veh->dt) + veh->coord.xyz[PF_Y]; veh->coord.hpr[PF_H] = (veh->dis.ang_vel_xyz[PF_Z] * veh->dt) + veh->coord.hpr[PF_H]; veh->coord.xyz[PF_Z] = (veh->dis.lin_vel_xyz[PF_Z] * veh->dt) + veh->coord.xyz[PF_Z]; veh->coord.hpr[PF_P] = (veh->dis.ang_vel_xyz[PF_X] * veh->dt) + veh->coord.hpr[PF_P]; veh->coord.hpr[PF_R] = (veh->dis.ang_vel_xyz[PF_Y] * veh->dt) + veh->coord.hpr[PF_R]; } ******************************** Reed Whittington Texas Instruments Visual Simulation Technology Development MS 8518 6620 Chase Oaks Blvd. Plano, Texas 75086 (214) 575-6761 off (214) 575-6771 fax reedwhit@dseg.ti.com ******************************** From guest Tue Mar 22 17:22:38 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9403230122.AA14744@tubes.asd.sgi.com> Subject: Re: Calling pfDraw twice.... To: guest (Nils Thune) Date: Tue, 22 Mar 94 17:22:29 PST Cc: info-performer@sgi.sgi.com In-Reply-To: <199403181740.SAA19706@godemine.cmr.no>; from "Nils Thune" at Mar 18, 94 6:40 pm X-Mailer: ELM [version 2.3 PL8] > > > How can one render objects in the pfScene to the same frame number when the > objects are located in different parts of the view frustrum, separated by a > delta view voulme in which objects should not be rendered? > > > | NearPlane=1.0 FarPlane=100.0 NearPlane=500.0 FarPlane=10000.0 > | | | | | > | | | | | > ----> |-------------------------------------------------------------------- > | | | | | > | | | | | > | Draw objects No drawing Draw objects > View direction > and viewplane > > Basically I want to do the following: > > 0. Clear channel. > 1. Cull scene against the view volume defined by near=1.0, far=100.0. > 2. Draw the objects which were not culled, i.e. the display list. > 3. Cull scene against the view volume defined by near=500.0, far=10000.0 > 4. Draw the new objects which were not culled, i.e a new display list. > 5. Swap buffers, and start over at 0. > > How can this be done? > Use 2 pfChannels. Give each channel a different frustum as you've illustrated above and combine them into a channel group with pfAttachChan so they can share attributes like view point and view direction, viewport, etc. Just make sure that the second channel doesn't clear the frame buffer and wipe out the results of the first. This should be easy to do in the draw callback. From guest Tue Mar 22 21:02:02 1994 From: "Ignazio Ranno" Message-Id: <9403222101.ZM2124@zorro.melbourne.sgi.com> Date: Tue, 22 Mar 1994 21:01:32 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Performer 1.1 on Indy Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hello All Does Performer 1.1 run on an Indy running 5.1.1X. When I load it on the system it seems to fail to load libpr.a. From guest Wed Mar 23 10:14:38 1994 Message-Id: <9403231814.AA18096@surreal.asd.sgi.com> To: "Ignazio Ranno" Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.1 on Indy In-Reply-To: Your message of "Tue, 22 Mar 94 21:01:32 PST." <9403222101.ZM2124@zorro.melbourne.sgi.com> Date: Wed, 23 Mar 94 10:14:28 -0800 From: Jim Helman I think this is in the current FAQ. The Indy did not exist when 1.1 came out, so you need to tell inst it's something else, inst -m "GFXBOARD=LIGHT" rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Mar 23 11:30:48 1994 Date: Wed, 23 Mar 1994 11:26:39 -0800 (PST) From: "Matthew S. Reeves" Subject: increasing performer heap To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm getting errors on heap size and wonder if there is any way to increase the size ? Appreciate any help ! Matt layer geometry generation time: 0.049999 seconds expanding layer "R_CLG2" (40 of 41) ... creating geometry data structures ... [12851] XvsDXF.c: 651: allocating 33408 bytes for 2784 vertices [12851] XvsDXF.c: 667: filling in vertices [12851] XvsDXF.c: 686: constructing 928 polygons [12851] XvsDXF.c: 753: constructing composite object [12851] XvsDXF.c: 767: cleaning up after composite object layer geometry generation time: 0.179999 seconds expanding layer "R_LITES" (41 of 41) ... creating geometry data structures ... [12851] XvsDXF.c: 651: allocating 66816 bytes for 5568 vertices [12851] XvsDXF.c: 667: filling in vertices [12851] XvsDXF.c: 686: constructing 1856 polygons [12851] XvsDXF.c: 753: constructing composite object [12851] XvsDXF.c: 767: cleaning up after composite object layer geometry generation time: 0.290000 seconds total geometry generation time: 51.790000 seconds -- DXF complete delete time: 1.299998 seconds Performer Fatal (12):pfMalloc() Unable to allocate 15720448 bytes from the heap. -IRI: From guest Thu Mar 24 09:56:14 1994 Message-Id: <9403241041.AA24208@surreal.asd.sgi.com> To: "Matthew S. Reeves" Cc: info-performer@sgi.sgi.com Subject: Re: increasing performer heap In-Reply-To: Your message of "Wed, 23 Mar 94 11:26:39 PST." Date: Thu, 24 Mar 94 02:41:24 -0800 From: Jim Helman Status: OR You should only be allocating from the heap if you are running in a single-process environment and never plan to use libpf's multiprocessing capabilities. If you plan to use MP, the argument to libpr's pfNew should be pfGetSharedArena(). Performer has no control over your heap size. Check your shell limits. Did you really intend a single allocation of 16MB? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Mar 24 16:28:04 1994 Date: Thu, 24 Mar 94 16:30:18 -0800 From: lroy@jetson (Linda Roy) Message-Id: <9403250030.AA04440@jetson.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Is performer worthwhile, if I'm re-calculating tex-coords? Would it be worthwhile to use Performer for a viewer where I was re-calculating texture coordinates for each vertex, each frame? My guess is I'ld want to replace the low-level drawing routines of performer for these objects. Is this easy to do or is this such a pain that I am better off sticking with GL for this?. Any suggestions and opinions are welcome. Speed is second to these texture calculations, here. Thanks, ~~~~~~~~~ Linda Roy lroy@sgi.com (415)390-3684 From aschaffe Tue Mar 29 13:52:13 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403291352.ZM18773@holodeck.asd.sgi.com> Resent-Date: Tue, 29 Mar 1994 13:52:13 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Date: Fri, 25 Mar 94 17:00:03+080 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9403250900.AA06403@bochap.iss.nus.sg> To: info-performer@sgi.sgi.com Subject: Loading Dgn files Content-Length: 2503 Hi, We have recently started using Performer 1.1 and are porting over code from our existing internally developed toolkit. Much of the existing tools were developed for dealing with "Intergraph" format "dgn" files. (Translation from dgn to performer is a two-step process, first we translate from a very complicated binary format from dgn to an ascii version and then we load the ascii to performer). We have constructed a "loadDgn" using the examples, which seems to work reasonable well. We have several questions however. 1) Dgn files typically have lots of "shapes". The easiest thing to do is to create a new geometry and node for each of these. We get a bunch of geometries with pfGSetNumPrims set to 1. It seems that this approach creates lots and lots of nodes; in our first tests it seemed we have poor performance on such datasets. One solution would be to collect the shapes of the different types (quads, or triangles) and then create a single geometry; however this is quite messy (and a LOT more work). Also culling won't work as nice if the orginally shapes were far apart. So what is the best approach? 2) What happens if you don't set a pfGeoState for a pfGeoSet? Does it inherit the global state? 3) This is the embarrassing one. We have lots of polygons that have greater that 4 vertices. Before we easily used gl to draw them. Now given drawing primitives that have < 5 vertices, do we have to decompose them into smaller polygons or are we missing something? If we have to decompose them, how do we do it? thanks much, Kim. PS By the way, we have a lovely translator for taking dgn design files and turning them into polygons (at selectable resolutions). Is any one else doing the same? Here is a data file fragment of the output of the translator. We will convert it to binary in the future (always nice to debug in ascii :->). format: bgf shape { material { ambient: 1.000000 1.000000 1.000000 diffuse: 0.000000 0.777778 0.744444 emission: 0.000000 0.000000 0.000000 specular: 0.000000 0.000000 0.000000 shininess: 0.000000 transparency: 0.000000 } no of polygons: 4 polygon { layer: 255 type: 4 no of points: 3 vertex { 0.041743 0.049698 -0.048695 -0.005608 0.049698 -0.048695 0.018067 0.026023 -0.022703 } normal { 0.000000 0.739274 0.673405 0.000000 0.739274 0.673405 0.000000 0.739274 0.673405 } } polygon { layer: 255 From aschaffe Tue Mar 29 13:55:01 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9403291355.ZM18811@holodeck.asd.sgi.com> Resent-Date: Tue, 29 Mar 1994 13:55:00 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer Message-Id: <9403260124.AA01546@surreal.asd.sgi.com> To: lroy@jetson (Linda Roy) Cc: info-performer@sgi.sgi.com Subject: Re: Is performer worthwhile, if I'm re-calculating tex-coords? In-Reply-To: Your message of "Thu, 24 Mar 94 16:30:18 PST." <9403250030.AA04440@jetson.asd.sgi.com> Date: Fri, 25 Mar 94 17:24:07 -0800 From: Jim Helman Status: OR pfGeoSet coordinate arrays are exposed, so you can do whatever you want to them. The only issue is when to do it so you don't collide with the draw process using them (might cause tearing or anomalies). For a single pipe application, you can diddle the coordinates in a draw callback on the parent geode or if you multibuffer the geoset so you don't collide with the one the draw is using you can do it in the application process. For complete safety in a multipipe application, each pipe needs its own copy of the pfGeoSet to avoid collision or problems during frame extension. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Mar 29 17:02:44 1994 Return-Path: Message-Id: <9403300100.AA07659@bach.iml.mkhar.sharp.co.jp> To: info-performer@sgi.sgi.com Cc: hasimoto@iml.mkhar.sharp.co.jp Subject: scaling image using rectcopy Date: Wed, 30 Mar 1994 10:00:51 +0900 From: Takeshi Hashimoto Status: OR Hi, I wrote a program in Performer whose window size is 320x240 pixel. I want to display it's 320x240 window to NTSC full screen by Galileo Video. How can I do it? I tried to scale image after pfDraw ,using rectzoom and rectcopy but it didn't work as I want. in draw process DrawFunc( pfChannel *chan, void *data) .... pfDraw(); afunction(0,AF_ALWAYS); viewport(0,639,0,479); rectzoom(2.0f,2.0f); rectcopy(0,0,319,239,0,0); } Is it wrong? --- //\\ The sky above Chiba-City was the color of television (O O) tuned to a 'video' channel..... \o/ WOW hasimoto@iml.mkhar.sharp.co.jp From guest Wed Mar 30 08:43:31 1994 From: "Michael Jones" Message-Id: <9403300843.ZM6250@babar.asd.sgi.com> Date: Wed, 30 Mar 1994 08:43:20 -0800 In-Reply-To: fair@iss.nus.sg (Kim Michael Fairchild) "Loading Dgn files" (Mar 25, 5:00pm) References: <9403250900.AA06403@bochap.iss.nus.sg> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: fair@iss.nus.sg (Kim Michael Fairchild), info-performer@sgi.sgi.com Subject: Re: Loading Dgn files Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Mar 25, 5:00pm, Kim Michael Fairchild wrote: > Subject: Loading Dgn files :We have recently started using Performer 1.1 and are porting over code :from our existing internally developed toolkit. Any chance of upgrading to the lastest 1.2 version of IRIS Performer? It has numerous facilities for building optimized database loaders, such as functions to tesselate concave or complex polygons, form triangle meshes, and make spatial-subdivision hierarchies from the resulting pfGeoSets. (It has a few hundred other new features too...) :We have constructed a "loadDgn" using the examples, which seems to :work reasonable well. We have several questions however. : :1) Dgn files typically have lots of "shapes". The easiest thing to do :is to create a new geometry and node for each of these. We get a bunch :of geometries with pfGSetNumPrims set to 1. It seems that this :approach creates lots and lots of nodes; in our first tests it seemed :we have poor performance on such datasets. Not unexpected. Triangle strips are desired, and geosets with tens of primitives are best. :One solution would be to collect the shapes of the different types :(quads, or triangles) and then create a single geometry; however this :is quite messy (and a LOT more work). Also culling won't work as nice :if the orginally shapes were far apart. So what is the best approach? Actually this is the EASY method with IRIS Performer 1.2 and the new pfuBuilder() functions. You just allocate a pfuBuilder, add polygons one at a time (each of which may have many sides, be concave, etc.) and then call pfuMakeGSets() when you're done -- you'll be give a minimal set of triangle strips of maximal length, as well as quads for the few fragments you have left over. It's that easy and explained in detail in the new Programming Guide. If the resulting pfGeoSets are too big spatially, then use pfuBreakup to reduce them to an efficient hierarchy. :2) What happens if you don't set a pfGeoState for a pfGeoSet? Does it :inherit the global state? No. Having no pfGeoState is a kind of "don't care" mode. It's like Bungee jumping without a cord. Since pfGeoStates inherit all modes and attributes by default, the "use global state" solution is to make one plain pfGeoState that's referenced by all the pfGeoSets you want to have inherit the global state. :3) This is the embarrassing one. We have lots of polygons that have :greater that 4 vertices. Before we easily used gl to draw them. Now :given drawing primitives that have < 5 vertices, do we have to :decompose them into smaller polygons or are we missing something? If :we have to decompose them, how do we do it? You make a triangle strip that zig-zags the n-gon. For example, if you had a 12-sided polygon, with vertices numbered as a clock face, you could specify the triangle strip: 1, 2, 12, 3, 11, 4, 10, 5, 9, 6, 8, 7 which makes for ten triangles, the same number which would have been drawn by IrisGL when sent the 12-sided polygon. Alternately, just give the 12 vertices to the pfuBuilder() and it will do all the work for you. (Hint: use the pfuBuilder(), it's your friend) :PS By the way, we have a lovely translator for taking dgn design files :and turning them into polygons (at selectable resolutions). Is any one :else doing the same? Here is a data file fragment of the output of the :translator. We will convert it to binary in the future (always nice to :debug in ascii :->). -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Mar 30 09:04:26 1994 From: "Michael Jones" Message-Id: <9403300904.ZM6352@babar.asd.sgi.com> Date: Wed, 30 Mar 1994 09:04:12 -0800 In-Reply-To: Takeshi Hashimoto "scaling image using rectcopy" (Mar 30, 10:00am) References: <9403300100.AA07659@bach.iml.mkhar.sharp.co.jp> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Takeshi Hashimoto , info-performer@sgi.sgi.com Subject: Re: scaling image using rectcopy Cc: hasimoto@iml.mkhar.sharp.co.jp Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Mar 30, 10:00am, Takeshi Hashimoto wrote: > Subject: scaling image using rectcopy :Hi, : I wrote a program in Performer whose window size is 320x240 :pixel. I want to display it's 320x240 window to NTSC full :screen by Galileo Video. :How can I do it? : :I tried to scale image after pfDraw ,using rectzoom and rectcopy :but it didn't work as I want. : :in draw process :DrawFunc( pfChannel *chan, void *data) : .... : : pfDraw(); : afunction(0,AF_ALWAYS); : viewport(0,639,0,479); : rectzoom(2.0f,2.0f); : rectcopy(0,0,319,239,0,0); :} : :Is it wrong? They way to do this is to simply make the pfPipe's origin and size match the Galileo Video's expectations. Take the code above out of the Channel Draw Callback, and simply make the Pipeline Initialization Callback specify the desired window size and origin. That's all there should be to it. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Apr 4 09:46:10 1994 Date: Mon, 4 Apr 94 11:44:50 EST From: mwilliam@ldsa.com (Micheal J. Williams) Message-Id: <9404041644.AA12583@ldsa.com> To: info-performer@sgi.sgi.com Hi, We are about to upgrade oll of our systems from IRIX 4.x to IRIX 5.x. We plan to move up to Performer 1.2 (from 1.0) when we do this. What kind of problems will we be looking at? I understand Performer 1.2 is Open-GL based rather than GL based. What does this mean to us in this upgrade. I understand basically what Open-GL is, but is it a special package that we will have to get in addition to Performer 1.2? I am also curious about how much rework of existing Performer code should be expected. We are doing flight simulation type work on Indigo2 Extremes using Performer 1.0 with ada. Any help would be appreciated. Thanks Mike Williams mwilliam@ldsa.com From aschaffe Mon Apr 4 15:59:02 1994 From: aschaffe (Allan Schaffer) Message-Id: <9404041558.ZM11183@holodeck.asd.sgi.com> Date: Mon, 4 Apr 1994 15:58:57 -0700 In-Reply-To: mwilliam@ldsa.com (Micheal J. Williams) "" (Apr 4, 11:44am) References: <9404041644.AA12583@ldsa.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: mwilliam@ldsa.com (Micheal J. Williams) Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On Apr 4, 11:44am, Micheal J. Williams wrote: > > We are about to upgrade oll of our systems from IRIX 4.x to > IRIX 5.x. We plan to move up to Performer 1.2 (from 1.0) when > we do this. What kind of problems will we be looking at? We're looking into some things, but 5.2 seems to be good. I'll upgrade the FAQ with the known bugs and repost it. (soon) Something to keep in mind when you upgrade is that you'll get the new "IndigoMagic" environment. It's a great interface but some people have worried that when it might wake up from time to time and make them drop a frame. If you see that happening, you can disable IndigoMagic temporarily by executing "chkconfig desktop off" or creating a file $HOME/.disableDesktop, then logging out & back in again. > I understand Performer 1.2 is Open-GL based rather than GL > based. What does this mean to us in this upgrade. I understand > basically what Open-GL is, but is it a special package that we > will have to get in addition to Performer 1.2? As mtj pointed out, Performer 1.2 does not use OpenGL, so you won't need anything special. > I am also curious about how much rework of existing Performer > code should be expected. We are doing flight simulation type work > on Indigo2 Extremes using Performer 1.0 with ada. A fair number of functions have changed names, arguments, etc. from 1.0/1.1 --> 1.2. Each change is listed in the 1.2 release notes, and there is also a "port1.2" sed script that will go through your code and make the trivial changes for you, and flag things that will need to be reworked. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Apr 6 05:19:25 1994 Date: Wed, 6 Apr 94 13:26:26 +0100 From: arnaud@thomson-dsi.fr (AST ) Message-Id: <9404061226.AA05968@thodsic.cergy.thomson-dsi.fr> To: info-performer@sgi.sgi.com Subject: Rendering in multiple windows Status: OR Hi there ! I am trying to draw geosets in 2 different windows created by winopen (non-mixed mode). My application is only based on GL and Performer LIBPR . The problem is : winset does not work. Why ? (I am using Performer Iris4.x 1.2a72) If I convert my application to mixed-mode, will GLXwinset work ? Thanks in advance. ------------------------------ C. DELEPINE THOMSON-CSF Simulator Division PARIS, FRANCE arnaud@cergy.thomson-dsi ------------------------------ P.S> Question to Allan: Is there an updated FAQ list we could receive ?? From guest Thu Apr 7 13:01:46 1994 From: watsen@netcom.com (Kent Watsen) Message-Id: <199404072002.NAA10959@mail.netcom.com> Subject: Can Performer handle this? To: info-performer@sgi.sgi.com (performer) Date: Thu, 7 Apr 1994 13:02:13 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1080 Hi, I am writting a simulation application in which I plan to model the Earth, all of it, in geocentric coordinate space. I would like to use the Earth/ Sky model but it assumes that the Z axis is "up" and I will need "up" to be defined by the vector coming from the center of the "earth" to the camera's location. I would like to specifiy the altitude and orientation for the Earth/Sky to then use to render the background with. If there is a way to do this, I have not found it yet. I assume that the Earth/Sky model is implemented through libpr or GL...can I get the source, add my function, recompile and relink libpf...maybe even add a man page? Maybe I can "trick" the channel out just long enough for it to render the correct Earth/Sky model and then switch it back to the correct channel orientation? Or to take it to an extreme, have two channels rendering to the same screen...the first with just the ESky models, the second with just my DB and no ESky. If not, does anyone know just the algorithm? I'll code it up. Any Ideas? Kent Watsen Watsen@netcom.com From guest Fri Apr 8 11:27:27 1994 Date: Fri, 8 Apr 94 14:29:36 -0400 From: passarella@enews.nrl.navy.mil (Kim Passarella) Message-Id: <9404081829.AA08699@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: help Status: OR Hi, I am hoping there is a quick fix for this... I am attempting to run a VERY simple performer application on an onyx from a pi with the DISPLAY set appropriately. I am using Performer 1.2. My code looks virtually identical to that given in the manual. I have a callback called OpenPipeline which I pass to pfInitPipe. In this callback I call winopen at which point a small window appears on my screen. The next call that is made is to pfInitGfx. As soon as this call is made the window goes away and the application dies. There is no core dumped, however. and I get no error messages. I put in the following diagnostic calls after winopen and before pfInitGfx: pfGetPipeScreen pfGetPipeSize pfGetPipeOrigin pfGetPipeWin The values these functions return are 0 x = -1, y = -1 x = -1, y = -1 0 Other folks here have had this problem when running on the onyx. Do you all know what the fix is? Kimberly From guest Fri Apr 15 08:14:28 1994 Message-Id: <199404151513.IAA22823@archimedes.chinalake.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: multisample() missing? Hello! I'm trying to compile Performer apps on an Indigo^2 extreme running: OS: 4.0.5H GL/X: 4.0.5 C++: 3.0.1 Dev: 4.1.1 Performer: Beta from 15 Feb (Couldn't figure out how to find the version!) Compilation goes well, but during loading the loader can't find "multisample". I have no problems with this on our Onyx. In fact, the Onyx has multisample in its man pages, but the Indigo^2 does not. I know I'm missing something, but where can I get/install it? I get the same loading error from the sample apps as well as my own... Thanks! jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Dude Internet: jan@archimedes.nwc.navy.mil Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA Naval Air Warfare Center kc6uth@kc6uth.ampr.org -Weapons Division [44.17.2.6] From guest Fri Apr 15 15:12:20 1994 Message-Id: <9404152212.AA20579@surreal.asd.sgi.com> To: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Cc: info-performer@sgi.sgi.com Subject: Re: multisample() missing? In-Reply-To: Your message of "Fri, 15 Apr 94 08:13:32 PDT." <199404151513.IAA22823@archimedes.chinalake.navy.mil> Date: Fri, 15 Apr 94 15:12:06 -0700 From: Jim Helman Re: undefined multisample() in 1.2 Beta for Irix 4.0.5 You need to get the official version of Performer 1.2 which should be shipping next week, if it isn't already. Performer 1.2 for IRIX 4.0.5 gives you one of two versions of libpr depending on your graphics hardware. In one of the 1.2 beta's, a call to multisample() sneaked into the non-RealityEngine version. A workaround for the beta is to generate a stub for the routine to keep the linker happy. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Apr 19 10:46:23 1994 Message-Id: <9404191844.ZM22924@unknown.zmail.host> Date: Tue, 19 Apr 1994 18:44:10 +0100 In-Reply-To: Jim Helman "Re: Is performer worthwhile, if I'm re-calculating tex-coords?" (Mar 25, 5:24pm) References: <9403260124.AA01546@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Is performer wortAnti-Aliasing Problem Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi Perhaps someone could help me with this. I am trying to implement my own Performer application program, and am in the process of implementing antialiasing. In the performer manuals it implies I should set anti-aliasing on for each geostate, and then a global switch exists, set by pfAntialias to toggle anti-aliasing on and off. When i look at perfly however it appears to go into the gl to turn on antialiasing, in particular, using the code fragment stensize(0); acsize(0); zbsize(0); mssize(Multisample, 32, 1); multisample(TRUE); gconfig(); I think that perfly does this because Performer does not allow full access to the RE multisampling options. Is this the case? Anyway, I have a VTX graphics system, which, when I try to copy what perfly has done, gives me strange results, as if the z-buffer has been turned off ,which of course it has, and the multi-sampling z-buffer has not been turned on. Now perfly works fine, so obviously I am missing something here, anyone any ideas? Thanks Richard Gallery From guest Wed Apr 20 06:16:59 1994 From: "Vidar Storkersen" Message-Id: <9404201531.ZM11063@onyx.autosim.no> Date: Wed, 20 Apr 1994 15:31:48 +0100 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Layered Intensity Alpha sky texture. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi, I'm running Performer1.2alpha99 on an Onyx RE^2 (running Irix 5.2-ALPHA-1010931841). In Multigen our Intensity Alpha sky texture looks nice, but when we are running our database in Performer the skies looks like they are layered. It is the Alpha part of the texture which is layered. There are just a few transparency levels. In Multigen I tried to change the Internal format, from the default format to TX_IA8. Then I would still have a full speed texture, but with 256 levels of Alpha. Again I tried to run our database in Performer. But still there where just a few levels of transparency. At last I changed the internal format to TX_RGBA12 on the sky texture in Multigen. Then I would have 4096 levels of Alpha. (The only difference was that the Intenity part of the texture became blue in Multigen.) In Performer the Intensity part became blue (as in Multigen), but there where still just 16 transparency levels. The last test is an indication that this problem has no origin in LoadFlt, since the Intensity part of the texture became blue in Performer. My question is: Doesn't Performer allow you to have Intensity Alpha textures with more than 16 transparency levels. If Performer allows more than 16 transparency levels: What can I do to get skies with more than 16 transparency levels TX_IA8 (256 transparency levels) will satisfy our needs for credible skyes. Vidar Stoerkersen. vidar@autosim.no From guest Wed Apr 20 10:16:10 1994 Message-Id: <9404201814.ZM671@unknown.zmail.host> Date: Wed, 20 Apr 1994 18:14:35 +0100 In-Reply-To: Richard Gallery "Re: Is performer wortAnti-Aliasing Problem" (Apr 19, 6:44pm) References: <9403260124.AA01546@surreal.asd.sgi.com> <9404191844.ZM22924@unknown.zmail.host> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Texture flashin on and off Problem Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi I am in the process of writing my own application code, taking bits from perfly as and when I need/understand them. Now, I load up the Performer Village using LoadFlt, but when i view it in my app on the roofs of some of the houses I get texture flashing on and off. This does not happen in perfly when I load up the performer village. My debugging approach has been to hack perfly, to try and replicate the problem in it, but it doesn't appear. Perfly is quite robust to this sort of treatment (well written code). Anyway, does anyone have any ideas/suggestions about this. I have an Onyx with VTX graphics. Thanks Richard Gallery P.S. If anyone saw my posting yesterday about anti-aliasing, ignore it please, as I have figured that one out From guest Wed Apr 20 10:56:00 1994 Date: Thu, 21 Apr 94 02:00:50+080 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9404201800.AA10249@bochap.iss.nus.sg> To: info-performer@sgi.sgi.com Subject: Builder Cc: desmond@iss.nus.sg, benghai@iss.nus.sg, luis@iss.nus.sg Content-Length: 22906 Hello, After one month of +12 hour days converting from our existing toolkit to performer, I am starting to believe I am starting to understand performer (a bit :->). But I still can't figure out a few remaining things. 1) Builder. For such an amazing function, a single page of documentation sure doesn't seem enough! I am trying to figure out what values to use for pfGetPartAttr. The docs says that if set the notify level to debug, something will be printed to tell you. Still seems mysterious to me. Here is my code from the end of the supplied "loadfile.c" file. Run-time output is appended at the end of the note. /* return pointer to in-memory hierarchy */ if (node == NULL) return NULL; notifyLevel = pfGetNotifyLevel(); pfNotifyLevel(PFNFY_DEBUG); partition = pfNewPart(); printf("node: %x\n", node); pfAddChild(partition, node); printf("Partition Attributes: %f %f %f\n", pfGetPartAttr(partition, PFPART_MIN), pfGetPartAttr(partition, PFPART_MAX), pfGetPartAttr(partition, PFPART_FINE)); printf("building part....\n"); pfBuildPart(partition , PFPART_DEFAULT); printf("Partition Attributes: %f %f %f\n", pfGetPartAttr(partition, PFPART_MIN), pfGetPartAttr(partition, PFPART_MAX), pfGetPartAttr(partition, PFPART_FINE)); printf("...done building part\n"); pfNotifyLevel(notifyLevel); /* return node;*/ return ((pfNode*) partition); 2) Attenuating Textures with colours. I have a large cad model that has colours on it. What I wish to do is add just a splash of colour to a default texture (e.g. whitemarble) and paste it on all the polygons. I saw the reference to doing this in the Performer 1.1 example textured cube (but the code wasn't given). By the way, is this a smart thing to do? I am running on a reality engine, will I take a performance hit if I have about 10000 small textures as opposed to 10000 materials? 3) Collisions I want to be able to effect objects by hitting them. Using the example collision routines, I assumed that I would be able to find out what nodes I hit and then be able to modify them (eg. translate them). I thought pfuXformer held the node information in its grndnode and objnode slots but that turned out just to be the top-level scene. So how do I get the actual objects that my vehicle hits? While on this subject, picking is REALLY hard in performer! Thankfully you included pickfly for reference and so it was not too hard to integrate all the obscure things in. Unfortunately pickfly has a odd behaviour in that once you move the orientation of the object, the object might move just about anywhere when you move the mouse on the screen. Normally when you pick with the mouse, you would sure like the object to stay under the mouse cursor when you drag! Has anyone fixed this? thanks so much for reading this overlong message, Kim. PS Here is the output of the position runtime I loaded in several of my "bgf" files (converted from Intergraph). Performer Info (12): All 2 processors available on this machine. Final LoadBGF: file name = T-satelite.bgf Number of Shapes = 5 Number of Polygons = 94 object name = commands skipped = 0 commands unknown = 0 vertices = 366 triangles = 178 loading time = 0.003 sec loading rate = 61313.261 tri/sec node: 7e2180 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffaa70 Performer Debug (2): cost=250.315796 (183.597382) nOccur=354 start=-1.421756 delta=0.960870 count=2 Performer Debug (2): cost=224.859955 (183.597382) nOccur=318 start=-0.738784 delta=0.960870 count=2 Performer Debug (2): cost=224.011902 (183.597382) nOccur=388 start=-1.435505 delta=0.960870 count=3 Performer Debug (2): cost=218.238403 (183.597382) nOccur=378 start=-1.436246 delta=0.960870 count=3 Performer Debug (2): cost=217.083694 (183.597382) nOccur=376 start=-1.458956 delta=0.960870 count=3 Performer Debug (2): cost=212.464890 (183.597382) nOccur=368 start=-1.376068 delta=0.929250 count=3 Performer Debug (2): cost=189.370880 (183.597382) nOccur=328 start=-1.449995 delta=0.974619 count=3 Performer Debug (2): points: 0.00s deltas: 0.01s pcost: 0.02s qsort: 0.00s cost: 0.13s Performer Info (2): coord 0: start=-1.449995 delta=0.974619 count=3 cost=189.370880 hits 0x7fffa958 Performer Debug (2): cost=318.000000 (2209.519531) nOccur=318 start=-0.040953 delta=0.081906 count=1 Performer Debug (2): cost=230.516800 (2209.519531) nOccur=326 start=-0.044601 delta=0.081906 count=2 Performer Debug (2): cost=227.688385 (2209.519531) nOccur=322 start=-0.122529 delta=0.081906 count=2 Performer Debug (2): points: 0.00s deltas: 0.04s pcost: 0.09s qsort: 0.00s cost: 0.11s Performer Info (2): coord 1: start=-0.122529 delta=0.081906 count=2 cost=227.688385 Performer Info (2): build: 0.539587 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Final LoadBGF: file name = T-arts_school.bgf Number of Shapes = 15 Number of Polygons = 1001 object name = commands skipped = 0 commands unknown = 0 vertices = 7314 triangles = 3994 loading time = 0.020 sec loading rate = 197092.865 tri/sec node: 7eb500 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffaa00 Performer Debug (2): points: 0.00s deltas: 0.03s pcost: 0.00s qsort: 0.00s cost: 0.00s Performer Info (2): coord 0: start=0.000000 delta=0.000000 count=0 cost=34028234663852886000000000000000000000.000000 hits 0x7fffa400 Performer Debug (2): points: 0.01s deltas: 0.59s pcost: 0.02s qsort: 0.00s cost: 0.00s Performer Info (2): coord 1: start=0.000000 delta=0.000000 count=0 cost=34028234663852886000000000000000000000.000000 Performer Info (2): build: 0.768146 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Final LoadBGF: file name = T-mirror.bgf Number of Shapes = 19 Number of Polygons = 1489 object name = commands skipped = 0 commands unknown = 0 vertices = 11252 triangles = 6222 loading time = 0.007 sec loading rate = 904622.911 tri/sec node: 87ae10 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffaa10 Performer Debug (2): points: 0.00s deltas: 0.02s pcost: 0.00s qsort: 0.00s cost: 0.00s Performer Info (2): coord 0: start=0.000000 delta=0.000000 count=0 cost=34028234663852886000000000000000000000.000000 hits 0x7fffa170 Performer Debug (2): points: 0.01s deltas: 1.03s pcost: 0.02s qsort: 0.00s cost: 0.00s Performer Info (2): coord 1: start=0.000000 delta=0.000000 count=0 cost=34028234663852886000000000000000000000.000000 Performer Info (2): build: 1.169156 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Final LoadBGF: file name = T-library.bgf Number of Shapes = 7 Number of Polygons = 116 object name = commands skipped = 0 commands unknown = 0 vertices = 540 triangles = 308 loading time = 0.000 sec loading rate = 800888.258 tri/sec node: 940010 Partition Attributes: 0.472503 0.135002 -0.326185 building part.... hits 0x7fffaab8 Performer Debug (2): points: 0.00s deltas: 0.00s pcost: 0.00s qsort: 0.00s cost: 0.00s Performer Info (2): coord 0: start=0.000000 delta=0.000000 count=0 cost=34028234663852886000000000000000000000.000000 hits 0x7fffaa08 Performer Debug (2): points: 0.00s deltas: 0.01s pcost: 0.00s qsort: 0.00s cost: 0.00s Performer Info (2): coord 1: start=0.000000 delta=0.000000 count=0 cost=34028234663852886000000000000000000000.000000 Performer Info (2): build: 0.030083 secs Partition Attributes: 0.472503 0.135002 0.500000 ...done building part Adding to a Container ready to addToLists called addToDynamicList Adding a new branch Final LoadBGF: file name = T-admin1.bgf Number of Shapes = 12 Number of Polygons = 1376 object name = commands skipped = 0 commands unknown = 0 vertices = 6018 triangles = 3146 loading time = 0.003 sec loading rate = 1244285.817 tri/sec node: bc2a30 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffaa28 Performer Debug (2): cost=5375.000000 (9522.815430) nOccur=5375 start=-0.137065 delta=0.274130 count=1 Performer Debug (2): cost=3800.698975 (9522.815430) nOccur=5375 start=-0.179301 delta=0.274130 count=2 Performer Debug (2): points: 0.00s deltas: 0.01s pcost: 0.09s qsort: 0.00s cost: 0.01s Performer Info (2): coord 0: start=-0.179301 delta=0.274130 count=2 cost=3800.698975 hits 0x7fffa590 Performer Debug (2): cost=4211.527832 (3103.257568) nOccur=5956 start=-1.141786 delta=0.820893 count=2 Performer Debug (2): cost=3461.792236 (3103.257568) nOccur=5996 start=-1.202202 delta=0.820893 count=3 Performer Debug (2): cost=3438.698242 (3103.257568) nOccur=5956 start=-1.142066 delta=0.820893 count=3 Performer Debug (2): cost=3424.841797 (3103.257568) nOccur=5932 start=-1.154510 delta=0.820893 count=3 Performer Debug (2): cost=3387.891357 (3103.257568) nOccur=5868 start=-1.157267 delta=0.820893 count=3 Performer Debug (2): cost=3382.695068 (3103.257568) nOccur=5859 start=-1.229077 delta=0.820893 count=3 Performer Debug (2): cost=3329.578857 (3103.257568) nOccur=5767 start=-1.231914 delta=0.820893 count=3 Performer Debug (2): cost=3326.692139 (3103.257568) nOccur=5762 start=-1.235896 delta=0.820893 count=3 Performer Debug (2): cost=3324.960205 (3103.257568) nOccur=5759 start=-1.237246 delta=0.820893 count=3 Performer Debug (2): cost=3315.722656 (3103.257568) nOccur=5743 start=-1.241944 delta=0.820893 count=3 Performer Debug (2): cost=3315.145264 (3103.257568) nOccur=5742 start=-1.243345 delta=0.820893 count=3 Performer Debug (2): cost=3292.628418 (3103.257568) nOccur=5703 start=-1.244215 delta=0.820893 count=3 Performer Debug (2): cost=3286.277588 (3103.257568) nOccur=5692 start=-1.244822 delta=0.820893 count=3 Performer Debug (2): cost=3282.813477 (3103.257568) nOccur=5686 start=-1.247562 delta=0.820893 count=3 Performer Debug (2): cost=3281.658936 (3103.257568) nOccur=5684 start=-1.249321 delta=0.820893 count=3 Performer Debug (2): cost=3262.606201 (3103.257568) nOccur=5651 start=-1.255837 delta=0.820893 count=3 Performer Debug (2): cost=3247.017822 (3103.257568) nOccur=5624 start=-1.257772 delta=0.820893 count=3 Performer Debug (2): cost=3238.935059 (3103.257568) nOccur=5610 start=-1.263504 delta=0.820893 count=3 Performer Debug (2): cost=3233.738770 (3103.257568) nOccur=5601 start=-1.269995 delta=0.820893 count=3 Performer Debug (2): cost=3232.006836 (3103.257568) nOccur=5598 start=-1.283753 delta=0.820893 count=3 Performer Debug (2): cost=3221.614502 (3103.257568) nOccur=5580 start=-1.298019 delta=0.820893 count=3 Performer Debug (2): cost=3219.882324 (3103.257568) nOccur=5577 start=-1.304199 delta=0.820893 count=3 Performer Debug (2): cost=3219.304932 (3103.257568) nOccur=5576 start=-1.305423 delta=0.820893 count=3 Performer Debug (2): cost=3211.222168 (3103.257568) nOccur=5562 start=-1.308873 delta=0.820893 count=3 Performer Debug (2): cost=3201.407227 (3103.257568) nOccur=5545 start=-1.310179 delta=0.820893 count=3 Performer Debug (2): cost=3195.056396 (3103.257568) nOccur=5534 start=-1.314291 delta=0.820893 count=3 Performer Debug (2): cost=3180.045166 (3103.257568) nOccur=5508 start=-1.316672 delta=0.820893 count=3 Performer Debug (2): cost=3168.498291 (3103.257568) nOccur=5488 start=-1.426380 delta=0.932982 count=3 Performer Debug (2): cost=3153.487061 (3103.257568) nOccur=5462 start=-1.431142 delta=0.935363 count=3 Performer Debug (2): points: 0.00s deltas: 0.52s pcost: 1.61s qsort: 0.02s cost: 30.74s Performer Info (2): coord 1: start=-1.431142 delta=0.935363 count=3 cost=3153.487061 Performer Info (2): build: 33.152908 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Adding to a Container ready to addToLists called addToDynamicList Adding a new branch Final LoadBGF: file name = T-student.bgf Number of Shapes = 9 Number of Polygons = 316 object name = commands skipped = 0 commands unknown = 0 vertices = 1918 triangles = 1066 loading time = 0.015 sec loading rate = 68954.614 tri/sec node: c50d20 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffaa20 Performer Debug (2): cost=1922.000000 (3577.262207) nOccur=1922 start=-0.137336 delta=0.274541 count=1 Performer Debug (2): cost=1383.100830 (3577.262207) nOccur=1956 start=-0.159989 delta=0.274541 count=2 Performer Debug (2): points: 0.00s deltas: 0.01s pcost: 0.07s qsort: 0.00s cost: 0.02s Performer Info (2): coord 0: start=-0.159989 delta=0.274541 count=2 cost=1383.100830 hits 0x7fffa8e8 Performer Debug (2): cost=1412.092163 (1109.667236) nOccur=1997 start=-1.021455 delta=0.689890 count=2 Performer Debug (2): cost=1152.968506 (1109.667236) nOccur=1997 start=-1.021946 delta=0.689890 count=3 Performer Debug (2): cost=1142.576172 (1120.059448) nOccur=1979 start=-1.016462 delta=0.658639 count=3 Performer Debug (2): cost=1139.112061 (1128.142456) nOccur=1973 start=-0.995686 delta=0.637661 count=3 Performer Debug (2): points: 0.00s deltas: 0.05s pcost: 0.18s qsort: 0.01s cost: 0.27s Performer Info (2): coord 1: start=-0.995686 delta=0.637661 count=3 cost=1139.112061 Performer Info (2): build: 0.628696 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Adding to a Container ready to addToLists called addToDynamicList Adding a new branch Final LoadBGF: file name = T-design.bgf Number of Shapes = 7 Number of Polygons = 326 object name = commands skipped = 0 commands unknown = 0 vertices = 1906 triangles = 1034 loading time = 0.016 sec loading rate = 62910.979 tri/sec node: c80db0 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffaa38 Performer Debug (2): cost=1638.000000 (2968.157715) nOccur=1638 start=-0.142526 delta=0.285052 count=1 Performer Debug (2): cost=1219.052124 (2968.157715) nOccur=1724 start=-0.143455 delta=0.285052 count=2 Performer Debug (2): cost=1216.223633 (2968.157715) nOccur=1720 start=-0.395080 delta=0.285052 count=2 Performer Debug (2): points: 0.00s deltas: 0.02s pcost: 0.08s qsort: 0.00s cost: 0.01s Performer Info (2): coord 0: start=-0.395080 delta=0.285052 count=2 cost=1216.223633 hits 0x7fffa840 Performer Debug (2): cost=1638.000000 (945.699707) nOccur=1638 start=-0.500000 delta=1.000000 count=1 Performer Debug (2): cost=1185.110962 (945.699707) nOccur=1676 start=-0.506499 delta=1.000000 count=2 Performer Debug (2): cost=1179.454102 (945.699707) nOccur=1668 start=-1.471412 delta=1.000000 count=2 Performer Debug (2): cost=1161.069336 (945.699707) nOccur=1642 start=-1.478644 delta=1.000000 count=2 Performer Debug (2): cost=969.948425 (963.020203) nOccur=1680 start=-1.450529 delta=0.972015 count=3 Performer Debug (2): points: 0.00s deltas: 0.16s pcost: 0.39s qsort: 0.01s cost: 0.17s Performer Info (2): coord 1: start=-1.450529 delta=0.972015 count=3 cost=969.948425 Performer Info (2): build: 0.882107 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Adding to a Container ready to addToLists called addToDynamicList Adding a new branch Performer Warning (2): pfuAddPoly() Degenerate polygon has 0 vertices Final LoadBGF: file name = T-business.bgf Number of Shapes = 11 Number of Polygons = 610 object name = commands skipped = 0 commands unknown = 0 vertices = 3300 triangles = 1774 loading time = 0.000 sec loading rate = 5644540.323 tri/sec node: ca7d80 Partition Attributes: 0.000000 0.000000 0.000000 building part.... hits 0x7fffa9c8 Performer Debug (2): cost=4848.000000 (11371.490234) nOccur=4848 start=-0.112974 delta=0.225948 count=1 Performer Debug (2): cost=4809.740234 (11371.490234) nOccur=6802 start=-0.117493 delta=0.225948 count=2 Performer Debug (2): cost=4287.895508 (11371.490234) nOccur=6064 start=-0.128028 delta=0.225948 count=2 Performer Debug (2): cost=4272.338867 (11371.490234) nOccur=6042 start=-0.130040 delta=0.225948 count=2 Performer Debug (2): cost=4265.975098 (11371.490234) nOccur=6033 start=-0.146801 delta=0.225948 count=2 Performer Debug (2): cost=4261.025391 (11371.490234) nOccur=6026 start=-0.150707 delta=0.225948 count=2 Performer Debug (2): cost=4088.491455 (11371.490234) nOccur=5782 start=-0.161607 delta=0.225948 count=2 Performer Debug (2): cost=4085.662842 (11371.490234) nOccur=5778 start=-0.161777 delta=0.225948 count=2 Performer Debug (2): cost=4084.248779 (11371.490234) nOccur=5776 start=-0.308885 delta=0.225948 count=2 Performer Debug (2): cost=3517.149170 (11371.490234) nOccur=4974 start=-0.309382 delta=0.225948 count=2 Performer Debug (2): points: 0.00s deltas: 0.04s pcost: 0.16s qsort: 0.01s cost: 0.06s Performer Info (2): coord 0: start=-0.309382 delta=0.225948 count=2 cost=3517.149170 hits 0x7fffa670 Performer Debug (2): cost=3546.140381 (2798.994141) nOccur=5015 start=-1.443584 delta=0.971790 count=2 Performer Debug (2): cost=2943.331543 (2798.994141) nOccur=5098 start=-1.465854 delta=0.971790 count=3 Performer Debug (2): cost=2900.030273 (2798.994141) nOccur=5023 start=-1.447928 delta=0.971790 count=3 Performer Debug (2): cost=2898.298340 (2798.994141) nOccur=5020 start=-1.430002 delta=0.953864 count=3 Performer Debug (2): points: 0.00s deltas: 0.25s pcost: 0.87s qsort: 0.01s cost: 1.72s Performer Info (2): coord 1: start=-1.430002 delta=0.953864 count=3 cost=2898.298340 Performer Info (2): build: 3.153576 secs Partition Attributes: 0.000000 0.000000 0.500000 ...done building part Dez Load time = 61.627 sec Performer Info (2): Selecting Node Named: A Performer Info (2): Beginning collision setup. Performer Info (2): End collision setup. Performer Info (2): No Databases loaded. Performer Notice: Using 60Hz video rate on screen 0 Performer Info (2): Initialized 1 Pipe(s) Performer Info (2): Initialized 1 Channel(s) Performer Info (2): Nothing Selected *** Scene Stats: *------------------------------------------------------------------------------* *** *** Average Frame Stats: *** --------------------- Num Frames: 59, update period: 2.000000 secs GSet Stats: gsets=3 flat=0 highlighted=0, pvcolor=3 pvnormal=0 texcoord=0 Geometry Stats: GL Primitives: total=12 tris=12 lines=0 points=0 primsPerGSet=4.00 primsPerGState=-1.00 gsetsPerGState=-1.00 Attrs: verts=24 colors=24 normals=0 texcoords=0 bytes=768 Tris: avg tris per strip = 0.00 Number of tris in strips of length: length 1: 0 length 2: 12 length 3: 0 length 4: 0 length 5: 0 length 6: 0 length 7: 0 length 8: 0 length 9: 0 length 10: 0 length 11: 0 length 12: 0 length 13: 0 length 14+: 0 Mode Change Stats: Enables: lighting=2 texturing=2 fog=0 ctab=0 wireframe=0 hlight=0 shade=0 cullface=2 afunction=0 aa=0 transp=0 decal=0 textures=0 detailTextures=0 texLoads=0 texBytes=0 texEnv=1 materials=0 lights=1 lmodels=1 fog=0 ctabs=0 hlights=0 Mode Call Stats: Enables: lighting=2 texturing=2 fog=1 ctab=2 wireframe=2 hlight=2 shade=2 cullface=2 afunction=2 aa=0 transp=2 decal=2 textures=0 detailTextures=0 texLoads=0 texBytes=0 texEnv=1 materials=0 lights=1 lmodels=1 fog=0 ctabs=0 hlights=0 State Stats: gstates=0 push=2 pop=2 flush=2 basic=0 Transform Stats: pushmat=1 popmat=1 loadmat=0 multmat=1 translate=0 rotate=0 scale=0 Frame times (msecs): total=97.3 app=0.6 cull=0.6 draw=10.9 isect=0.0 Frame counts: total=59 app=59 cull=59 draw=59 isect=0 Frames=59 Misses: total=0 app+cull=0 draw=0 Database Stats: Visible nodes=7 groups=5 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=1 layers=0 sequences=0 lsources=1 Evaluated App nodes=0 groups=0 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=0 layers=0 sequences=0 lsources=0 Evaluated Cull nodes=1 groups=0 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=0 layers=0 sequences=0 lsources=1 Cull Hierarchy Stats: Cull traversed nodes=0 groups=17 geodes=18 bboards=0 switches=0 LODs=0 (fade=0) SCSs=1 DCSs=5 layers=0 sequences=0 lsources=1 Cull Result Stats: Nodes: total traversed=41 test=40 accept=1 reject=34 non-trivial=6 GSets: total=0 test=0 accept=0 reject=0 non-trivial=0 sorted=0 *** *** Previous Frame Stats: *** --------------------- Frame = 1172 GSet Stats: gsets=3 flat=0 highlighted=0, pvcolor=3 pvnormal=0 texcoord=0 Geometry Stats: GL Primitives: total=12 tris=12 lines=0 points=0 primsPerGSet=4.00 primsPerGState=-1.00 gsetsPerGState=-1.00 Attrs: verts=24 colors=24 normals=0 texcoords=0 bytes=768 Tris: avg tris per strip = 0.00 Number of tris in strips of length: length 1: 0 length 2: 12 length 3: 0 length 4: 0 length 5: 0 length 6: 0 length 7: 0 length 8: 0 length 9: 0 length 10: 0 length 11: 0 length 12: 0 length 13: 0 length 14+: 0 Mode Change Stats: Enables: lighting=2 texturing=2 fog=0 ctab=0 wireframe=0 hlight=0 shade=0 cullface=2 afunction=0 aa=0 transp=0 decal=0 textures=0 detailTextures=0 texLoads=0 texBytes=0 texEnv=1 materials=0 lights=0 lmodels=1 fog=0 ctabs=0 hlights=0 Mode Call Stats: Enables: lighting=2 texturing=2 fog=1 ctab=2 wireframe=2 hlight=2 shade=2 cullface=2 afunction=2 aa=0 transp=2 decal=2 textures=0 detailTextures=0 texLoads=0 texBytes=0 texEnv=1 materials=0 lights=0 lmodels=1 fog=0 ctabs=0 hlights=0 State Stats: gstates=0 push=2 pop=2 flush=2 basic=0 Transform Stats: pushmat=0 popmat=0 loadmat=0 multmat=0 translate=0 rotate=0 scale=0 Frame times (msecs): total=76.7 app=0.4 cull=0.3 draw=10.6 isect=0.0 Frame counts: total=1 app=1 cull=1 draw=1 isect=0 Frames=59 Misses: total=0 app+cull=0 draw=0 Database Stats: Visible nodes=0 groups=0 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=0 layers=0 sequences=0 lsources=0 Evaluated App nodes=0 groups=0 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=0 layers=0 sequences=0 lsources=0 Evaluated Cull nodes=0 groups=0 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=0 layers=0 sequences=0 lsources=0 Cull Hierarchy Stats: Cull traversed nodes=0 groups=2 geodes=0 bboards=0 switches=0 LODs=0 (fade=0) SCSs=0 DCSs=0 layers=0 sequences=0 lsources=0 Cull Result Stats: Nodes: total traversed=2 test=2 accept=0 reject=2 non-trivial=0 GSets: total=0 test=0 accept=0 reject=0 non-trivial=0 sorted=0 From guest Wed Apr 20 13:59:04 1994 From: "Stephen Joyce {75069}" Message-Id: <9404202057.AA04204@swlrgk> To: lau@ai.sri.com Subject: Large MultiGen/Performer databases Cc: info-performer@sgi.sgi.com Status: OR We are building a data base that would probably not be gigabytes of terrain, but I'm told that if the MultiGen hierarchy is organized spatially, and possibly optimized (in Performer, use pfPartition), that this will greatly speed the traversing time. From guest Wed Apr 20 20:11:29 1994 Message-Id: <9404210311.AA27113@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Re: Large MultiGen/Performer databases In-Reply-To: Your message of "Wed, 20 Apr 94 16:57:57 EDT." <9404202057.AA04204@swlrgk> Date: Wed, 20 Apr 94 20:11:23 -0700 From: Jim Helman Status: OR It's always best to spatially organize the scene graph for culling. pfPartitions speed up intersection traversals, e.g. terrain following, but do not affect culling. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Apr 21 10:28:34 1994 Message-Id: <199404211727.NAA20589@favorite.cis.ohio-state.edu> To: info-performer@sgi.sgi.com My question concerns optimizing performance from Performer. I'm running Performer 1.2 (1.1 documentation) on a 3 pipe (RE^2) Onyx with MCO and 8 150MHz R4400's. Each pipe is divided into 2 1280x1024's for a total of 6 video channels. Due to the geometry of the display surface and the projection system, this requires 6 individual channels in Performer. The projection system blends an overlap of adjacent images and a separate pespective calculation is required for each channel, so I can not run as a 3 channel system with larger viewports. Initially, I started writing code from "scratch" and was able to get a 6 channel scene up and running, but with approximately half the frame rate of perfly. I proceded to modify perfly to display the proper geometry. I'm a performer newbie so it is very possible that I did not change all of the required code. The modified perfly's frame rate dropped to approximately half of the rate of the unmodified version. Guesses as to why ... - I need to add additional logic to the cull callback - The unmodified version only runs 3 channels and the modified version must transform twice the number of polygons for a 6 channel scene. - Not enough processors for 6 channels with draw and cull for each channel - Other Questions - How many processes should run for optimal performance for 6 channels ? 1 app with 1 cull and 1 draw per channel (total 13)? or 1 app with 1 cull and 1 draw per pipe (total 7) ? or 1 app with 1 cull per channel and 1 draw per pipe (total 10) ? I didn't quite understand how the multiprocess configuration options treated channels versus pipes. Any information would be appreciated... Mark Visconti LTSI, WPAFB, Dayton, OH From guest Thu Apr 21 16:00:01 1994 Date: Thu, 21 Apr 94 16:00:24 -0700 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9404212300.AA06186@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: pfInvertMat Within Performer 1.0, is there a bug in the routine: pfInvertMat or any of the private routines it calls (pfLUDecompMat) such that it fails when inverting a singular matrix, as opposed to returning FALSE? I am testing for this, but the routine never returns and instead gives me a 'Floating point exception' core dump. Are there any work-arounds, or do I wait for 1.2? From guest Fri Apr 22 08:32:07 1994 Return-Path: Date: Fri, 22 Apr 94 10:32:03 -0500 From: reiners@ncsa.uiuc.edu (Dirk Reiners) Message-Id: <9404221532.AA00600@nlsgi5.ncsa.uiuc.edu> To: info-performer@sgi.sgi.com Subject: multiprocessing/ multibuffering ??? In an article some time ago Jim Helman wrote: > on the parent geode or if you multibuffer the geoset so you don't What is a multibuffered geoset? How to create one? How does Performer handle multiprocessing with any of the nodes, like DCS'es etc.? I couldn't find any hint on doing this or possible problems in the docs. Did I miss the right page(s)? Thanks Dirk From guest Fri Apr 22 09:24:35 1994 Message-Id: <9404221624.AA29351@surreal.asd.sgi.com> To: reiners@ncsa.uiuc.edu (Dirk Reiners) Cc: info-performer@sgi.sgi.com Subject: Re: multiprocessing/ multibuffering ??? In-Reply-To: Your message of "Fri, 22 Apr 94 10:32:03 CDT." <9404221532.AA00600@nlsgi5.ncsa.uiuc.edu> Date: Fri, 22 Apr 94 09:24:27 -0700 From: Jim Helman "Multibuffering" refers to maintaining multiple copies of an object or its attributes for the different stages in Performer's software pipeline. When Performer runs multiprocessed, the scene graph is multibuffered with the APP, ISECT and each pfPipe's CULL process having its own copy of each scene graph node. Updates propagate frame-accurately from the APP stage of the pipeline. Each frame, all changes to the scene graph (e.g. - a change to a DCS matrix or to the scene graph topology) are copied from the APP by the ISECT and CULL processes. Dynamic geometry also requires multibuffering for frame-accuracy and to avoid data collisions. Performer does not internally multibuffer pfGeoSets because in most databases the majority of the geometry is static and keeping extra copies of geometry would waste a lot of memory. The next major release of Performer will have intrinsic support for multibuffered geometry and morphing. Until then, you can multibuffer geometry yourself in Performer 1.X using a switch node with multiple pfGeodes and pfGeoSets underneath it. Just set the switch value appropriately each frame and modify the corresponding geometry in the APP process. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Fri Apr 22 14:37:01 1994 From: Kevin Mueller Subject: acreate() To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi I'm trying to use acreate() to no sucsees. :( I would like to create an area where multiple processes can allocate memory from. I want commands like pfMalloc() and pfNewGState() to use this area. Once this is done, can multiple process have acces to pfNode's and states created in this arena? A general overview and quick example would help. I'm just not getting it from the man page. Thanks in advance Kevin From guest Mon Apr 25 10:38:20 1994 Message-Id: <9404251836.ZM5910@unknown.zmail.host> Date: Mon, 25 Apr 1994 18:36:29 +0100 In-Reply-To: Jim Helman "Re: Texture Coordinates" (Jan 13, 10:40am) References: <9401131840.AA09386@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Flashing on and off of colours Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi I had a posting a few days ago about texture flashing on and off. I have since investigated this further, and found out that it isn't texture, but in fact appears to be the ambient colour for some of the polygons either saturating at peak white or peak black. So what happens is, using a program adapted from simple.c, reading in the Performer village through loadflt, as I approach some building, at a subjective distance of about a 1/4 mile, the roofs on some of the houses appear to flash on and off (changing colour). One test I tried was setting the light colour to be 1.0, 0.0, 0.0, with ambient for that one light set to be 0.0, 0.0, 0.0. so I should have a scene rendered in various shades of red. What happens though is that the roofs of some of the houses flash on and off with non-red coulours. I disabled texturing, and hardware lighting in the draw callback, and still this happens. The demo code for perfly that I have works okay though, but I can't discover what it is doing that is making the difference (I have hacked perfly ruthlessly to try and find the problem). Does anyone have any ideas. I have spent several days looking at this, with no success. As perfly seems to have some magic element that does not have this problem, I could just adapt it, but I've spent so long on this I really would like to know whats going on. Anyone any ideas? Thanks for your time Richard Gallery From guest Wed Apr 27 07:01:38 1994 Date: Mon, 25 Apr 1994 17:46:48 -0400 From: "Timothy Cormier {76857}" Message-Id: <199404252146.AA05178@swlgbi.msd.ray.com> To: info-performer@sgi.sgi.com I am trying to understand why Onyx based Performer applications cannot pipe their display to an Indigo workstation. I have set the DISPLAY enviornment variable properly on the Onyx, and have set xhost on the Indigo to allow the pipe. I have I heard about GL, OGL and now DGL! Can someone give me an explaination as to why I cannot display properly on another SGI machine. Intrigued! From guest Mon Apr 25 18:26:31 1994 Message-Id: <00581.2850143389.1269@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Mon, 25 Apr 1994 17:40:44 PST Subject: Re: >Flashing on and off of Reply to: RE>>Flashing on and off of c >Hi > >I had a posting a few days ago about texture flashing on and >off. I have since investigated this further, and found out >that it isn't texture, but in fact appears to be the ambient >colour for some of the polygons either saturating at peak white >or peak black. >Thanks for your time >Richard Gallery I have seen similarly "flashing" geometry. It happens on machines without hardware z-buffer, when there is co-planer geometry in the data base. On an Indigo XS24 with 4 stencil planes and no z-buffer for instance. I suspect that Performer requires a z-buffer (and stencil planes) in order to render co-planer geometry correctly, although the Performer 1.0 manual page for pfLayer says that only a "hardware stencil buffer" is required. The visual results imply [ ... quick check of the stencil(3g) manual page] that the FAIL and ZPASS cases are handled correctly by Performer, but perhaps not the PASS case? (Corrections welcome ;-) Note also the multi-sampling configurations can alter the *apparent* existance of both stencil and z buffers. Regards, Mark Barnes Member Technical Staff multigen!marcus@uunet.UU.NET MultiGen Inc. (408) 247 4326 From guest Tue Apr 26 01:50:07 1994 Return-Path: Date: Tue, 26 Apr 94 17:41:50 +0900 From: wry@dimwit.dst.nk-exa.co.jp (Masahiko Yamanaka) Message-Id: <9404260841.AA18229@dimwit.dst.nk-exa.co.jp> To: info-performer@sgi.sgi.com Subject: [Q] Can I access a runtime database from an other application ? Almost of all Performer runtime database are constructed by arena using acreate(). I want to access it from my independent program. Are there any way except using shmget() ? Thanks. -- Masahiko Yamanaka From guest Tue Apr 26 08:40:09 1994 Date: Tue, 26 Apr 1994 08:41:46 -0700 From: Ramin Samadani Message-Id: <199404261541.IAA08669@abney.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: help! Cc: ramin@gauss.arc.nasa.gov Could I please get off this mailing list. I don't know how I got on it, or how to get off, but I certainly didn't join through any effort of mine. Thank you, Ramin Samadani From guest Tue Apr 26 09:48:33 1994 Date: Tue, 26 Apr 94 09:56:26 PDT From: Fletcher Robinson Message-Id: <9404261656.AA16788@world.nad.northrop.com> To: info-performer@sgi.sgi.com Subject: PVI Hi , anyone out there using Performer for cockpit displays ? I know other GUIs exist , like VAPS , etc. , but it seems to me that Performer would be a better 'performer' allow more creative flexibility and easier integration with existing applications than a canned package like VAPS . Anyone have experiences comparing these two approaches ? -- ``''' ( O O ) (_) -----------------------------------ooO---Ooo---------------------------------- - Fletcher Karl Robinson | Phone : 310 948 0859 - - Computer Engineering Specialist | 310 948 7359 - - Department 71/N500/XA | - - Advanced Technology & Design Center | Fax : 310 948 7345 - - B-2 Advanced Systems Division | - - Northrop Corporation | Email : - - 8900 East Washington Boulevard | - - Pico Rivera California 90660 3783 | frobinso@world.nad.northrop.com - ------------------------------------------------------------------------------ From guest Tue Apr 26 11:25:28 1994 for portal!sgi.com!info-performer id AA00592; Tue, 26 Apr 94 10:41:08 -0700 From: "David Cooper" Message-Id: <9404261041.ZM900@nether.coryphaeus.com> Date: Tue, 26 Apr 1994 10:41:01 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com, ag@nether.coryphaeus.com Subject: Re: PVI Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Apr 26, 9:56am, Fletcher Robinson wrote: > Subject: PVI > Hi , anyone out there using Performer for cockpit displays ? I > know other GUIs exist , like VAPS , etc. , but it seems to me > that Performer would be a better 'performer' allow more creative > flexibility and easier integration with existing applications than > a canned package like VAPS . Anyone have experiences comparing these > two approaches ? Coryphaeus Software sell a package that will take displays or models defined within their Designers Workbench modelling tool and animate them using Performer without the need for a single line of source code, giving optimal performance with minimum effort. -- From guest Tue Apr 26 12:04:23 1994 Message-Id: <9404261904.AA20570@surreal.asd.sgi.com> To: wry@dimwit.dst.nk-exa.co.jp (Masahiko Yamanaka) Cc: info-performer@sgi.sgi.com Subject: Re: [Q] Can I access a runtime database from an other application ? In-Reply-To: Your message of "Tue, 26 Apr 94 17:41:50 +0900." <9404260841.AA18229@dimwit.dst.nk-exa.co.jp> Date: Tue, 26 Apr 94 12:04:07 -0700 From: Jim Helman You can't get access to the scene graph and its associated Performer state from an unrelated process (i.e. one not forked from the original Performer application). If you want read-only access to the scene graph, your best bet would be to sproc off a thread in the ISECT process. The APP process is another alternative, but you will have to be careful that the modifications you are making in the main APP thread do not leave the scene graph in an inconsistent state while the other thread is examining it. In 1.2, database modification is only allowed in the main APP thread, so in any event your other thread should be read-only. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Apr 28 04:50:25 1994 From: Mark Coyle Subject: Re: PVI (fwd) To: info-performer@sgi.sgi.com Message-Id: <9404281148.AA13706@dexter.psych.umn.edu> X-Mailer: ELM [version 2.4 PL6] Content-Type: text Content-Transfer-Encoding: 7BIT Content-Length: 2345 Forwarded message: > From guest@holodeck.asd.sgi.com Tue Apr 26 13:57:32 1994 > From: "David Cooper" > Message-Id: <9404261041.ZM900@nether.coryphaeus.com> > Date: Tue, 26 Apr 1994 10:41:01 -0700 > X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) > To: info-performer@sgi.com, ag@nether.coryphaeus.com > Subject: Re: PVI > Content-Type: text/plain; charset=us-ascii > Mime-Version: 1.0 > > > On Apr 26, 9:56am, Fletcher Robinson wrote: > > Subject: PVI > > Hi , anyone out there using Performer for cockpit displays ? I > > know other GUIs exist , like VAPS , etc. , but it seems to me > > that Performer would be a better 'performer' allow more creative > > flexibility and easier integration with existing applications than > > a canned package like VAPS . Anyone have experiences comparing these > > two approaches ? > > Coryphaeus Software sell a package that will take displays or models defined > within their Designers Workbench modelling tool and animate them using > Performer without the need for a single line of source code, giving optimal > performance with minimum effort. > > Well, this is almost true. We have the Coryph. product mentioned (DWB) and we are using it for cockpit displays. Really a nice tool, but it should be for the money (~17K). The tool to create models allows files to be saved under many formats, including dwb and flt formats. They also provide a loader for dwb files to be loaded into Performer. The feature mentioned above can't be used under Performer, as the "runtime module" is used for it. But, it is even easier than Performer. One just needs to make a half dozen library calls and your done. Within the modeler you set up these things called "links" which link properties of parts of the display (i.e. the compass rose movement) with a shared memory variable. All you do in the application program (if you are using the libraries) is update the shared memory variable and the display does its thing. Links can be used for translation, rotation, color, scale, etc. We are using it for the cockpit Primary Flight Display, the Navigational Display, and an FMS keypad display. I do recomend it, a very nice tool and the company is ok to work with. i.e. they have been able to answer every question we have had. Plug for DWB ends here. (-:). mark From guest Fri Apr 29 12:03:28 1994 Message-Id: <00581.2850465967.1277@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Fri, 29 Apr 1994 11:23:10 PST Subject: Re: >Remote .vs Local IRIS P Reply to: RE>>Remote .vs Local IRIS Pe Hi Michael, Michael Jones wrote: >Lew sent the following note and then asked me to send it out >to the info-performer mailing list. How common is this type >of situation? Comments? > >On Apr 29, 7:45am, Lew Hitchner wrote: >> Subject: Re: Remote .vs Local IRIS Performer graphics >:In environments where there's one >:"big" machine (e.g., 4 or 8 CPU Onyx) and many networked "small" >:machines (e.g., Indigos), developers usually develop and test on the >:small machines (single CPU) on their desktop. But, you also need to >:check out your latest development on the "big machine" with its OS, >:multi-CPU, and graphics hardware environment. But, in large >:organizations the console of "big machine" may not always be available >:on demand for every developer whenever he or she wants to test their >:latest "enhancement". This is similar to my development environment at MultiGen Inc.. I do alot of the OpenFlight loader development and initial testing on an Indigo. Our ONYX RE and Crimson RE machines are typically reserved for customer training and in-house demos. For features, such as detail textures, that require a Reality Engine, I schedule development time on one of these machines. During this time, I "move to another seat". Remote display would be convenient for many things, but this brings up a question. I would want the remote ONYX to display detail textures (or other RE features) on my local Indigo display. How would this be done? Perhaps OpenGL would support this? There are situations when you have to be testing Performer software solely on the target platform. Regards, Mark Barnes Member Technical Staff multigen!marcus@uunet.UU.NET MultiGen Inc. (408) 247 4326 From guest Mon May 2 16:19:56 1994 From: hill_b@ameig1.navsea.navy.mil (Brian Hill) Message-Id: <199405030029.AA21661@ameig1.navsea.navy.mil> Subject: Anyone know anything about VEGA? To: info-performer@sgi.sgi.com Date: Mon, 2 May 94 19:29:03 CDT X-Mailer: ELM [version 07.00.00.00 (2.3 PL11)] Greetings, I would like to apologize in advance if my question is inappropriate for this forum. I currently use a product called VisionWorks to build visual simulations. I have read alot about Performer and have tinkered around with it some. Unfortunately I do not have much experience with the "details" of how to set up and run a Performer based application. I prefer programming at a higher level and would like to avoid having to get too involved with the real inner workings of Performer. I need to concentrate more on the application specifics and less on the visualization details. VisionWorks has provided this environment for me in the GL world. My question is about a product called VEGA (it is from the same company that wrote VisionWorks). VEGA is based on Performer. Does anyone have any experience with it and does anyone have anything to say about what is good or bad about it? Thanks for your time. =================================================================== Brian Hill | Advanced Marine Enterprises, Inc.| CSD Section Chief | Suite 1300 | (703)415-3080 | 1725 Jefferson Davis Hwy. | hill_b@ameig1.navsea.navy.mil | Arlington VA, 22202 | =================================================================== From guest Wed May 4 05:05:33 1994 From: "Ran Yakir" Message-Id: <9405041204.ZM5049@rea1.bvr.co.il> Date: Wed, 4 May 1994 12:04:31 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Drawing a scene twice Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hi All How does one replace current vertices' colors with new colors? (The database is originally in Flight format). I succeeded unbinding the texture coords, however binding new colours using the command pfGSetAttr(gd, PFGS_COLOR4, PFGS_OVERALL, Colour, NULL); where Colour is pfVec4 Colour = {rrr.rrr, ggg.ggg, bbb.bbb, aaa.aaa} (called through a db traversal using has pfuTraverse) resulted in a coloured scene which is a mixture of the previous color and the newly binded colour. Thanks -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Thu May 5 12:48:18 1994 Date: Thu, 5 May 94 21:48:04 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405051948.AA25388@ligsg8.epfl.ch> To: info-performer@sgi.sgi.com Subject: black objects on 1.2 Reply-To: matomira@epfl.ch Hello, I have just ported a program to 1.2 . The terrain and objects get rendered, but totally black. Is there anything to add to the material, state definition procedure or could something like this be related to getting a no virtual swap space warning at the beginning? The materials are not NULL, that's for sure. Also, loading some specific .sgo objects crashes the program, which did not happen before either. Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Thu May 5 14:06:06 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405052105.AA11883@tubes.asd.sgi.com> Subject: Re: black objects on 1.2 To: guest (Fernando D. Mato Mira) Date: Thu, 5 May 94 14:05:50 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9405051948.AA25388@ligsg8.epfl.ch>; from "Fernando D. Mato Mira" at May 5, 94 9:48 pm X-Mailer: ELM [version 2.3 PL8] > > > Hello, > > I have just ported a program to 1.2 . The terrain and objects > get rendered, but totally black. Is there anything to add to the > material, state definition procedure or could something like > this be related to getting a no virtual swap space warning at > the beginning? The materials are not NULL, that's for sure. Try disabling color mode on your materials: pfMtlColorMode(mtl, PFMTL_BOTH, PFMTL_CMODE_COLOR); The default is for colors(cpack, c4f) to replace the diffuse and ambient color of the current material. Thus you might get black geometry if you clear the screen to black and make no other color commands. From guest Fri May 6 10:30:30 1994 Fri, 6 May 1994 10:30:22 -0700 for <@ucsd.ucsd.edu:info-performer@sgi.com> From: va90sap@sgva-xs4.ucsd.edu (Payton White) Message-Id: <9405061730.AA02980@sgva-xs4> Subject: Collision/Compiling Problems To: info-performer@sgi.sgi.com Date: Fri, 6 May 1994 10:30:12 -0800 (PDT) Cc: sbrown@sgva-xs4.ucsd.edu (Sheldon Brown) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1922 Status: OR I am having some problems getting collision detection to work in a simulation that I am writing using Performer 1.2. Considering that the faq and release notes warned that the pfuCollide functions are jumpy I set out writing my own. After implementing simple terrain following (just like pfuCollideGrnd returning zpr) I decided to test out the pfu version. Here's the problem: When I compile my code that calls pfNodeTravMask, pfSegsIsectNode and pfQueryHit everything goes nicely and I have great performance. When I try to use the pfuCollideGrnd function as a replacement with all of the same links (including a link to libpfutil.a) and all of the same includes (including #include "/usr/src/Performer/include/pfutil.h") I get the following: cc pfobj2.o vrnav.o pftri.o vr.o -o vr -xansi -D__STDC__ -I. -I.. -I/usr/src/Performer/include -I/usr/include/Performer /usr/lib/libpf.a /usr/src/Performer/lib/libpfutil.a /usr/lib/libpr.a -lmpc -limage -lfm -lgl_s -lX11 -lm -lfpe -lC /usr/bin/ld: Undefined: pfNodeTravMask pfMQueryHit pfSegsIsectNode pfQueryHit *** Error code 1 Stop. So almost identical versions of code are having problems finding functions that should be easily found. This isn't the first time I have had a problem with mysteriously undefined functions (just the most frustrating). Obviously I have overlooked some small something, or we have installed Performer incorrectly. Any insight is greatly appreciated. -- Visualization << SGI >> Simulation -- Payton R. White __ __ __ prwhite@ucsd.edu / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From guest Fri May 6 11:57:23 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405061857.AA13161@tubes.asd.sgi.com> Subject: Re: Collision/Compiling Problems To: guest (Payton White) Date: Fri, 6 May 94 11:57:07 PDT Cc: info-performer@sgi.sgi.com, sbrown@sgva-xs4.ucsd.edu In-Reply-To: <9405061730.AA02980@sgva-xs4>; from "Payton White" at May 6, 94 10:30 am X-Mailer: ELM [version 2.3 PL8] > > I am having some problems getting collision detection to work > in a simulation that I am writing using Performer 1.2. Considering that > the faq and release notes warned that the pfuCollide functions are > jumpy I set out writing my own. After implementing simple terrain > following (just like pfuCollideGrnd returning zpr) I decided to test > out the pfu version. Here's the problem: > > When I compile my code that calls pfNodeTravMask, pfSegsIsectNode and > pfQueryHit everything goes nicely and I have great performance. > > When I try to use the pfuCollideGrnd function as a replacement > with all of the same links (including a link to libpfutil.a) and all of > the same includes (including #include "/usr/src/Performer/include/pfutil.h") > I get the following: > > > cc pfobj2.o vrnav.o pftri.o vr.o -o vr -xansi -D__STDC__ -I. -I.. > -I/usr/src/Performer/include -I/usr/include/Performer /usr/lib/libpf.a > /usr/src/Performer/lib/libpfutil.a /usr/lib/libpr.a -lmpc -limage -lfm > -lgl_s -lX11 -lm -lfpe -lC > > /usr/bin/ld: > Undefined: > pfNodeTravMask > pfMQueryHit > pfSegsIsectNode > pfQueryHit > *** Error code 1 > > Stop. > > > So almost identical versions of code are having problems finding functions > that should be easily found. This isn't the first time I have had a > problem with mysteriously undefined functions (just the most frustrating). > Obviously I have overlooked some small something, or we have installed > Performer incorrectly. > > Any insight is greatly appreciated. > You need to put libpfutil before libpf since libpfutil references libpf functions. From guest Fri May 6 12:14:15 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405061913.AA13217@tubes.asd.sgi.com> Subject: Re: Drawing a scene twice To: guest (Ran Yakir) Date: Fri, 6 May 94 12:13:59 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9405041204.ZM5049@rea1.bvr.co.il>; from "Ran Yakir" at May 4, 94 12:04 pm X-Mailer: ELM [version 2.3 PL8] > > Hi All > > > How does one replace current vertices' colors with new colors? > (The database is originally in Flight format). > I succeeded unbinding the texture coords, however binding new > colours using the command > > pfGSetAttr(gd, PFGS_COLOR4, PFGS_OVERALL, Colour, NULL); > > where Colour is > > pfVec4 Colour = {rrr.rrr, ggg.ggg, bbb.bbb, aaa.aaa} > > (called through a db traversal using has pfuTraverse) resulted > in a coloured scene which is a mixture of the previous color and > the newly binded colour. > > I need more information. What does your traversal routine look like? Maybe you're not finding all the pfGeoSets in your scene. One concern is that "Colour" is not allocated out of shared memory so that if you multiprocess you might have problems. From guest Tue May 10 02:40:54 1994 Date: Tue, 10 May 94 07:36:18 GMT From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9405100736.AA01546@rea1.bvr.co.il> To: info-performer@sgi.sgi.com Subject: Colour alteration with cloned nodes Status: OR Hi All, My application involves a two pass rendered scene. The first pass the application draws the scene as it is (i.e. as it was modeled in MultiGen with textures, rgb colours for each vertex, etc.). In the second pass I would like to draw the scene with a single texture (using texgen) and a single colour. To draw the scene twice I have cloned the database. Enforcing the database to use a single texture is easy, using the an override command as shown bellow: pfApplyTEnv(env); pfApplyTex(missjan); pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_ON); /* draw the scene */ pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_OFF); However can I do the same for the colour? It would be nice if I could call say "pfApplyColor()" and then use pfOverride() to lock the colour in the GeoSets. Thanks \________ \___ \_________ \__________ \___ \__________ \___ \___ \___ \___ \___ Alon J Rosenfeld \___ \___ \___ \___ \___ BVR Technologies Ltd. \__________ \___ \___ \_________ 1 Korazim st. Givatayim, Israel \__________ \___ \___ \_________ Tel: 972-3-571 5671 \___ \___ \__________ \___ \___ Fax: 972-3-571 5668 \___ \___ \________ \___ \___ Home: 972-3-683 6020 \___ \___ \______ \___ \___ Email: alon@bvr.co.il From guest Tue May 10 02:18:38 1994 Date: Tue, 10 May 94 09:16:39 GMT From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9405100916.AA01984@rea1.bvr.co.il> To: info-performer@sgi.sgi.com Subject: Colour alteration with cloned nodes Hi All, My application involves a two pass rendered scene. The first pass the application draws the scene as it is (i.e. as it was modeled in MultiGen with textures, rgb colours for each vertex, etc.). In the second pass I would like to draw the scene with a single texture (using texgen) and a single colour. To draw the scene twice I have cloned the database. Enforcing the database to use a single texture is easy, using the an override command as shown bellow: pfApplyTEnv(env); pfApplyTex(missjan); pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_ON); /* draw the scene */ pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_OFF); However can I do the same for the colour? It would be nice if I could call say "pfApplyColor()" and then use pfOverride() to lock the colour in the GeoSets. Meanwhile I am loading the database twice. On the second loaded db I run a pre-process traversal which alters the existing colours in the GeoSets to the desired uniform colour. Thanks \________ \___ \_________ \__________ \___ \__________ \___ \___ \___ \___ \___ Alon J Rosenfeld \___ \___ \___ \___ \___ BVR Technologies Ltd. \__________ \___ \___ \_________ 1 Korazim st. Givatayim, Israel \__________ \___ \___ \_________ Tel: 972-3-571 5671 \___ \___ \__________ \___ \___ Fax: 972-3-571 5668 \___ \___ \________ \___ \___ Home: 972-3-683 6020 \___ \___ \______ \___ \___ Email: alon@bvr.co.il From guest Tue May 10 02:41:38 1994 Date: Tue, 10 May 94 09:40:22 GMT From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9405100940.AA02057@rea1.bvr.co.il> To: info-performer@sgi.sgi.com Subject: Colour alteration with cloned nodes Hi All, My application involves a two pass rendered scene. The first pass the application draws the scene as it is (i.e. as it was modeled in MultiGen with textures, rgb colours for each vertex, etc.). In the second pass I would like to draw the scene with a single texture (using texgen) and a single colour. To draw the scene twice I have cloned the database. Enforcing the database to use a single texture is easy, using the an override command as shown bellow: pfApplyTEnv(env); pfApplyTex(missjan); pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_ON); /* draw the scene */ pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_OFF); However can I do the same for the colour? It would be nice if I could call say "pfApplyColor()" and then use pfOverride() to lock the colour in the GeoSets. Meanwhile I am loading the database twice. On the second loaded db I run a pre-process traversal which alters the existing colours in the GeoSets to the desired uniform colour. Thanks \________ \___ \_________ \__________ \___ \__________ \___ \___ \___ \___ \___ Alon J Rosenfeld \___ \___ \___ \___ \___ BVR Technologies Ltd. \__________ \___ \___ \_________ 1 Korazim st. Givatayim, Israel \__________ \___ \___ \_________ Tel: 972-3-571 5671 \___ \___ \__________ \___ \___ Fax: 972-3-571 5668 \___ \___ \________ \___ \___ Home: 972-3-683 6020 \___ \___ \______ \___ \___ Email: alon@bvr.co.il From guest Wed May 11 12:24:37 1994 From: watsen@netcom.com (Kent Watsen) Message-Id: <199405111924.MAA16419@netcom.com> Subject: Accumulation Buffer To: info-performer@sgi.sgi.com (performer) Date: Wed, 11 May 1994 12:24:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1555 Hi, I have an Onyx RE2 and Performer 1.2. I have spent a week going through the GL advance GL manuals trying to get the accumulation buffer to work with performer in real-time. My best guess is to initialize the ACBUF after calling pfConfig() with the following commands: acsize(16); gconfig(); acbuf(AC_CLEAR, 0.0); I then establish a swap function callback with the following command after initializing my pipe with pfPipeSwapFunc (pipe, swapfunc). Swapfunc() is call once per frame just after the scene has been rendered into the backbuffer. The swapfunc() makes the appropriate ACBUF calls and the calls swapbuffers() as follows: void swapfunc (pfPipe *pipe) { // MOTION BLUR acbuf(AC_MULT, 0.5); acbuf(AC_ACCUMULATE, 1.0); acbuf(AC_RETURN, 1.0); swapbuffers(); } I acheive the desired effect but my frame rate drops to less the one frame every five seconds! I have done some experimentation and have determined that the larger my viewport the slower the ACBUF takes. The standard GL motion blur demos show much greater frame rates being achieved...but how? The fundamental difference in the codes is that I'm using Performer to do my rendering into the backbuffer rather then GL. It looks like all of the processing is being done in software, even though I am making the acbuf() calls. Does anybody have a clue as to what I'm doing wrong. Also, is the accumulation buffer a peice of hardware sitting in the RE2 pipeline or is it just another abstraction of the 40MB video memory included. Kent Watsen Watsen@netcom.com From guest Wed May 11 12:37:36 1994 Message-Id: <199405111936.MAA26697@archimedes.chinalake.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: Tracking camera... Forgive me if this is really basic, but I want to implement a "tracking" camera. That is, a camera which always looks at a particular model. This model will be driven by data, so its position cannot be known before hand. The way I've been going about it is: take the position of the model and subtract the position of the camera. This gives a vector from the camera to the model. The problem now is getting this vector into a hpr form so that I can use the pfChanView function to set the viewing direction. Am I going about this wrong? I've looked in the myriad of Performer function calls to see if there is a conversion from vector to hpr, but can't find any. Is there a "Performer way" that does all this automatically? Thanks in advance! jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Dude Internet: jan@archimedes.nwc.navy.mil Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA Naval Air Warfare Center kc6uth@kc6uth.ampr.org -Weapons Division [44.17.2.6] From guest Wed May 11 13:01:40 1994 From: barham@gnarly.cs.nps.navy.mil (paul barham) Message-Id: <9405111940.AA19795@gnarly.cs.nps.navy.mil> Subject: Re: Tracking camera... To: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Date: Wed, 11 May 1994 12:40:21 -0700 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <199405111936.MAA26697@archimedes.chinalake.navy.mil> from "Jan A. Barglowski" at May 11, 94 12:36:22 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2469 > > Forgive me if this is really basic, but I want to implement a "tracking" > camera. That is, a camera which always looks at a particular model. This > model will be driven by data, so its position cannot be known before hand. > > The way I've been going about it is: take the position of the model and > subtract the position of the camera. This gives a vector from the camera > to the model. The problem now is getting this vector into a hpr form so > that I can use the pfChanView function to set the viewing direction. > > Am I going about this wrong? I've looked in the myriad of Performer > function calls to see if there is a conversion from vector to hpr, but > can't find any. Is there a "Performer way" that does all this > automatically? > > Thanks in advance! > > jan. > > > Jan Anthony Barglowski Phone: (619) 927-1057 > Computer Dude Internet: jan@archimedes.nwc.navy.mil > Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA > Naval Air Warfare Center kc6uth@kc6uth.ampr.org > -Weapons Division [44.17.2.6] > > Here is a subroutine from our NPSNET-IV virtual world simulator which will perform the operation you need (in C++): void compute_hpr ( pfVec3 &from_pos, pfVec3 &to_pos, pfVec3 &hpr_result ) { float bearing_angle; float pitch_angle; float ordered_heading; float target_dist; target_dist = pfDistancePt3 ( to_pos, from_pos ); bearing_angle = atan2f( (from_pos[Y] - to_pos[Y]), (from_pos[X] - to_pos[X]) ); pitch_angle = RAD_TO_DEG * asinf( (to_pos[Z] - from_pos[Z])/target_dist ); ordered_heading = RAD_TO_DEG * (HALFPI + bearing_angle); while ( ordered_heading < 0.0f ) ordered_heading += 360.0f; while ( ordered_heading >= 360.0f ) ordered_heading -= 360.0f; pfSetVec3 ( hpr_result, ordered_heading, pitch_angle, 0.0f ); } -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Paul T. Barham Computer Specialist Computer Graphics Research + + + + Naval Postgraduate School barham@cs.nps.navy.mil + + Computer Science Department, Code CS Spanagel Hall Room 311A + + Monterey, Calfornia 93943 (408)656-2253 (2814 fax)+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From guest Wed May 11 14:00:23 1994 Date: Wed, 11 May 94 13:59:12 PDT From: stiles@aic.lockheed.com (Randy Stiles) Message-Id: <9405112059.AA21106@aic.lockheed.com> To: jan@archimedes.chinalake.navy.mil Cc: info-performer@sgi.sgi.com In-Reply-To: Jan A. Barglowski's message of Wed, 11 May 1994 12:36:22 -0700 <199405111936.MAA26697@archimedes.chinalake.navy.mil> Subject: Tracking camera... Date: Wed, 11 May 1994 12:36:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Forgive me if this is really basic, but I want to implement a "tracking" camera. That is, a camera which always looks at a particular model. This model will be driven by data, so its position cannot be known before hand. The way I've been going about it is: take the position of the model and subtract the position of the camera. This gives a vector from the camera to the model. The problem now is getting this vector into a hpr form so that I can use the pfChanView function to set the viewing direction. Am I going about this wrong? I've looked in the myriad of Performer function calls to see if there is a conversion from vector to hpr, but can't find any. Is there a "Performer way" that does all this automatically? Performer has a routine pfMakeRotOntoMat which will give you a viewing matrix (or coords if you use pfGetOrthoMatCoord) that will rotate from one vector to another. The starting vector should be 0.0,1.0.0.0, and the end vector should be the world coordinate xyz minus the current viewpoint xyz, giving you a vector that points at the desired object. Of course to get world coordinates, for target object, you have make sure all the transformation matrices that are parents in the tree have been evaluated (multiplied) against the objects DCS matrix. You can premultiply this stuff yourself in your own code using performer utilities. Obviously performer evaluates these matrices to get world coordinates in order to render stuff, but I haven't come across the hook to get that info (maybe more enlighted performer hackers can tell me where it is... I hate re-evaluating something I know is already out there, evaluated). There may be a more direct way to do this point at stuff, but I have tried it and it works reliably. We routinely do this in our perfomer applications. There is an infinite number of roll angles possible, so you may wish to ignore the roll and keep old roll values. -Randy # Randy Stiles (stiles@aic.lockheed.com) # Office: 415.354.5256, Fax: 415.354.5235 # Lockheed R&DD, Orgn 9620 Bldg 254F # 3251 Hanover St., Palo Alto, CA 94304-1191 From guest Wed May 11 14:12:58 1994 Date: Wed, 11 May 94 23:12:44 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405112112.AA08036@ligsg8.epfl.ch> To: info-performer@sgi.sgi.com Subject: blended LODs Reply-To: matomira@epfl.ch Hello, What's the secret to get blended LODs working? It's not a problem of attribute setup, but rather of multisampling, I think. I've called multisample(TRUE) and mssize(4/8,24/32,0/1/4) and gconfig on an RE onyx but it doesn't work. Either the LODs just 'jump', or there's no transition at all, or (latest news) the LODs 'jump' being translucid all the time (no blending). getgconfig after gconfig tells me there's 0 sample buffers. According to the lod example, it seems I am not forgetting anything. Thanks in advance P.S.: I am running 1.2, of course. Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Wed May 11 14:39:11 1994 From: "Sharon Fischler" Message-Id: <9405111438.ZM4370@rose.asd.sgi.com> Date: Wed, 11 May 1994 14:38:52 -0700 In-Reply-To: watsen@netcom.com (Kent Watsen) "Accumulation Buffer" (May 11, 12:24pm) References: <199405111924.MAA16419@netcom.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: watsen@netcom.com (Kent Watsen), info-performer@sgi.sgi.com (performer) Subject: Re: Accumulation Buffer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 +>---- On May 11, 12:24pm, Kent Watsen wrote: > Subject: Accumulation Buffer -> ->Hi, I have an Onyx RE2 and Performer 1.2. I have ->spent a week going through the GL advance GL ->manuals trying to get the accumulation buffer to ->work with performer in real-time. -> ->My best guess is to initialize the ACBUF after ->calling pfConfig() with the following commands: -> -> acsize(16); -> gconfig(); -> acbuf(AC_CLEAR, 0.0); -> ->I then establish a swap function callback with the ->following command after initializing my pipe with ->pfPipeSwapFunc (pipe, swapfunc). -> ->Swapfunc() is call once per frame just after the ->scene has been rendered into the backbuffer. The ->swapfunc() makes the appropriate ACBUF calls and ->the calls swapbuffers() as follows: -> -> void swapfunc (pfPipe *pipe) -> { -> // MOTION BLUR -> acbuf(AC_MULT, 0.5); -> acbuf(AC_ACCUMULATE, 1.0); -> acbuf(AC_RETURN, 1.0); -> -> swapbuffers(); -> } -> ->I acheive the desired effect but my frame rate drops ->to less the one frame every five seconds! I have done ->some experimentation and have determined that the ->larger my viewport the slower the ACBUF takes. -> ->The standard GL motion blur demos show much greater ->frame rates being achieved...but how? The fundamental ->difference in the codes is that I'm using Performer ->to do my rendering into the backbuffer rather then GL. ->It looks like all of the processing is being done in ->software, even though I am making the acbuf() calls. -> ->Does anybody have a clue as to what I'm doing wrong. ->Also, is the accumulation buffer a peice of hardware ->sitting in the RE2 pipeline or is it just another ->abstraction of the 40MB video memory included. Framebuffer words (pixel depth) are allocated amoung the color buffers, zbuffer, overlay planes, accumulation buffer, multisample buffer, etc. If you do not have enough pixel depth to support your current requests, you will drop into software accumulation buffering, which might be happening here. getgdesc(GD_BITS_ACBUF_HW) tells you how many bits per component are supported in hardware, which should be 16. You do want to use exactly that number in acsize(). You might try reducing your required pixel depth: don't allocate stereo buffers, use RGBsize(8), zbsize(24). FYI: /usr/gfx/gfxinfo will tell you your current pixel depth (which can be increased by using a smaller resolution screen area via setmon()). Pixel depth is small=16 16-bit words, Med=32 words, and Larg=64 words. srf. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Thu May 12 12:17:07 1994 Date: Thu, 12 May 94 21:16:39 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405121916.AA10001@ligsg8.epfl.ch> To: info-performer@sgi.sgi.com Subject: pfLoadTexture gets null texture Reply-To: matomira@epfl.ch Hi, My sim started giving warnings about pfLoadTexture getting null textures. I have checked and the files are found by performer and they are readable and OK. I saw on the console warnings about no more virtual swap. Could this be the reason? Last time I run the program there were no swap warnings, but I still haven't rebooted the machine. Also, is there a way of cleaning the swap area state without rebooting, like when you run out of semaphores (I have a little program to do just that). I tried swap -d to remove the extra swap device (as root), but it tells me there's to little free pages (swap -l shows that physical pages are all free). Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Thu May 12 11:46:52 1994 From: "Salvador Blasco" Message-Id: <9405121233.ZM1982@arrakis.mexico.sgi.com> Date: Thu, 12 May 1994 12:33:52 -0700 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Please unsubscribe me. Thank you -- Salvador Blasco Silicon Graphics, Inc. (525)662-0322 Voice Mail: 5-9471 Email: salvador@sgi.com "If there's nothing wrong with me, there must be something wrong with the universe!" - Dr.Beverly Crusher, Star Trek:TNG From guest Thu May 12 13:07:04 1994 Date: Thu, 12 May 94 22:06:47 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405122006.AA10235@ligsg8.epfl.ch> To: info-performer@sgi.sgi.com Subject: Photoshop -> RGBA? Reply-To: matomira@epfl.ch Hello, I have a 4-component (8bits per component) image in Photoshop. I need to save this into any appropriate format supported and convert this into an SGI RGBA file. Is there any freely available tool that will do this right? And in what format should I save in Photoshop? Thanks in advance Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Thu May 12 13:42:50 1994 From: marrou@vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9405122042.AA07956@crusader.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com, matomira@epfl.ch Subject: Re: Photoshop -> RGBA? > Is there any freely available tool that will do this right? > And in what format should I save in Photoshop? The programs fromtiff and fromtarga will work fine to convert from AT&T Targa (Vista) images or TIFF images, both of which I think Photoshop can output. These programs should be in /usr/sbin, otherwise you can try ~4Dgifts/iristools/imgtools. If both of these options fail, you can fall back on netpbm, available from various ftp sites, and then try compiling the (humongous) thing. I recommend trying fromtarga, personally, because netpbm is a pain in the butt to compile on SGs, and fromtiff may or may not support compressed TIFF files (which I think it does, try the man pages). _______________________________________________________ IST __ E-mail: marrou@vsl.ist.ucf.edu Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Thu May 12 13:54:29 1994 Date: Thu, 12 May 94 22:54:20 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405122054.AA10323@ligsg8.epfl.ch> To: info-performer@sgi.sgi.com Subject: Re: Photoshop -> RGBA? Reply-To: matomira@epfl.ch >>> > Is there any freely available tool that will do this right? > And in what format should I save in Photoshop? The programs fromtiff and fromtarga will work fine to convert from AT&T Targa (Vista) images or TIFF images, both of which I think Photoshop can output. >>> Hm. I tried today saving to Targs and using fromtarga, but the billboards do not get alpha-modulated at all. I know this can work, because if I set PFTE_COMP_IA_GETS_RG in the texture environment, the trees look nice. Also, we tried generating the mask with TDI Explore (reform -4) and then translating via tdisgi but this does not work, either. Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Thu May 12 14:06:24 1994 Date: Thu, 12 May 94 17:06:09 EDT From: flip@cgrg.ohio-state.edu (Flip Phillips) Message-Id: <9405122106.AA26967@sap.cgrg.ohio-state.edu> To: matomira@epfl.ch Cc: info-performer@sgi.sgi.com In-Reply-To: <9405122006.AA10235@ligsg8.epfl.ch> (matomira@lig.di.epfl.ch) Subject: Re: Photoshop -> RGBA? there is in fact an SGI format exporter/importer module for photoshop. if you cannot locate it directly I may be able to binhex and send it to you directly. -- flip From guest Fri May 13 15:58:12 1994 Date: Fri, 13 May 94 15:57:15 -0700 From: sbrown@nestor.ucsd.edu Message-Id: <9405132257.AA03024@nestor> To: info-performer@sgi.sgi.com I am curious if anyone has experience in working with Logitech's 3-D Mouse and 3D HeadTracker in Performer Applications, including how they compare with Polhemous and Ascencion devices. I am primarily interested in the Logitech devices out of price considerations, but I have yet to determine if they actually work well enough to track movement through a 6'x6'x6' space. Any information is appreciated. Sheldon Brown Visual Arts University of California at San Diego sgbrown@ucsd.edu From guest Mon May 16 14:20:45 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405162120.AA02974@tubes.asd.sgi.com> Subject: Re: Colour alteration with cloned nodes To: guest (Alon Rosenfeld 18 Hatzedef street Jaffa) Date: Mon, 16 May 94 14:20:04 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9405100916.AA01984@rea1.bvr.co.il>; from "Alon Rosenfeld 18 Hatzedef street Jaffa" at May 10, 94 9:16 am X-Mailer: ELM [version 2.3 PL8] > > > Hi All, > > My application involves a two pass rendered scene. The first pass the application > draws the scene as it is (i.e. as it was modeled in MultiGen with textures, rgb colours > for each vertex, etc.). In the second pass I would like to draw the scene with a single > texture (using texgen) and a single colour. To draw the scene twice I have cloned the > database. Enforcing the database to use a single texture is easy, using the an override > command as shown bellow: > > pfApplyTEnv(env); > pfApplyTex(missjan); > pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_ON); > > /* draw the scene */ > > pfOverride(PFSTATE_ENTEXTURE | PFSTATE_TEXTURE, PF_OFF); > > However can I do the same for the colour? It would be nice if I could call > say "pfApplyColor()" and then use pfOverride() to lock the colour in the GeoSets. > > Meanwhile I am loading the database twice. On the second loaded db I run a pre-process > traversal which alters the existing colours in the GeoSets to the desired uniform colour. > You are doing the right thing for the texture but there is no analogy for overriding color. However, if your database is lit, you can override a material of the color you want. You'll have to disable color mode on the material: pfMtlColorMode(mtl, PFMTL_BOTH, PFMTL_CMODE_COLOR) so subsequent colors are ignored. If your database is not lit, then you'll have to modify the above technique somewhat. From guest Mon May 16 14:33:41 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405162132.AA02997@tubes.asd.sgi.com> Subject: Re: blended LODs To: guest (Fernando D. Mato Mira) Date: Mon, 16 May 94 14:32:51 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9405112112.AA08036@ligsg8.epfl.ch>; from "Fernando D. Mato Mira" at May 11, 94 11:12 pm X-Mailer: ELM [version 2.3 PL8] > > > Hello, > > What's the secret to get blended LODs working? It's not a problem > of attribute setup, but rather of multisampling, I think. I've called > multisample(TRUE) and mssize(4/8,24/32,0/1/4) and gconfig on an > RE onyx but it doesn't work. Either the LODs just 'jump', or there's > no transition at all, or (latest news) the LODs 'jump' being translucid > all the time (no blending). getgconfig after gconfig tells me there's > 0 sample buffers. If getgconfig(GC_MS_SAMPLES) returns 0 then you are not getting multisampling and will not get fade lod. To get multisampling for a fullscreen VOF you need at least 2RM's. If you have but 1 then you need to run a smaller VOF. From guest Tue May 17 07:42:49 1994 From: "Stephen Joyce {75069}" Message-Id: <9405171442.AA21424@swlrgk> To: info-performer@sgi.sgi.com I'm trying to rebuild the perfly example source code using a pre-release of Performer 1.2 (We have not received the official 1.2 release yet). I'm getting an unresolved link error with pfuCalcNodeBBox being unresolved. Is there any way to get around this? Thanks, Steve Joyce Exact error - --------------------------------------------------------------------------------------------------------------------------------------------------- {122} make making OPT version of perfly cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../cmdline.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../../common/generic.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../../common/env.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../gui.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../keybd.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../perfly.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -c ../../common/main.c uopt: Warning: u-code 3.15 instead of 3.17 cc -xansi -D__STDC__ -I.. -I../../common -I/usr/src/Performer/include -I/usr/include/Performer -O -o perfly.OPT cmdline.o generic.o env.o gui.o keybd.o perfly.o main.o /usr/src/Performer/lib/libpfsgi.a /usr/src/Performer/lib/libpfdwb.a /usr/src/Performer/lib/libpfflt.a /usr/src/Performer/lib/libpfutil.a /usr/lib/libpf.a /usr/lib/libpr.a -lmpc -limage -lfm -lgl -lX11 /usr/lib/libm.a -lfpe -lC ld: Unresolved: pfuCalcNodeBBox *** Error code 1 (bu21) make: fatal error. *** Error code 1 (bu21) make: fatal error. -------------------------------------------------------------------------------------------------------------------------------------------------- From guest Tue May 17 08:37:55 1994 Message-Id: <9405171537.AA20240@surreal.asd.sgi.com> To: "Stephen Joyce {75069}" Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Tue, 17 May 94 10:42:20 EDT." <9405171442.AA21424@swlrgk> Date: Tue, 17 May 94 08:37:46 -0700 From: Jim Helman > I'm getting an unresolved link error with pfuCalcNodeBBox being > unresolved. Is there any way to get around this? It sounds like the perfly sample code which you are using is older than the Performer release you are linking it with. Just change pfuNodeCalcBBox() to pfuTravCalcBBox() in your source code. For naming consistency with the other utility traveral routines, i.e. pfuTravPrintNodes(), pfuTravGLProf(), pfuTravCountDB(), pfuTravCountNumVerts(), etc., pfuCalcNodeBBox() was renamed pfuTravCalcBBox() for the released version of 1.2's libpfutil. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed May 18 11:34:08 1994 Date: Wed, 18 May 1994 11:02:48 -0700 (PDT) From: "Michael D. Good" Sender: "Michael D. Good" Reply-To: "Michael D. Good" Subject: DXF reader and VR sensor tools for Performer To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII In response to Scott's question, we have developed a more advanced DXF loader for Performer which we use in our virtual reality consulting. We have used it to perform flythroughs of architectural data coming from the ARRIS CAD system. It is not yet available as a separate product, but that could change if there is sufficient interest. We have also developed a C++ class library for VR devices that is now in beta test. Currently it supports 10 devices, including sensors from Ascension, Polhemus, Logitech, Spaceball, and Origin, plus gloves from VPL and Virtex. All are handled in a device- independent way, including conversion of data into Performer's coordinate system, via the base sensor class. Filtering operations such as origin offsets, tolerance levels, and scaling are also included. Device-dependent features can be accessed via the derived class for each supported device. We found this library made it easy to add VR device control to Performer code. We are looking for additional beta customers to help ensure that this device software is usable with a variety of Performer applications. Versions are available for both IRIX 4.0.5 and 5.2, running with SGI C++ 3.0. If you are interested, please contact me via e-mail. Thanks, Michael Good Xtensory Inc mdgood@netcom.com From guest Wed May 18 12:34:36 1994 Date: Wed, 18 May 94 21:34:20 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405181934.AA21065@ligsg8.epfl.ch> To: iris-performer@sgi.sgi.com Subject: spline MAGFILTER Reply-To: matomira@epfl.ch Hello, Does anybody know the control points for a nice spline for a magnification filter? Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Wed May 18 18:17:58 1994 Message-Id: <9405190118.AA29116@mak.com> To: info-performer@sgi.sgi.com Subject: pfClone Date: Wed, 18 May 94 21:18:42 -0400 From: Len Granowetter After pfCloning a node, is there any good way of finding the node within the cloned graph that corresponds to a particular node in the original graph? (For instance a DCS that controls the articulation of a piece of a vehicle model.) Thanks, -Len Granowetter MaK Technologies From guest Thu May 19 15:26:24 1994 Date: Thu, 19 May 94 19:19:59+080 From: fair@iss.nus.sg (Kim Michael Fairchild) Message-Id: <9405191119.AA02400@bochap> To: info-performer@sgi.sgi.com Subject: Problem with scaling with Intersections Content-Length: 1416 Hello, I have found that reported intersections don't seem to pay any attention to scale. For instance if I load the "canyon.flt" file and run a version of the following code, segset.segs[0].length = 1000.0f; pfSetVec3(segset.segs[0].dir, 0.0f, 0.0f, -1.0f); segset.isectMask = intersectionMask; pfSetVec3(segset.segs[0].pos, vector[0], vector[1], vector[2]); isect = pfSegsIsectNode(ViewState->scene, &segset, hits); I get a depth of about 300 meters when looking over the canyon. But when I scale "canyon.flt" (e.g. by .1), I still get 300 meters for the depth of the canyon. It is of course possible that I could save the scale factor and multiple it by what ever I get from pfSegsIsectNode to get the correct value but this seems quite clumsy. Since I could have multiple scale factors, I would then have to traverse up the parent hierarchy looking for DCS or SCS type objects and if finding them collect a cumulative multiplication to get the scale. Alternative, I could of pre-collected the scale factors and bind it to the top-level group but this still doesn't seem very elegant. So, am I doing something wrong? In our applications, we typically will scale something by 1000 or by .001 (since we have to convert stuff from all sorts of formats). The default xformer collision detection gets confused as well (although works reasonably well for smaller scaling factors). thanks, Kim. From guest Thu May 19 15:26:18 1994 From: barham@gnarly.cs.nps.navy.mil (paul barham) Message-Id: <9405191441.AA12404@gnarly.cs.nps.navy.mil> Subject: Re: pfClone To: lengrano@mak.mak.com (Len Granowetter) Date: Thu, 19 May 1994 07:41:14 -0700 (PDT) Cc: info-performer@sgi.sgi.com In-Reply-To: <9405190118.AA29116@mak.com> from "Len Granowetter" at May 18, 94 09:18:42 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1374 > > > After pfCloning a node, is there any good way of finding the node > within the cloned graph that corresponds to a particular node in the > original graph? (For instance a DCS that controls the articulation of > a piece of a vehicle model.) > > Thanks, > -Len Granowetter > MaK Technologies > > What version of Performer are you using? I found that in v1.0 and v1.1 that the pfFindNode does not work so I wrote my own. Basically, I had pointers to the DCSs in the original. After I cloned, I backward traversed (pfGetParent) the original scene graph until I reached the top level node that was cloned (storing the path on a stack as I went up). I then traversed downward using the names of the node stored on the stack one level at a time. If there is an easier way, I would like to know about it. Hopefully, pfFindNode works in 1.2. -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Paul T. Barham Computer Specialist Computer Graphics Research + + + + Naval Postgraduate School barham@cs.nps.navy.mil + + Computer Science Department, Code CS Spanagel Hall Room 311A + + Monterey, Calfornia 93943 (408)656-2253 (2814 fax)+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From guest Thu May 19 15:26:10 1994 Message-Id: <9405191546.AA29685@mak.com> To: info-performer@sgi.sgi.com Subject: Re: pfClone In-Reply-To: Your message of "Thu, 19 May 94 07:41:14 PDT." <9405191441.AA12404@gnarly.cs.nps.navy.mil> Date: Thu, 19 May 94 11:46:50 -0400 From: Len Granowetter >What version of Performer are you using? I found that in v1.0 and v1.1 >that the pfFindNode does not work so I wrote my own. Basically, I had >pointers to the DCSs in the original. After I cloned, I backward >traversed (pfGetParent) the original scene graph until I reached the top level >node that was cloned (storing the path on a stack as I went up). I then >traversed downward using the names of the node stored on the stack one >level at a time. > >If there is an easier way, I would like to know about it. > >Hopefully, pfFindNode works in 1.2. I am using Performer1.2, but pFind would not really help in this case, since the nodeName of the desired node in the cloned graph would be the same as the nodeName of the desired node in the original graph. pfFind returns NULL when the name is ambiguous (more than one node with the desired name). Unfortunately, 1) there is no capability for passing a callback function to pfClone and 2) pfFind does not have the capability for passing it a root node indicating where to start the search. If there were, I could just run pfFind on the desired name, passing in the root of the cloned subgraph as the starting node. Anyway, either writing a function that implements my #2 above, or one that does what you suggest seem like the best ways to do this. I had been thinking along those lines as well but I thought I'd ask if I was overlooking an easier solution first. Thanks, -Len Granowetter From guest Thu May 19 16:25:34 1994 Date: Thu, 19 May 94 16:26:53 -0700 From: shung@ernie.arc.nasa.gov (Felix Shung) Message-Id: <9405192326.AA06474@ernie.arc.nasa.gov> To: info-performer@sgi.sgi.com Status: OR I am trying to set up a single pipe, 3 channel simulation which is based on Performer 1.2. The viewing frustrums are created by the off_axis projection command "pfMakePerspFrust", since the pilot's head movement eventually will have influence on the eyepoint.(A device "Polhemus" will provide the information about locations and orientations of the head) Nevertheless, I am having problem that the scene shown in side window is partially overlapped with the center window even though the offset rotation angle is exactly what it should be.( defined in pfChanViewOffsets) I rewrite the code with "pfChanFov" and kept every thing else the same, the scenes of 3 windows matched perfectly this time. I check the FOV created by "pfMakePerspFrust" and it is the same as what I used in "pfChanFOV". The eye location, the content of the scene shown in the center window, and the offset angle are the same in both cases. What can go wrong? Do I have to treat the "pfMakePerspFrust" differently than "pfChanFOV" even, at this moment, no off-axis projection is really happening? Felix The following is the part of my code: /* initialization */ /* allocate space for the 3 viewing frustrum of the 3 channels */ Shared->fr_chan1 = pfNewFrust(NULL); Shared->fr_chan2 = pfNewFrust(NULL); Shared->fr_chan3 = pfNewFrust(NULL); /* center window */ Center = pfNewChan(Pipe); pfAllocChanData(Center, sizeof(PassData)); pfChanCullFunc(Center, CullFunc); pfChanDrawFunc(Center, DrawFunc); pfChanViewport(Center, 0.f, 1.f, 0.66406250f, 0.99609375f); pfChanScene(Center, scene); pfChanESky(Center, eSky); pfChanNearFar(Center, Output->near, Output->far); pfMakePerspFrust(Shared->fr_chan1, Shared->off_proj.original_win.l, Shared->off_proj.original_win.r, Shared->off_proj.original_win.b, Shared->off_proj.original_win.t); pfFrustNearFar (Shared->fr_chan1, Shared->off_proj.original_win.near, Shared->off_proj.original_win.far); /* left window */ Left = pfNewChan(Pipe); pfAllocChanData(Left, sizeof(PassData)); pfChanCullFunc(Left, CullFunc); pfChanDrawFunc(Left, DrawFunc2); pfChanViewport(Left, .0f, 1.f, 0.0f, 0.33203125f); pfChanScene(Left, scene); pfChanESky(Left, eSky); pfChanNearFar(Left, Output->near, Output->far); pfMakePerspFrust(fr_chan1, l,r, b, t); pfFrustNearFar ( near, far); /* right window */ Right = pfNewChan(Pipe); pfAllocChanData(Right, sizeof(PassData)); pfChanCullFunc(Right, CullFunc); pfChanDrawFunc(Right, DrawFunc2); pfChanViewport(Right, 0.0f, 1.f, 0.33203125f, 0.66406250f); pfChanESky(Right, eSky); pfMakePerspFrust(fr_chan3, l, r, b, t); pfFrustNearFar (fr_chan3, near, far); pfAttachChan(Center, Left); pfAttachChan(Center, Right); /* Not sharing FOV and not sharing Near & Far clipping */ share = pfGetChanShare(Center); pfChanShare(Center, (share & ~PFCHAN_FOV) & ~PFCHAN_NEARFAR); /* real time loop */ while(!terminate){ /* include the head movement */ offaxis_realtime(pol_x, pol_y, pol_z, pol_azi, pol_ele, pol_rol); /* redefine the l,r, b, t, near, far for 3 windows based on new */ /* head movement */ creating structure updated_win information...... /* CENTER window, center */ pfFrustNearFar (fr_chan1, new_near_center, new_far_center); pfMakePerspFrust(fr_chan1, Shared->off_proj.updated_win[1].l, Shared->off_proj.updated_win[1].r, Shared->off_proj.updated_win[1].b, Shared->off_proj.updated_win[1].t); /* include the head movement for the new eye point*/ actual_viewpoint.xyz[0] =old_viewpoint.xyz[0] + Shared->head_trans_in_meter[0]; actual_viewpoint.xyz[1] =old_viewpoint.xyz[1] + Shared->head_trans_in_meter[1]; actual_viewpoint.xyz[2] =old_viewpoint.xyz[2] + Shared->head_trans_in_meter[2]; pfChanView(Center, actual_viewpoint.xyz, Output->viewpoint.hpr); pfGetFrustFOV(fr_chan1, &hfov, &vfov); pfGetFrustEye(fr_chan1, eye); /* LEFT window */ pfFrustNearFar (fr_chan2, Shared->off_proj.updated_win[0].near, Shared->off_proj.updated_win[0].far); pfMakePerspFrust(fr_chan2, Shared->off_proj.updated_win[0].l, Shared->off_proj.updated_win[0].r, Shared->off_proj.updated_win[0].b, Shared->off_proj.updated_win[0].t); pfApplyFrust(fr_chan2); pfChanView(Left, actual_viewpoint.xyz, Output->viewpoint.hpr); pfChanViewOffsets(Left, chan2_xyz, chan2_hpr); /* RIGHT window */ pfFrustNearFar (fr_chan3, Shared->off_proj.updated_win[2].near, Shared->off_proj.updated_win[2].far); pfMakePerspFrust(fr_chan3, Shared->off_proj.updated_win[2].l, Shared->off_proj.updated_win[2].r, Shared->off_proj.updated_win[2].b, Shared->off_proj.updated_win[2].t); pfApplyFrust(fr_chan3); pfChanView(Right, actual_viewpoint.xyz, Output->viewpoint.hpr); pfChanViewOffsets(Right, chan3_xyz, chan3_hpr); /* start frame processing */ pfFrame(); } From guest Fri May 20 09:51:46 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405201525.AA01159@tubes.asd.sgi.com> Subject: Re: your mail To: guest (Felix Shung) Date: Fri, 20 May 94 8:25:57 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9405192326.AA06474@ernie.arc.nasa.gov>; from "Felix Shung" at May 19, 94 4:26 pm X-Mailer: ELM [version 2.3 PL8] > > I am trying to set up a single pipe, 3 channel simulation which is > based on Performer 1.2. The viewing frustrums are created by the off_axis > projection command "pfMakePerspFrust", since the pilot's head movement > eventually will have influence on the eyepoint.(A device "Polhemus" will > provide the information about locations and orientations of the head) > > Nevertheless, I am having problem that the scene shown in side window is > partially overlapped with the center window even though the offset rotation > angle is exactly what it should be.( defined in pfChanViewOffsets) > I rewrite the code with "pfChanFov" and kept every thing else the same, > the scenes of 3 windows matched perfectly this time. I check the > FOV created by "pfMakePerspFrust" and it is the same as what I used > in "pfChanFOV". The eye location, the content of the scene shown in the > center window, and the offset angle are the same in both cases. > What can go wrong? Do I have to treat the "pfMakePerspFrust" differently > than "pfChanFOV" even, at this moment, no off-axis projection is really > happening? This is probably an artifact of automatic aspect ratio matching of the view frustum to the viewport. If you specify both fov's to pfChanFOV, then you disable this feature. Unfortunately, pfMakePerspFrust does not disable this feature so your frustum will be mangled. The solution is to disable aspect ratio matching by calling pfChanAutoAspect(chan, PFFRUST_CALC_NONE) before calling pfMakePerspFrust. Notes: 1. It is not necessary (or safe) to call pfApplyFrust. 2. When attaching channels in a group, the attachee inherits the values of the attacher so pfAttachChan(Center, Left) means that Left will grab the fov of Center. From guest Fri May 20 09:52:42 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9405201651.AA01311@tubes.asd.sgi.com> Subject: Re: Layered Intensity Alpha sky texture. To: guest (Vidar Storkersen) Date: Fri, 20 May 94 9:51:25 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9404201531.ZM11063@onyx.autosim.no>; from "Vidar Storkersen" at Apr 20, 94 3:31 pm X-Mailer: ELM [version 2.3 PL8] > > Hi, > > I'm running Performer1.2alpha99 on an Onyx RE^2 (running Irix > 5.2-ALPHA-1010931841). > > In Multigen our Intensity Alpha sky texture looks nice, but when we are > running our database in Performer the skies looks like they are layered. > It is the Alpha part of the texture which is layered. There are just a few > transparency levels. > > In Multigen I tried to change the Internal format, from the default format > to TX_IA8. Then I would still have a full speed texture, but with 256 levels > of Alpha. > > Again I tried to run our database in Performer. But still there where just a > few levels of transparency. > > At last I changed the internal format to TX_RGBA12 on the sky texture in > Multigen. Then I would have 4096 levels of Alpha. (The only difference was > that the Intenity part of the texture became blue in Multigen.) In Performer > the Intensity part became blue (as in Multigen), but there where still just > 16 transparency levels. > > The last test is an indication that this problem has no origin in LoadFlt, > since the Intensity part of the texture became blue in Performer. > > My question is: > Doesn't Performer allow you to have Intensity Alpha textures with more than > 16 transparency levels. > > If Performer allows more than 16 transparency levels: > What can I do to get skies with more than 16 transparency levels > TX_IA8 (256 transparency levels) will satisfy our needs for credible skyes. > The default Performer transparency mechanism uses multisampling (see msalpha) for best performance. However, this looks worse than the slower blendfunction type transparency. What you need to do is specify the higher quality transparency for your sky. Find the gstate in question and: pfGStateMode(gstate, PFSTATE_TRANSPARENCY, PFTR_HIGH_QUALITY); From guest Fri May 20 13:21:25 1994 Date: Fri, 20 May 94 22:21:20 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9405202021.AA27929@ligsg8.epfl.ch> To: info-performer@sgi.sgi.com Subject: PF_BLEND textures Reply-To: matomira@epfl.ch I am mapping a texture on a terrain taken from an .iv file (no vertex colors, just material), and PF_BLEND works OK except for the transparency. When I set the corresp geostate for transparent rendering, the thing just dissapears. Alpha in the geostate material is 1.0 and the alpha component of the texture is OK. Is this related to the multisampling problem (only 1 RM on RE - What's an RM?). I am going to try that fast transparency mode tomorrow. Otherwise, am I missing anything or what? Perf 1.2 IRIX 5.0.1 Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Fri May 20 15:23:17 1994 From: hunt@gts.elan.af.mil (Tracy Hunt) Message-Id: <9405201510.ZM7743@gts.elan.af.mil> Date: Fri, 20 May 1994 15:10:32 -0700 X-Mailer: Z-Mail (2.1.5 20sep93) To: info-performer@sgi.sgi.com Subject: File size????? I am having a problem loading files into Performer using Loadflt. I am loading a database in which most of the files are ~ 30K. The file containing the area of interest is 500k. Performer loads the other file correctly up to the larger file, then core dumps. Is there a file size limit for Loadflt or am I in the dark? Tracy Hunt hunt@gts.elan.af.mil From guest Sat May 21 12:26:41 1994 Message-Id: <199405211927.OAA14161@bert.eecs.uic.edu> To: info-performer@sgi.sgi.com Subject: Panel bg color changeable??? Loving performer, but really wanting to change, disable, and or make transparent the background panel in the pfuPanel stuff. I have looked briefly for any obvious ways to do this, but no luck yet. Anybody done this yet? ceder@eecs.uic.edu From guest Sat May 21 14:52:02 1994 From: "Michael Jones" Message-Id: <9405211451.ZM1068@babar.asd.sgi.com> Date: Sat, 21 May 1994 14:51:40 -0700 In-Reply-To: Christopher Cederwall "Panel bg color changeable???" (May 21, 2:27pm) References: <199405211927.OAA14161@bert.eecs.uic.edu> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Christopher Cederwall , info-performer@sgi.sgi.com Subject: Re: Panel bg color changeable??? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On May 21, 2:27pm, Christopher Cederwall wrote: > Subject: Panel bg color changeable??? : :Loving performer... That's the spirit! ;-) :...but really wanting to change, disable, and :or make transparent the background panel in the pfuPanel stuff. Take a look at line 1091 in gui.c which is in the libpfutil source directory. You'll see this source line: static pfVec3 clr ={.05,.3,.3}; Change it to the color of your dreams, and you'll be in good shape. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon May 23 12:14:38 1994 From: marrou@vsl.ist.ucf.edu (Lance Marrou) Message-Id: <9405231758.AA22487@crusader.vsl.ist.ucf.edu> To: Len Granowetter , info-performer@sgi.sgi.com Subject: Re: pfClone >Unfortunately, 1) there is no capability for passing a callback >function to pfClone and 2) pfFind does not have the capability for >passing it a root node indicating where to start the search. If there >were, I could just run pfFind on the desired name, passing in the root >of the cloned subgraph as the starting node. I am not sure if someone as already responded to this, but here is my solution for this problem. As a new object is cloned, the top-level DCS (or whatever the top-level node is) is named specifically. That is, the "clone" is attached to a specific name which is then thrown on the scene graph. You can then use pfGetNodeName for the current clone name and attach the names of the DCSes to this top-level. pfFindDCS does take an argument, which is the path of the DCS. I hope this makes sense, if not let me know. The following is an example (part of my code) which finds the fulcrum DCS of an articulated AVLB using the top-level DCS entity_dcs: // note that overhead and entity_dcs are class variables of type pfDCS char path[100]; char name[100]; strcpy(path, "/"); if (pfGetNodeName(entity_dcs)) { strcat(path, pfGetNodeName(entity_dcs)); strcat(path, "/"); } strcpy(name,path); overhead = pfFindDCS(strcat(name, "Fulcrum")); if (overhead == NULL) { fprintf(stdout,"Could not find overhead (Fulcrum) DCS.\n"); fprintf(stdout,"\tlooking for: %s\n",name); fflush(stdout); } _______________________________________________________ IST __ E-mail: marrou@vsl.ist.ucf.edu Visual / / ______ /\____ ______ ______ Systems / / / _ / / __ // ____// ____/ Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou ________/____//____/\\/_/ /_//_____//_____/____________ From guest Tue May 24 00:45:14 1994 From: hirota@trl.ibm.co.jp Message-Id: <9405240744.AA69219@ns.trl.ibm.com> To: info-performer@sgi.sgi.com Subject: .poly format Date: Tue, 24 May 1994 16:44:56 +0900 Status: OR We are planning to use Prisms for modelling and Performer for visual simulation. I heard ver 1.2 has loader for .poly format. Is this polygon file format for Prisms? Can this loader read color, normal, texture coordinate as well as vertex coordinate if a .poly file has those optional info? Thanks, Gentaro From guest Tue May 24 02:24:27 1994 From: suter@esar9 (Martin Suter) Message-Id: <9405240925.AA09855@esar9> Subject: cout produces coredump To: info-performer@sgi.sgi.com Date: Tue, 24 May 1994 09:25:18 +0000 (MET) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 316 I'm writing an importer to be used by the IRIS Performer sample programs (e.g. perfly) and I'd like to use the C++ style I/O (cout, cin). So I've edited LoadFile() in libpfsgi/loadfile.c to call my import-function. As soon as I introduce any cout or cin statement in my importer a coredump is produced. Any hints? From guest Tue May 24 04:36:20 1994 Message-Id: <199405241135.EAA28482@sgi.sgi.com> From: Robert Rossow Subject: Prisms??? To: info-performer@sgi.sgi.com Date: Tue, 24 May 94 7:42:11 EDT Mailer: Elm [revision: 66.25] In regard to the Prisms/Performer loader question, does anyone know who I can contact regarding the Prisms modeler? A phone number or an e-mail address? Thanks in advance, Robert Rossow rossow@gsi.gsc.com From guest Tue May 24 05:45:53 1994 From: hirota@trl.ibm.co.jp Message-Id: <9405241245.AA66604@ns.trl.ibm.com> To: info-performer@sgi.sgi.com Subject: .poly and Prisms Date: Tue, 24 May 1994 21:45:33 +0900 Roughly speaking, Prisms is an animation package like SoftImage or Wavefront, and is developed by a Canadian company, Side Effects Software Inc. The software can save polygon data in an ascii file, whose format is called ".poly". I found in FAQ, that IRIS Performer 1.2 includes a file loader for .poly. Now, is this just coincidence? -Gentaro From guest Tue May 24 08:35:10 1994 id AA09535; Tue, 24 May 94 10:34:12 CDT Date: Tue, 24 May 94 10:34:12 CDT From: reedwhit@skips.dseg.ti.com (Reed Whittington) Message-Id: <9405241534.AA09535@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: Problem with pickfly on 2 Pipe System We have been working with the pickfly example code trying to develop a target tracker. pickfly works fine on our single pipe Onyx RE2 wo MCO, but has problems on both of our 2 pipe Onyx RE2s w MCO. To recreate problem on a 2 pipe system: pickfly somemodel.xxx # this has problems pickfly -c 1 somemodel.xxx # this works fine The symptom is this: pickfly lets you move and pick once and then no more mouse interaction is possible. Some information on our 2 Pipe Onyx RE2 w/ MCOs. hinv: 4 150 MHZ IP19 Processors CPU: MIPS R4400 Processor Chip Revision: 5.0 FPU: MIPS R4010 Floating Point Chip Revision: 0.0 Data cache size: 16 Kbytes Instruction cache size: 16 Kbytes Secondary unified instruction/data cache size: 1 Mbyte Main memory size: 128 Mbytes, 2-way interleaved I/O board, Ebus slot 9: IO4 revision 1 I/O board, Ebus slot 11: IO4 revision 1 Integral EPC serial ports: 4 RealityEngineII Graphics Pipe 1 at IO Slot 9 Physical Adapter 6 (Fchip rev 2) Multi-Channel Option board installed RealityEngineII Graphics Pipe 0 at IO Slot 11 Physical Adapter 2 (Fchip rev 2) Integral Ethernet controller: et0, Ebus slot 11 Integral SCSI controller 91: Version WD33C95A Integral SCSI controller 90: Version WD33C95A Integral SCSI controller 1: Version WD33C95A Disk drive: unit 1 on SCSI controller 1 Integral SCSI controller 0: Version WD33C95A Tape drive: unit 7 on SCSI controller 0: QIC 150 Tape drive: unit 6 on SCSI controller 0: DAT CDROM: unit 5 on SCSI controller 0 Integral EPC parallel port: Ebus slot 9 Integral EPC parallel port: Ebus slot 11 VME bus: adapter 0 mapped to adapter 45 VME bus: adapter 45 gfxinfo: Graphics board 0 is "REV" graphics. Managed (":0.0") 1280x1024 Display 1280x1024 @ 60Hz 12 GE (GE10 rev. 0x7) 4 RM4 boards Large pixel depth 10-bit RGBA pixels Not using Multi-Channel Option Graphics board 1 is "REV" graphics. Managed (":0.1") 1280x1024 Display 1280x1024 @ 60Hz 12 GE (GE10 rev. 0x7) 2 RM4 boards Medium pixel depth 10-bit RGBA pixels Not using Multi-Channel Option uname -a: IRIX snoopy 5.2 02282015 IP19 mips From guest Wed May 25 09:03:43 1994 From: "JAVIER CASTELLAR" Message-Id: <9405251525.ZM1709@aladdin.madrid.sgi.com> Date: Wed, 25 May 1994 15:25:28 +0000 X-Mailer: Z-Mail-SGI (3.0S.1016 16oct93 MediaMail) To: watsen@netcom.com, info-performer@sgi.sgi.com, srf@sgi.sgi.com Subject: Re: Accumulation buffer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi all, I have read your mails regarding the accumulation buffer worng function. The reason IS: If you are working on a Reality Engine you should take care about TWO issues: 1st) Which RGBsize are you using ? By default Reality Engine works with 12bits per component (as in your case). The right sizes for the accumulation components will be 12 or 24 (NOT 8 or 16). Then in your case acsize(12) or acsize(24) is OK. 2nd) You can work with acsize(24) only if you have enought framebuffer free. If you are working with SMALL pixel depth (one case is 1280x1024 vof with 1RM),depending on the use of other features (z buffer, stencil ...) you will be able to work with acsize(24). With SMALL pixel you can: with Zbuffer: ONLY with acsize(12); w/o Zbuffer: acsize(12) and zcsize(24); With MEDIUM and LARGE: No problem, no limitations. If you wish to work with acsize(24) and Zbuffer in an 1RM Reality Engine, the only way is to use the 960x680 vof. Then you can obtain MEDIUM PIXEL. In general the acsize(12) is usable for most of the VisSim tricks that i know (static Backgrounds, panning, sprites ... etc). USE acsize(12) !!!! If you try to use acsize(16) with RGBsize at 12 bits per component, it will work IN CPU, IN SOFTWARE, (1/100 to 1/10000 of the speed). Then you should match the RGBsize or the acsize, but in your case acsize(12) will be enough in any case. Hope to help. Javier Castellar javier@madrid.sgi.com Silicon Graphics Spain From guest Fri Jun 3 07:59:31 1994 From: "Michael Jones" Message-Id: <9406030759.ZM29911@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 07:59:22 -0700 In-Reply-To: hirota@trl.ibm.co.jp ".poly and Prisms" (May 24, 9:45pm) References: <9405241245.AA66604@ns.trl.ibm.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: hirota@trl.ibm.co.jp, info-performer@sgi.sgi.com Subject: Re: .poly and Prisms Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR On May 24, 9:45pm, hirota@trl.ibm.co.jp wrote: > Subject: .poly and Prisms :Roughly speaking, Prisms is an animation package like SoftImage or :Wavefront, and is developed by a Canadian company, Side Effects :Software Inc. : :The software can save polygon data in an ascii file, whose format is :called ".poly". : :I found in FAQ, that IRIS Performer 1.2 includes a file loader for :.poly. : :Now, is this just coincidence? Sadly, it is just that. I would never have named my polyhedron file format ".poly" if I had realized that Prisims uses ".poly" and ".bpoly". I'll rename the "/usr/src/Performer/friends/models/poly" datasets to something else (".euclid" ?) for the next release of IRIS Performer. I later recieved information about Prisims and a working loader for Prisims files into IRIS Performer does now exist. We will be working with Side Effects to get this support released for those users who use their modeling tools. This will be important since Prisims provides such complete support for animated characters and that's a big topic now in the many companies where IRIS Performer is being used to build interactive entertainment applications. Let me know if you want to help test the Prisims loaders. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 08:20:31 1994 Return-Path: Message-Id: <9406031519.AA51924@ns.trl.ibm.com> To: info-performer@sgi.sgi.com Cc: ohbuchi@trl.ibm.co.jp, miyazawt@trl.ibm.co.jp, aono@trl.ibm.co.jp, ssuda@vnet.ibm.co.jp Subject: Re: .poly and Prisms In-Reply-To: "Michael Jones" Your message of "Fri, 03 Jun 1994 07:59:22 MST." <9406030759.ZM29911@babar.asd.sgi.com> Date: Sat, 04 Jun 1994 00:19:49 +0900 From: hirota@trl.ibm.co.jp > On May 24, 9:45pm, hirota@trl.ibm.co.jp wrote: > > Subject: .poly and Prisms > :Roughly speaking, Prisms is an animation package like SoftImage or > :Wavefront, and is developed by a Canadian company, Side Effects > :Software Inc. > : > :The software can save polygon data in an ascii file, whose format is > :called ".poly". > : > :I found in FAQ, that IRIS Performer 1.2 includes a file loader for > :.poly. > : > :Now, is this just coincidence? > > Sadly, it is just that. I would never have named my polyhedron > file format ".poly" if I had realized that Prisims uses ".poly" and > ".bpoly". I'll rename the "/usr/src/Performer/friends/models/poly" > datasets to something else (".euclid" ?) for the next release of > IRIS Performer. > > I later recieved information about Prisims and a working loader > for Prisims files into IRIS Performer does now exist. We will be > working with Side Effects to get this support released for those > users who use their modeling tools. > > This will be important since Prisims provides such complete > support for animated characters and that's a big topic now > in the many companies where IRIS Performer is being used to > build interactive entertainment applications. > > Let me know if you want to help test the Prisims loaders. > Of course I want. I have a data set from Veiwpoint in .poly format, so first of all, I'd like to try it. Prisms itself will be available for us soon, then more intensive tests will be possible. Thanks ---------------------------------- Gentaro Hirota IBM Japan, Ltd. e-mail : hirota@trl.ibm.co.jp telephone : +81-462-73-4926 facsimili : +81-462-73-7428 From guest Fri Jun 3 10:10:10 1994 Date: Fri, 3 Jun 94 18:59:42 +0200 From: fsanchez@viva.paris.sgi.com (FRANCOIS SANCHEZ) Message-Id: <9406031659.AA13532@viva.paris.sgi.com> To: info-performer@giraffe Subject: pfChanPick on secondary channel A developer writing a multichannel Performer application on RE (no MCO option - Irix 5.2 Performer 1.2), claims than pfChanPick only works on the main channel . Is there any restriction or is it a user error? I tried to reproduce that with pickfly -c but I'm not sure what I'm doing since it mentions MCO settings Thank you Francois Sanchez From guest Fri Jun 3 13:21:45 1994 From: "Bob Buckley" Message-Id: <9406031250.ZM21460@grimmy.mss.ctaeng.com> Date: Fri, 3 Jun 1994 12:50:48 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Spot lights/landing light lobes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 753 Status: OR What would be the proper technique to model landing light lobes or spot lights in Performer? With the assumption that these are accomplished by direct GL calls are there any plans to incorporate these capabilities into Performer functionality? Thanks. =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Fri Jun 3 19:07:47 1994 From: hildebra@vsl.ist.ucf.edu (Andrew Hildebrand ) Message-Id: <9406040206.AA07566@onyx.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: Performer 1.2 Bounding Spheres I have a question about the bounding spheres in Performer 1.2. I have been trying to do collision detection between 2 objects using pfSphereIsectSphere. The 2 objects are in Flight format and are set up as DCSs. I get the bounding sphere from the DCS and then check to see if the 2 objects are intersecting. I get different results than what appears to be happening. I get a result of maybe|true if the objects are nowhere near each other I printed out the scene and found that the DCS bounding sphere is moving with the object, but the Geode bounding sphere beneath the DCS is not moving, is this a BUG???? ALSO if anyone has sample code for collision detection between 2 objects that are DCSs, I would love to see it. THANKS ______________________________________________________________________________ Andrew Hildebrand The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) hildebra@vsl.ist.ucf.edu _______________________________________________________________________________ From guest Fri Jun 3 20:09:56 1994 Message-Id: <9406040309.AA15701@surreal.asd.sgi.com> To: hildebra@vsl.ist.ucf.edu (Andrew Hildebrand ) Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.2 Bounding Spheres In-Reply-To: Your message of "Fri, 03 Jun 94 22:06:54 EDT." <9406040206.AA07566@onyx.vsl.ist.ucf.edu> Date: Fri, 03 Jun 94 20:09:35 -0700 From: Jim Helman > I printed out the scene and found that the DCS bounding sphere > is moving with the object, but the Geode bounding sphere beneath > the DCS is not moving, is this a BUG???? Not a bug. When you get the bounding volume on a geode, the bounding volume contains the geometry beneath it without any regard to what lies above it in the scene graph. That's how hierarchical bounding volumes work. It's really the only way. Suppose the geode were instanced several times in the scene graph under different DCSes. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Jun 6 10:31:27 1994 Message-Id: <199406061731.MAA01666@jadoube> Subject: WIREFRAME toggling question To: info-performer@sgi.sgi.com Date: Mon, 6 Jun 1994 12:31:14 -0500 (CDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1219 Hello Fellow Performers: We are attempting to toggle wireframe in our GeoState model by setting pfGStateMode(gstates[i], PFSTATE_ENWIREFRAME, PF_ON); then, by pfApplyGState(gstate[i]) where `i` is the particular part of the model we are interested in toggling. However, instead of applying the wireframe mode locally to the particular part, the entire GeoSet (ie. gstates[0] .. gstates[n]) gets switched to wireframe. -- What gives? Interestingly enough, when we first define these geostates, we don't need to use "pfApplyGState" and we can have different parts with different "pfGStateModes". The difficulty seems to come in when we try to do toggling. Also, does anyone know of a performer site which houses all the traffic on this newsgroup, and/or bonus code samples, etc. ? Nihar Gokhale Graphics/Animation Group Mathematics and Computer Sciences Division Argonne National Laboratory Argonne, Illinois USA 60439 /\\ gokhale@mcs.anl.gov // \\ 708-252-2815 (voice) //_ o _\\ 708-252-5986 (FAX) \- --/ Mosaic: http://www.mcs.anl.gov/home/gokhale/gokhale.html The goal of Computer Science is to build something that will last at least until we've finished building it. From guest Mon Jun 6 11:05:19 1994 From: "Michael Jones" Message-Id: <9406061105.ZM4523@babar.asd.sgi.com> Date: Mon, 6 Jun 1994 11:05:01 -0700 In-Reply-To: Nihar Gokhale "WIREFRAME toggling question" (Jun 6, 12:31pm) References: <199406061731.MAA01666@jadoube> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Nihar Gokhale , info-performer@sgi.sgi.com Subject: Re: WIREFRAME toggling question Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jun 6, 12:31pm, Nihar Gokhale wrote: > Subject: WIREFRAME toggling question : :Hello Fellow Performers: : :We are attempting to toggle wireframe in our GeoState :model by setting : : pfGStateMode(gstates[i], PFSTATE_ENWIREFRAME, PF_ON); : :then, by : : pfApplyGState(gstate[i]) : :where `i` is the particular part of the model we :are interested in toggling. All you need is the first part of this, which specifies the wireframe mode for those geosets you care about. The apply() function is called for you during the traversal. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Jun 6 11:49:14 1994 Message-Id: <9406061848.AA07753@sgi.sgi.com> Date: 6 Jun 94 14:37:00 EST From: "Robert Reif" Subject: stereo version of libpfutil xwin.c ? To: "info-performer" Does anyone have a modified version of the libpfutil module xwin.c that supports stereo on an ONYX RE2? Thanks. Robert Reif reif@ntsc-rd.navy.mil From guest@holodeck.asd.sgi.com Wed Jun 8 18:48:50 1994 -0700 for /usr/lib/sendmail info-performer-dist id AA09742; Wed, 8 Jun 94 15:21:40 -0700 for info-performer@holodeck.asd.sgi.com id AA23364; Wed, 8 Jun 94 15:24:04 -0700 for info-performer@giraffe.asd.sgi.com id AA06527; Wed, 8 Jun 94 15:21:36 -0700 ; Wed, 8 Jun 1994 18:21:35 -0400 From: "Howard Abrams" Message-Id: <9406081821.ZM19322@tabor> Date: Wed, 8 Jun 1994 18:21:31 -0400 X-Face: "K/fJ/f?*WE_#;z\|CNp$+h^E2!&gQ81\C'^AU,bHw*Fnw7"kIpq-_CHK*U(9;@W(dH?6A-:K'G#O>"?FJN#x`G^|O[OoJ&\]90&gj,gCE}bd]s%(y9`rVDKoqA(7S$9neB8J7}h;G3P^'7Sz^`:h{[,x->n~e*#'D})GpI"f^l^eiTkXeg+p'J()_<3Rx))]QJ=*p&l8iS~1NjHB49cVV+W/E\9,*rg={To@d;uSmNJ|b<+DSKUSbtc1Z@&@TMM}7vtL{ud!ULX/vbz,^!0HFzcj?p71>9i>&[^ZK`nj~VtL X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.com Subject: FadeLOD & Lightpoints == BUG Cc: plevy@tabor.mitre.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Apparently Lightpoints don't fade with LOD's which isn't that bad execpt that during the fade transition of an lod, they disappear, causing a 'black out' until the next lod is compleatly faded in. Does anyone know of a work-around for this? PS. Is there anyone out there using libpfflt who has the need for directional lights as they appear in MultiGen? Or better yet, has anyone fixed LoadFLT to do directional lights correctly? -- Howard Abrams (abramsh@mitre.org) The MITRE Corporation Mail Stop W273 Interactive Simulation Technology The Mitre Corporation I-Lab Envisioning Group McLean, VA 22102 Phone (703) 883-7421 These are not Mitre's opinions.... Hell, they're not even mine! From guest Wed Jun 8 15:21:40 1994 Return-Path: abramsh@tabor.mitre.org id AA25051; Wed, 8 Jun 94 18:21:34 EDT From: "Howard Abrams" Message-Id: <9406081821.ZM19322@tabor> Date: Wed, 8 Jun 1994 18:21:31 -0400 X-Face: "K/fJ/f?*WE_#;z\|CNp$+h^E2!&gQ81\C'^AU,bHw*Fnw7"kIpq-_CHK*U(9;@W(dH?6A-:K'G#O>"?FJN#x`G^|O[OoJ&\]90&gj,gCE}bd]s%(y9`rVDKoqA(7S$9neB8J7}h;G3P^'7Sz^`:h{[,x->n~e*#'D})GpI"f^l^eiTkXeg+p'J()_<3Rx))]QJ=*p&l8iS~1NjHB49cVV+W/E\9,*rg={To@d;uSmNJ|b<+DSKUSbtc1Z@&@TMM}7vtL{ud!ULX/vbz,^!0HFzcj?p71>9i>&[^ZK`nj~VtL X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: FadeLOD & Lightpoints == BUG Cc: plevy@tabor.mitre.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Apparently Lightpoints don't fade with LOD's which isn't that bad execpt that during the fade transition of an lod, they disappear, causing a 'black out' until the next lod is compleatly faded in. Does anyone know of a work-around for this? PS. Is there anyone out there using libpfflt who has the need for directional lights as they appear in MultiGen? Or better yet, has anyone fixed LoadFLT to do directional lights correctly? -- Howard Abrams (abramsh@mitre.org) The MITRE Corporation Mail Stop W273 Interactive Simulation Technology The Mitre Corporation I-Lab Envisioning Group McLean, VA 22102 Phone (703) 883-7421 These are not Mitre's opinions.... Hell, they're not even mine! From guest Thu Jun 9 09:37:09 1994 Date: Thu, 9 Jun 1994 09:37:06 -0700 From: "Carlo L. Tiana" Message-Id: <199406091637.JAA28788@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: Movie generation/format conversion I hope this question is relevant enought for this list. I have a number of snapshots taken from renderings of a scene by Performer. THey are all .rgb files. I would like to compose a movie from them. THe number is high enough (150 frames) that using moviemaker to load each frame manually is a little painful. In addition, I am trying to use ImageVision Library to process the resulting movie, and IL does not seem to recognize the movie format moviemaker generates. What I am wondering is (in order of decreasing appeal!): - are there tools to take a number of .rgb files and create an IL movie (and if so are there tools that will do the reverse (take an IL movie and split it into a number of .rgb files) - are three tools that will take a number of .rgb files and create a 'moviemaker' format movie (whatever that is) (and the reverse would be nice too). Sorry if this is far off the mark for this list. Carlo Tiana NASA Ames Research Center From guest Thu Jun 9 10:01:30 1994 Date: Thu, 9 Jun 94 10:01:22 -0700 From: ib@ivan (Ivan Bach) Message-Id: <9406091701.AA10839@ivan.asd.sgi.com> To: info-performer@sgi.sgi.com, "Carlo L. Tiana" Subject: Re: Movie generation/format conversion Try to use /usr/sbin/movie from the subsystem eoe2.sw.imagetools in 5.2. Just enter: movie file1.rgb file2.rgb ... If you want to slow down the movie, enter: movie file1.rgb file1.rgb file2.rgb file2.rgb ... Ivan Bach, ib@sgi.com From guest Thu Jun 9 23:42:52 1994 Date: Fri, 10 Jun 1994 08:44:06 +0059 (MDT) From: Henrik Tramberend Subject: Re: Movie generation/format conversion To: "Carlo L. Tiana" Cc: info-performer@sgi.sgi.com In-Reply-To: <199406091637.JAA28788@descartes.arc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Jun 1994, Carlo L. Tiana wrote: > I would like to compose a movie from them. THe number is > high enough (150 frames) that using moviemaker to load > each frame manually is a little painful. In addition, Try 'man makemovie'. That's what you need. Regards, Henrik ------------------------------------------------------------------------ Henrik Tramberend Phone: +49(30)262.94.01 Art+Com e.V. Fax: +49(30)261.90.36 Berlin, Germany E-Mail: henrik@artcom.de From guest Mon Jun 13 10:24:05 1994 Date: Mon, 13 Jun 1994 10:23:56 -0700 From: "Carlo L. Tiana" Message-Id: <199406131723.KAA00482@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: SUMMARY Re: Movie generation/format conversion Thanks for the many helpful hints. I recently posted this question: > I hope this question is relevant enought for this list. > I have a number of snapshots taken from renderings of > a scene by Performer. THey are all .rgb files. > I would like to compose a movie from them. THe number is > high enough (150 frames) that using moviemaker to load > each frame manually is a little painful. In addition, > I am trying to use ImageVision Library to process the > resulting movie, and IL does not seem to recognize the > movie format moviemaker generates. > What I am wondering is (in order of decreasing appeal!): > - are there tools to take a number of .rgb files and > create an IL movie (and if so are there tools that will > do the reverse (take an IL movie and split it into a > number of .rgb files) > - are three tools that will take a number of .rgb files > and create a 'moviemaker' format movie (whatever that is) > (and the reverse would be nice too). > > Sorry if this is far off the mark for this list. > Carlo Tiana > NASA Ames Research Center A number of people pointed me to a number of tools, and I myself remembered the existence of others. In particular: /usr/sbin/movie will take a series of .rgb files and play them as a movie. Not too flexible otherwise (and I could not find a way to save that movie). This has a man page. /usr/sbin/makemovie more flexible than the above and will let you save the movie. Has a man page. Movie created can be edited manually with moviemaker. moviemaster this was suggested by the list, though it's not on my system so I can't comment on it. ilcat/ilmovie these 2 'demo quality' tools come with the ImageVision library in source form (in /usr/people/4Dgifts/examples/ImageVision). ilcat will take a bunch of .rgb (and others) files and make a movie ImageVision recognizes as such (I have not compared this format to that of the other tools mentioned), and ilmovie will play this movie as well as allowing one to perform some image processing operations on the movie (frame by frame). Unfortunately the processed movie cannot be saved, although since the source code for this is available this is a simple addition one can make. These guys did it for me, since my requirement was to create a movie that IL would be able to operate on. Thanks to all for their help. Carlo Tiana NASA/Ames Research Center. From guest Tue Jun 14 11:45:20 1994 Date: Tue, 14 Jun 94 11:43:34 PDT From: ling@cod.nosc.mil (Ling Vongsouthy) Message-Id: <9406141843.AA04987@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Diffuse Color Hi there, I am a beginner on Performer. I have questions about changing diffuse color of objects using the smallfly program. The following is a portion of smallfly.c that I modified: Void InitScene(void) { .... .... .... for(i = 0; i < Numfiles; i++) { material = pfNewMtl(pfGetSharedArena()); pfMtlColorMode(material, PFMTL_FRONT, LMC_AD); gstate = pfNewGState(pfGetSharedArena()); root = (pfGroup *)LoadFile(DatabaseFiles[i], gstate); pfGStateAttr(gstate, PFSTSTE_FRONTMTL, material); pfMtlColor(material, PFMTL_DIFFUSE, 1.0, 0.0, 0.0); ..... ..... The modified smallfly program compiled no problem. However I can change the color of .obj files only. What do I have to do to change the color on other file formats (.dxf, .sv, etc). Thanks From guest Wed Jun 15 11:20:22 1994 Wed, 15 Jun 1994 11:20:08 -0700 for <@ucsd.ucsd.edu:info-performer@sgi.com> From: prwhite@sgva-xs4.ucsd.edu (Payton White) Message-Id: <9406151820.AA12228@sgva-xs4> Subject: Multi-process problem To: info-performer@sgi.sgi.com Date: Wed, 15 Jun 1994 11:19:59 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1358 Status: OR This should be a simple problem, but it has been causing us much trouble. We have been developing a scaled down application on some single cpu machines with Performer 1.2 with no problems. When we recompile and run it on a RE (OS 5.2) we get plenty of crashes. As per the manual, this means we are probably doing something wrong with (not) allocating things in our shared memory structure. We have _everything_ (scene, pipe, channel, env, light model material, etc) in our shared structure and we malloc for it before pfConfig when the processes split. Through debugging we have found it crashes on pfShadeModel, pfApplyLModel, pfApplyMtl, pfApplyGState. My question is, just what exactly must be allocated in the shared structure, how and when? Adapting perfly or other examples is not an alternative that we welcome, but any solutions and ideas about this problem are. Thanks, -- Visualization << SGI >> Simulation -- Payton R. White __ __ __ prwhite@ucsd.edu / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From guest Wed Jun 15 05:56:12 1994 Message-Id: Date: Wed, 15 Jun 94 14:56 MDT From: matomira@ligsg2.epfl.ch (Fernando D. Mato Mira) To: info-performer Subject: threaded Performer Reply-To: matomira@epfl.ch Hello, Have you thought about giving the possibility to the users of choosing how the processes should be spawned (that is, using sproc instead of fork). When using sproc the drawing, culling process callbacks should take one more argument (the private data block). I think this would be quite easy to implement. This is very important for people who have a HUGE application that they do not want to clone for every process. (in my case, I run Performer from Lisp, and I do not want to copy 20Mb of developent environment, libraries, GUI toolkit, application on things that might even not need Lisp (for example if the cull callbacks are all writen in C). When the callbacks need Lisp, I might want to refer to things in my app (I have multiple processes, locks, etc in Lisp, too), so it has to be ONE Lisp. What's more, even in the case when you fork the processes, and I replicate Lisps, I might need to initialize the Lisp in the other process, if I am going to call Lisp routines as callbacks, or in C callbacks. This is possible for the draw process (pfInitPipe), but not for the cull process. When processes are spawned via sproc, I might need to initilize a lisp process representing the corresponding Unix thread (this assumes a lisp where processes are implemented using Unix threads). Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Wed Jun 15 14:30:21 1994 Date: Wed, 15 Jun 94 14:28:26 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406152128.AA27499@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Coloring Models in Performer Cc: goodhart@cod.nosc.mil I am using perfly to implement a specific type of object selection algorithm. I want to be able to change the color of some model dynamically. For example at some given time I want to change the color of the geometry under node X to red. Currently I think that node X is a DCS. The data files that I've tried this with are flt format files, obj files, and iv files. When I do what follows below all that happens is that the model turns grey instead of the desired color. 1) Let's say I load 4 data files (4 separate objects) such as 4 enterprise.flt files. ie: perfly enterprise.flt enterprise.flt enterprise.flt enterprise.flt c) My SW selects one of those objects (models) and attempts to change its color. I do this in a node call back function during the draw traversal. So I execute the following when I am reading in the model files. ptrToNode is a pointer to the node that gets set up when perfly loads a file. int mydata; pfNodeTravFuncs(ptrToNode, PFTRAV_DRAW, clgpreDraw, clgpostDraw); pfNodeTravData(ptrToNode, PFTRAV_DRAW, &mydata); In the preDraw function I intend to color the object red when test is set: long clgpreDraw(pfTraverser *trav, void *data) { int test; static int firsttime = 0; static pfMaterial *ahaPreselectMtl; /* Please forgive this hack of setting the material here * I intend to move it to an initialization file when I * get things working. */ if (!firsttime) { firsttime = 1; ahaPreselectMtl = pfNewMtl(NULL); } test = *(int *) data; if (test) { pfPushState(); pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_CMODE_COLOR); /* I also tried it with the following statement included - nodifference * pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_AD); */ pfMtlColor(ahaPreselectMtl, PFMTL_DIFFUSE, 1.0, 0.0, 0.0); pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_ON); pfApplyMtl(ahaPreselectMtl); } return PFTRAV_CONT; } The postDraw function to restore the state is: long clgpostDraw(pfTraverser *trav, void *data) { int test; test = *(int *)data; if (test) { pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_OFF); pfPopState(); } return PFTRAV_CONT; } The idea is that whenever test is 1 I want to change the color of that object to red. When I use what I show you above the material of the selected object becomes gray rather than red. This code seems to work ok when I change the selected object to wireframe rather than coloring the object red (ie I just do a pfEnable(PFEN_WIREFRAME) in the preDraw, and a pfDisable(PFEN_WIREFRAME) in the postDraw. 3) We are running on an Onyx running IRIX 5.2 and using Performer 1.2. Thank you, Curt Goodhart From aschaffe Wed Jun 15 17:27:45 1994 From: aschaffe (Allan Schaffer) Message-Id: <9406151727.ZM17353@holodeck.asd.sgi.com> Date: Wed, 15 Jun 1994 17:27:34 -0700 In-Reply-To: prwhite@sgva-xs4.ucsd.edu (Payton White) "Multi-process problem" (Jun 15, 11:19am) References: <9406151820.AA12228@sgva-xs4> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: prwhite@sgva-xs4.ucsd.edu (Payton White), info-performer@sgi.sgi.com Subject: Re: Multi-process problem Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jun 15, 11:19am, Payton White wrote: > > This should be a simple problem, but it has been causing us much > trouble. We have been developing a scaled down application on some > single cpu machines with Performer 1.2 with no problems. When we > recompile and run it on a RE (OS 5.2) we get plenty of crashes. As > per the manual, this means we are probably doing something wrong > with (not) allocating things in our shared memory structure. We have > _everything_ (scene, pipe, channel, env, light model material, etc) > in our shared structure and we malloc for it before pfConfig when the > processes split. Just for a sanity check -- be sure that you're using pfMalloc (and not malloc). Also that the pfMalloc for your shared struct is between pfInit() and pfConfig(), ie.. /* Initialize Performer */ pfInit(); /* Use default multiprocessing mode based on number of processors. */ pfMultiprocess (PFMP_DEFAULT); /* Malloc storage in shared memory region for shared data */ shared = (SharedData *) pfMalloc(sizeof(SharedData),pfGetSharedArena()); /* Configure multiprocessing mode and start parallel processes */ pfConfig(); > Through debugging we have found it crashes on > pfShadeModel, pfApplyLModel, pfApplyMtl, pfApplyGState. It's likely then that you're calling these routines from the APP process. They are libpr routines that make GL calls, so they can only be called from within the DRAW. On an MP machine, the APP, CULL, and DRAW stages can each be different processes. Only the DRAW process has access to the rendering pipeline, so you can only make those calls in the pipe initialization callback, channel draw callback, or node draw callbacks. When Performer runs on a 1-CPU machine this doesn't matter so much, since the APP, CULL, and DRAW are all part of the same process. That's probably why you didn't see the problem before. And as always, take a look in /usr/src/Performer/src/pguide/libpf/progs for some samples. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Thu Jun 16 11:25:19 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406161825.AA05103@tubes.asd.sgi.com> Subject: Re: Coloring Models in Performer To: guest (Curtis L. Goodhart) Date: Thu, 16 Jun 94 11:25:06 PDT Cc: info-performer@sgi.sgi.com, goodhart@cod.nosc.mil In-Reply-To: <9406152128.AA27499@cod.nosc.mil>; from "Curtis L. Goodhart" at Jun 15, 94 2:28 pm X-Mailer: ELM [version 2.3 PL8] > > > I am using perfly to implement a specific type of object selection > algorithm. I want to be able to change the color of some model > dynamically. For example at some given time I want to change the > color of the geometry under node X to red. Currently I think that > node X is a DCS. > > The data files that I've tried this with are flt format files, > obj files, and iv files. > > When I do what follows below all that happens is that the model turns > grey instead of the desired color. > > 1) Let's say I load 4 data files (4 separate objects) such as > 4 enterprise.flt files. > ie: > > perfly enterprise.flt enterprise.flt enterprise.flt enterprise.flt > > c) My SW selects one of those objects (models) and attempts to change > its color. I do this in a node call back function during > the draw traversal. > > So I execute the following when I am reading in the model files. > ptrToNode is a pointer to the node that gets set up when perfly > loads a file. > > int mydata; > pfNodeTravFuncs(ptrToNode, PFTRAV_DRAW, clgpreDraw, clgpostDraw); > pfNodeTravData(ptrToNode, PFTRAV_DRAW, &mydata); > > In the preDraw function I intend to color the object red > when test is set: > > long > clgpreDraw(pfTraverser *trav, void *data) > { > int test; > static int firsttime = 0; > static pfMaterial *ahaPreselectMtl; > > /* Please forgive this hack of setting the material here > * I intend to move it to an initialization file when I > * get things working. > */ > if (!firsttime) > { > firsttime = 1; > ahaPreselectMtl = pfNewMtl(NULL); > } > > test = *(int *) data; > if (test) > { > pfPushState(); > pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_CMODE_COLOR); > > /* I also tried it with the following statement included - nodifference > * pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_AD); > */ > pfMtlColor(ahaPreselectMtl, PFMTL_DIFFUSE, 1.0, 0.0, 0.0); > pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_ON); > pfApplyMtl(ahaPreselectMtl); > } > return PFTRAV_CONT; > } > > The postDraw function to restore the state is: > > long > clgpostDraw(pfTraverser *trav, void *data) > { > int test; > > test = *(int *)data; > > if (test) > { > pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_OFF); > pfPopState(); > } > return PFTRAV_CONT; > } > > > > The idea is that whenever test is 1 I want to change the color > of that object to red. > > When I use what I show you above the material of the selected > object becomes gray rather than red. > > This code seems to work ok when I change the selected object to > wireframe rather than coloring the object red (ie I just do a > pfEnable(PFEN_WIREFRAME) in the preDraw, and a > pfDisable(PFEN_WIREFRAME) in the postDraw. > > > 3) We are running on an Onyx running IRIX 5.2 and using > Performer 1.2. > > > Thank you, > > Curt Goodhart > > > > > > From guest Thu Jun 16 12:06:18 1994 From: "Sharon Fischler" Message-Id: <9406161206.ZM12134@rose.asd.sgi.com> Date: Thu, 16 Jun 1994 12:06:02 -0700 In-Reply-To: goodhart@cod.nosc.mil (Curtis L. Goodhart) "Coloring Models in Performer" (Jun 15, 2:28pm) References: <9406152128.AA27499@cod.nosc.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: goodhart@cod.nosc.mil (Curtis L. Goodhart), info-performer@sgi.sgi.com Subject: Re: Coloring Models in Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 +>---- On Jun 15, 2:28pm, Curtis L. Goodhart wrote: > Subject: Coloring Models in Performer -> ->I am using perfly to implement a specific type of object selection ->algorithm. I want to be able to change the color of some model ->dynamically. For example at some given time I want to change the ->color of the geometry under node X to red. Currently I think that ->node X is a DCS. -> Performer highlighting was implemented in 1.2 specifically for this purpose. You can temporarily change the color of an object, draw it with outlines, or interesting multi-color patterns, and even make them transparent - all without destroying the man pfGeoState of the object. You can highlight specific pfGeoStates, turn it on on a pfGeoState, or enable it globally. The pickfly example uses highlighting to color the selected object. /usr/src/Performer/src/sample/pickfly There is a highlighting example at /usr/src/Performer/pguide/libpr/progs/hlcube.c and you can man on pfHighlight. srf. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Fri Jun 17 14:06:17 1994 Date: Fri, 17 Jun 94 14:06:08 -0700 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9406172106.AA12633@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: pfPhase() Status: OR We are using: SkyWriter VGXT, IRIX 4.0.5, Performer 1.0 My situation: Our app has always been used with pfPhase set to PFPHSE_FREE_RUN. Now we need a fixed frame rate for taking experimental data. By setting the phase to PFPHASE_LOCK the app is still looping, but the display is frozen. I can change at will between PFPHASE_LOCK and PFPHASE_FLOAT and the app loops with no new display. Whenever I set the phase back to PFPHASE_FREE_RUN, the app loops three more times, then hangs. I have tried making PFPHASE_LOCK the default (so we are not changing it dynamically) but with the same results. We have never had any problems changing the framerate while in PFPHASE_FREE_RUN. My questions: How do I get it to work? :^) More specifically, are we supposed to be able to change the phase dynamically? Is this frozen display a bug in our code, or somewhere else? Why would it hang when going to PFPHASE_FREE_RUN? -------------------+------------------------------+------------------------ William Briggs | MailStop 262-2 | "The computer screen NASA Ames Research | PO Box 1000 | has become the retina (415) 604-6438 | Moffett Field, CA 94035-1000 | of the mind's eye." -------------------+------------------------------+------------------------ From guest Mon Jun 20 01:47:42 1994 From: "Ran Yakir" Message-Id: <9406201147.ZM1394@rea1.bvr.co.il> Date: Mon, 20 Jun 1994 11:47:16 +0000 X-Face: aaaaaaaaaaljasddfjsdlkfjasd X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfMultiPipe + pfMultiProcess Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hi A problem : Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual pipe performer application. The following pfMultiProcess modes give you the following results : 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - because you have only 4 CPUs) 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls in the same process No item here gives good results. This is due to the fact that multi-processing mode is the same for all pipes. If multi-processing mode was per pipe - I could run one pipe as PFMP_APPCULL_DRAW, and the other as PFMP_APP_CULL_DRAW. Then I would fully occupy my 4 CPUs. I know that 4 CPUs in not the bets configuration for running a dual pipe performer application, but I think that allowing a separate multi-processing mode for pipes would help in similar cases. Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Mon Jun 20 18:38:55 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9406201838.ZM4391@holodeck.asd.sgi.com> Resent-Date: Mon, 20 Jun 1994 18:38:49 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer@sgi.sgi.com From: jaydee@thor.ats.qc.ca (Jean Daigle) Date: Mon, 20 Jun 1994 09:55:39 -0400 In-Reply-To: "Ran Yakir" "pfMultiPipe + pfMultiProcess" (Jun 20, 11:47am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: guest Subject: Re: pfMultiPipe + pfMultiProcess On Jun 20, 11:47am, "Ran Yakir" wrote: } Subject: pfMultiPipe + pfMultiProcess } From guest@holodeck.asd.sgi.com Mon Jun 20 05:07:35 1994 } From: "Ran Yakir" } Date: Mon, 20 Jun 1994 11:47:16 +0000 } X-Face: aaaaaaaaaaljasddfjsdlkfjasd } X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) } To: info-performer@sgi.com } Subject: pfMultiPipe + pfMultiProcess } Content-Type: text/plain; charset=us-ascii } Mime-Version: 1.0 } } Hi } } A problem : } } Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual } pipe performer application. The following pfMultiProcess modes give you the } following results : } } 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) } 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - } because you have only 4 CPUs) } 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls } in the same process ... } }-- End of excerpt from "Ran Yakir" Have you tried PFMP_APP_CULLDRAW? This will utilize your 4 processors effectively -- 1 for UNIX, 1 for APP, 2 for CULL+DRAW for your two pipes. This would imply that your scene is light enough for CULL+DRAW to not frame-extend. Such has not been the case for us, but your mileage may vary. Your alternative of allowing per-pipe multiprocessing mode specification sounds attractive. I'd be very interested in trying it out should the wizards of Performerdom make this feature available. In the mean time, would it be at all possible to run two completely separate Performer instances, each configured for one of your two pipes, and communicating via shared memory for syncronization? Just a wild thought. Regards, Jean Daigle. ----------------------------------------------------------------- | Jean Daigle ATS AeroTechnologies Inc. | | Software Designer 1250 Boul Marie-Victorin | | St. Bruno, QC J3V 6B8 | | jaydee@ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 | ----------------------------------------------------------------- From guest Mon Jun 20 08:13:42 1994 Message-Id: <199406201512.IAA21256@archimedes.chinalake.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: Data Stream buffering/interpolation... Hello! While not graphics, this would be of VizSim importance. I have to buffer the incoming data stream from ethernet to our app for three reasons: 1) the data stream may be coming in at a fixed, known data rate *slower* than 30 Hz, 2) incoming packets may occasionally be lost, and 3) the data may "jerk" about -- move randomly about the "real" location (GPS margin of error). My first thought is to try a real-time spline function. This could possibly smooth the data to any rate I'd wish, but I haven't heard of any "predictive" algorithms (haven't started looking 'til now, either :-) If I didn't care about the possible visual descrepencies during the acquisition (I do), then I could do the interpolation after acquisition and before "playback". Questions are then: - What is a suitable splining (or other smoothing) function to use, that could possibly work real-time in a predictive manner? - What is a good way to interpolation the rotations (quaternions)? - Is this the proper way to approach this problem? - What are you doing, if you have this same problem? Any pointers to papers, books, code snippets, etc. welcome! Thanks! jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Dude Internet: jan@archimedes.nwc.navy.mil Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA Naval Air Warfare Center kc6uth@kc6uth.ampr.org -Weapons Division [44.17.2.6] From guest Mon Jun 20 11:04:19 1994 From: "Chris Tanner" Message-Id: <9406201104.ZM6984@faith.asd.sgi.com> Date: Mon, 20 Jun 1994 11:04:06 -0700 In-Reply-To: "Ran Yakir" "pfMultiPipe + pfMultiProcess" (Jun 20, 11:47am) References: <9406201147.ZM1394@rea1.bvr.co.il> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Ran Yakir" , info-performer@sgi.sgi.com Subject: Re: pfMultiPipe + pfMultiProcess Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Jun 20, 11:47am, Ran Yakir wrote: > Subject: pfMultiPipe + pfMultiProcess > Hi > > A problem : > > Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual > pipe performer application. The following pfMultiProcess modes give you the > following results : > > 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) > 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - > because you have only 4 CPUs) > 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls > in the same process > > No item here gives good results. This is due to the fact that multi-processing > mode is the same for all pipes. If multi-processing mode was per pipe - I could > run one pipe as PFMP_APPCULL_DRAW, and the other as PFMP_APP_CULL_DRAW. Then I > would fully occupy my 4 CPUs. > I know that 4 CPUs in not the bets configuration for running a dual pipe > performer application, but I think that allowing a separate multi-processing > mode for pipes would help in similar cases. > > > Thanks > > Ran Yakir >-- End of excerpt from Ran Yakir Because of current complexities in the Performer MP framework, if you are using multiple pfPipes then you must have the cull process forked (because they dont share views and thus they dont share culls). This means that you should try just forking the cull (APP_CULLDRAW). That should give you (if you look at procs with ps for instance): 1) App 2) (a clock wrapper proc that doesnt eat much cpu)... 3) CullDraw 4) CullDraw Hope that helps... Later, Chris Tanner IRIS Performer Remember, if you really want best real-time results make sure you take a look at 'lockcpu.c' in the 1.2 /usr/src/Performer/src/lib/libpfutil directory such that you can lock the procs down on the corresponding cpus and ensure no competition for processors or context switches... -- _____________________________________________________________ Chris Tanner (cct@faith.asd.sgi.com) Silicon Graphics - Advanced Graphics Division _____________________________________________________________ From guest Tue Jun 21 08:35:52 1994 Date: Tue, 21 Jun 94 08:34:01 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406211534.AA12516@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: pfMakePtsPlane in Performer 1.2 for IRIX 4.05H Cc: goodhart@cod.nosc.mil Has anybody had any problems with the function pfMakePtsPlane. I've been getting segmentation violations (I think) when I call that function. I remember this problem in the past too, perhaps on a Beta version. Just wondering if anyone has seen any similar behavior. Running Performer 1.2 on IRIX 4.05H on a Crimson Reality Engine. Curt PS I haven't had any problem with this on Performer 1.2 for IRIX 5.2 on an Onyx. From guest Tue Jun 21 10:48:56 1994 Message-Id: <9406211748.AA22830@surreal.asd.sgi.com> To: goodhart@cod.nosc.mil (Curtis L. Goodhart) Cc: info-performer@sgi.sgi.com Subject: Re: pfMakePtsPlane in Performer 1.2 for IRIX 4.05H In-Reply-To: Your message of "Tue, 21 Jun 94 08:34:01 PDT." <9406211534.AA12516@cod.nosc.mil> Date: Tue, 21 Jun 94 10:48:46 -0700 From: Jim Helman The code for this routine is extremely simple and is identical in 1.1 and both 1.2 versions (5.2 and 4.0.5). I can't think of any reason why it would behave differently on 4.0.5H vs. 5.2 or on a Crimson vs. Onyx. Bad FP values or colinear points could cause an FP exception, but as far as I can tell, a SEGV would only be caused by a bad pointer either one of the pfVec3 src args or the pfPlane* dst arg. Can you get it to fail in a simple case? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Date: Tue, 21 Jun 94 08:34:01 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) To: info-performer@sgi.sgi.com Subject: pfMakePtsPlane in Performer 1.2 for IRIX 4.05H Has anybody had any problems with the function pfMakePtsPlane. I've been getting segmentation violations (I think) when I call that function. I remember this problem in the past too, perhaps on a Beta version. Just wondering if anyone has seen any similar behavior. Running Performer 1.2 on IRIX 4.05H on a Crimson Reality Engine. Curt PS I haven't had any problem with this on Performer 1.2 for IRIX 5.2 on an Onyx. From guest Tue Jun 21 12:03:52 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406211903.AA09441@tubes.asd.sgi.com> Subject: Re: pfMultiPipe + pfMultiProcess To: guest (Ran Yakir) Date: Tue, 21 Jun 94 12:03:37 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406201147.ZM1394@rea1.bvr.co.il>; from "Ran Yakir" at Jun 20, 94 11:47 am X-Mailer: ELM [version 2.3 PL8] > > Hi > > A problem : > > Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual > pipe performer application. The following pfMultiProcess modes give you the > following results : > > 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) > 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - > because you have only 4 CPUs) > 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls > in the same process > > No item here gives good results. This is due to the fact that multi-processing > mode is the same for all pipes. If multi-processing mode was per pipe - I could > run one pipe as PFMP_APPCULL_DRAW, and the other as PFMP_APP_CULL_DRAW. Then I > would fully occupy my 4 CPUs. This makes sense if the culling loads for your 2 pipes are not balanced. The pipe with PFMP_APP_CULL_DRAW will have an entire CPU dedicated to culling while the PFMP_APPCULL_DRAW pipe will have to share APP with CULL. In general I am not in favor of asymmetric multiprocessing pipelines. It complicates Performer's API, semantics and internal code. The salient issue here is how to attain better load balancing. Performer's multiprocessing granularity is coarse which hampers load balancing but I believe the dividends of vastly reduced synchronization overhead, data management and a simplified programming model greatly outweigh any load balancing problems arising from coarse-grained parallelism. In addition, you can, in theory, duplicate the above behavior by using IRIX5 sysmp/schedctl commands to restrict processes to CPUs. For the above example you could MP_RESTRICT the 2 CULLs to the same CPU and use priorities or your own semaphores in the cull callbacks to serialize the 2 CULL processes and avoid wasted effort in context switching. > I know that 4 CPUs in not the bets configuration for running a dual pipe > performer application, but I think that allowing a separate multi-processing > mode for pipes would help in similar cases. > From guest Wed Jun 22 01:53:22 1994 Message-Id: <9406220852.AA82131@ns.trl.ibm.com> To: info-performer Cc: aono@trl.ibm.co.jp Subject: texture-map with Performer Date: Wed, 22 Jun 1994 17:52:39 +0900 From: Masaki Aono Status: OR Hi. I'm curious about texture mapping with Performer. My questions are as follows: (1) Given a set of 3D triangles that represent a human head bone. Is there a tool to generate cylindrical/spherical texture coordinates such as the ones that are provided by Inventor's facilities? Please note that I want to texture-map an image surrounding the human head bone. If anyone knows a better way of texture-map with other methods, please suggest it to me. (2) Is there a source code that corresponds to pfLoadTexFile(tex,name)? I'm particularly interested in understanding the specific format of the texture image file. Although there is a description of such image file in GL's Programming Guide, it seems that a real texture file has certain header information (judging from the data provided in /usr/src/Performer/data such as tree.rgba and wood256.rgb), doesn't it? Anyone who knows the texture image format, please let me know. I'd appreciate anyone who can give an answer to me. Regards, Masaki Aono Tokyo Research Laboratory aono@trl.ibm.co.jp From guest Wed Jun 22 11:04:44 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406221804.AA16622@tubes.asd.sgi.com> Subject: Re: pfPhase() To: guest (William Briggs) Date: Wed, 22 Jun 94 11:04:32 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406172106.AA12633@niesten.arc.nasa.gov>; from "William Briggs" at Jun 17, 94 2:06 pm X-Mailer: ELM [version 2.3 PL8] > > We are using: SkyWriter VGXT, IRIX 4.0.5, Performer 1.0 > > My situation: Our app has always been used with pfPhase set to > PFPHSE_FREE_RUN. Now we need a fixed frame rate > for taking experimental data. By setting the > phase to PFPHASE_LOCK the app is still looping, > but the display is frozen. I can change at will > between PFPHASE_LOCK and PFPHASE_FLOAT and the app > loops with no new display. Whenever I set the phase > back to PFPHASE_FREE_RUN, the app loops three more > times, then hangs. I have tried making PFPHASE_LOCK > the default (so we are not changing it dynamically) > but with the same results. We have never had any > problems changing the framerate while in PFPHASE_FREE_RUN. > > My questions: How do I get it to work? :^) More specifically, are > we supposed to be able to change the phase dynamically? > Is this frozen display a bug in our code, or somewhere > else? Why would it hang when going to PFPHASE_FREE_RUN? > > -------------------+------------------------------+------------------------ > William Briggs | MailStop 262-2 | "The computer screen > NASA Ames Research | PO Box 1000 | has become the retina > (415) 604-6438 | Moffett Field, CA 94035-1000 | of the mind's eye." > -------------------+------------------------------+------------------------ > > > > From guest Wed Jun 22 10:52:57 1994 From: Bernd Froehlich Message-Id: <9406221554.AA06322@viswiz.gmd.de> Subject: Darkness To: info-performer@sgi.sgi.com Date: Wed, 22 Jun 94 19:39:09 MDT Status: OR Hi, we have just moved from Performer 1.2 beta ( 1.2a64 ) to 1.2 and from Irix5.1.1.2 to 5.2 on our Onyx RE2 system. Our software uses an extended version of the wavefront-obj-loader of the Performer 1.2 beta release. After recompiling the sources under 5.2 and Performer 1.2 our objects are not lit any more. Only the ambient term seems to work. Any ideas? Bernd ------------------------------------------------------------------------- Bernd Froehlich email: bernd@viswiz.gmd.de Dept. Scientific Visualization Tel: +49-2241-14-2364 GMD Fax: +49-2241-14-2040 Schloss Birlinghoven D-53754 St. Augustin Germany ------------------------------------------------------------------------- From guest Tue Jun 28 09:13:09 1994 Date: Tue, 28 Jun 94 09:12:56 -0700 From: mtj@babar (Michael Jones) Message-Id: <9406281612.AA23716@babar.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Performer Demo Contest Status: OR To: Friends of Performer Worldwide From: The IRIS Performer Team RE: SIGGRAPH '94 Performer Contest The IRIS Performer team will again have an Onyx/RE2 system in one of SGI's booths at SIGGRAPH '94 in Orlando, Florida. We are looking for interesting and attractive demos of existing applications developed using IRIS Performer for exhibition at this station. The prizes, beyond the deep and lasting satisfaction of public recognition of a job well done, will be a new IRIS Performer "polo-style" shirt that has the IRIS Performer (with top-hat and cane) embroidered in seven colors on the front. This latest addition to the PerformerWear line is beautiful and much sought after. We'll have a 4-CPU deskside system with either two or four Raster Manager boards at a small stand with monitor, mouse and (possibly) a flybox. If you have an application that runs well in this configuration that you would like to enter into the judging for the demo contest, please take the following steps: 1. Send email to me (mtj@sgi.com) with a brief summary of the application: what it is, how the user interacts, frame rates, special I/O devices required, etc. A screen snapshot in RGB form would be great. The decision will happen on July 11th, and entries after the decision will be deemed to have lost. 2. I'll respond with the method for sending your demo to us for judging and a simple release form that says we're allowed to show the demo in our booth at SIGGRAPH '94. FAX the release back to me and ftp or mail the demo, and you'll have entered. 3. Please let me know if you would be willing to schedule a time slot during SIGGRAPH when you could come by the booth and explain your work to the many customers who will be asking for more information. 4. Also, let me know if you'd like to have an RGB snapshot of your application and a one paragraph description of it to appear on the SGI IRIS Performer xmosaic page. The judges (the seven members of the IRIS Performer team) will pick four winning demos based on theme, technical merit, and beauty. All entrants -- winning or not -- will be invited to join the IRIS Performer team for a late-night "engineering discussion" (;-) at Disney's Pleasure Island. Good Luck! Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Wed Jun 29 11:11:10 1994 Date: Wed, 29 Jun 94 11:07:57 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406291807.AA07297@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Compiler crash - perfly Status: OR A couple of us now have experienced system intermittent system crashes when we are compiling modified perfly code. We are running on an ONYX with 2 CPUs running IRIX 5.2 and Performer 1.2. We do a make on perfly, and the system crashes and then comes up in the state where we can restart the system (ie the display comes up with the icons for different things: green light for restarting the system, an icon for diagnostics, etc). A recompile of the same source code then may work. Ie the crash is itermittent. Anyone experienced anything like this? Thanks, Curt Goodhart NRaD San Diego, CA 619 553-2002 From guest Wed Jun 29 18:59:43 1994 Message-Id: <00581.2855761377.1539@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 29 Jun 1994 17:00:55 PST Subject: Re: FadeLOD & Lightpoints == Reply to: RE>FadeLOD & Lightpoints == BU Sorry for the late reply, The OpenFlight loader does not handle directional light points correctly. The direction vector is simply interpreted wrong and the light shape is 90 degrees by 90 degrees (old/current Performer defaults?). MultiGen directional lights have shapes of 180 by 180 degrees. If they have a back color they're considered PFLP_BIDIRECTIONAL (but only front colored, hmm... any chance that Performer will support multi-colored light points?) otherwise they're PFLP_UNIDIRECTIONAL. Light point direction vector and shape are nearly fixed. These and other improvements will be available in the next OpenFlight loader released by MultiGen Inc., some time in July ... 1994 ;-) (SIGGRAPH permitting) As to the falloff of a pfLightPoint, MultiGen doesn't have that concept, so the default falloff value of 4 is used by the loader. Their interaction with Performer's fade LOD capability is best answer by someone in the Performer Group. PS: Thanks for the reminder Jean. Regards, Mark Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4110 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET -------------------------------------- Date: 6/8/94 10:05 PM To: Marcus From: Howard Abrams From guest Wed Jun 29 11:14:04 1994 Message-Id: Date: Wed, 29 Jun 94 20:13 MDT From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: stereo on Indigo II Extreme Reply-To: matomira@epfl.ch Hello, I am running Performer 1.2 on an Indigo II Extreme with 5.2 and everything is OK with the dual-channel display until I do setmonitor(STR_RECT) Then, the machine gets into stereo mode, and I get to see in stereo, but the application stops updating the display, even if I return to normal mode. The programs seems to run fine if stereo was set before lanunching it (of course, doing setmonitor from the program messes up allways). I create the channels like in the 3-channel simulation example (with one less channel, different offsets, and viewports that will match the stereo drawing areas). Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Thu Jun 30 01:52:08 1994 Date: Thu, 30 Jun 94 10:52:04 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9406300852.AA01757@scl> To: info-performer@sgi.sgi.com Subject: Shadows ... Bonjour a tous ... This is not really a Performer question but the answer should help me to use it in !. Any ideas where I can find some shadows rendering example codes ?. Merci par avance ... Thank's a lot ... Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Thu Jun 30 09:38:29 1994 Date: Thu, 30 Jun 94 09:06:10 -0700 From: sal@sgidev.mdc.com (Sal Cabaruvias) Message-Id: <9406301606.AA15175@sgidev.mdc.com> To: iris-performer@sgi.sgi.com Subject: Performer Questions Hi, I was refered by local sgi salesman to you. I hope you can help me. I am creating a 400 by 400 nm database using DTED data. This creates 60 by 60 nm tiles (sections). If I was to implemented a swapping alogithm to bring my tiles as I need them, what Performer calls do I use? I am using Coryphaeus DWB to create my database files. I not sure what calls release old sections of the database and what calls bring in databases. Thanks, sal ----------------------------------------------------------------------------- Salvador Cabaruvias |email: sal@sgidev.mdc.com CSSL |saying: "Well I be done seen about McDonnell Douglas | everything when I see elephant (310) 593-6719 | fly!" --- Dumbo --- ----------------------------------------------------------------------------- From guest Fri Jul 1 14:22:58 1994 Message-Id: <199407012122.OAA04765@sgi.sgi.com> Date: 1 Jul 94 17:15:00 EST From: "Scott Davidson" Subject: pfFrame questions To: "info-performer" If I understand forked intersections, it appears to me that the argument to pfIsectFunc is initiated at each pfFrame and then runs asynchronously with the rest of the rendering pipeline. What happens if the intersection processing at frame "n" continues beyond the call to pfFrame in frame "n+1"? Are the intersections at frame "n" discarded? Is it possible for an application-sproc'd process to call pfSync/pfFrame in stead of the application making the calls? If the sproc'd process can call pfFrame, is the performer in-memory database locked during the pfFrame operation? If so, what is the latency associated with pfFrame including the locked operation? From guest Fri Jul 1 15:46:23 1994 Message-Id: <9407012246.AA08989@surreal.asd.sgi.com> To: "Scott Davidson" Cc: "info-performer" Subject: Re: pfFrame questions In-Reply-To: Your message of "01 Jul 94 17:15:00 EST." <199407012122.OAA04765@sgi.sgi.com> Date: Fri, 01 Jul 94 15:46:05 -0700 From: Jim Helman > If I understand forked intersections, it appears to > me that the argument to pfIsectFunc is initiated at each > pfFrame and then runs asynchronously with the rest of the > rendering pipeline. What happens if the intersection > processing at frame "n" continues beyond the call to > pfFrame in frame "n+1"? Are the intersections at frame > "n" discarded? pfIsectFunc is initiated at each pfFrame, but only if the previous invocation of the isect func has completed. Hence, if intersections for frame "n" extend into frame "n+1", then pfIsectFunc won't be called again until frame "n+2" at the earliest. > Is it possible for an application-sproc'd process to > call pfSync/pfFrame in stead of the application making > the calls? If the sproc'd process can call pfFrame, is > the performer in-memory database locked during the > pfFrame operation? A sproc'd APP thread should not modifiy libpf objects while the other thread is doing so or while the other thread is in pfFrame or pfSync. Basically, sprocing only buys you is the ability to create libpr objects or do other non-performer processing in the sproc'd thread. We're looking at better ways to allow simultaneous access to the APP's scene graph for things like database paging. > If so, what is the latency associated > with pfFrame including the locked operation? pfFrame returns fairly quickly in MP mode if pfSync has already been called, otherwise it sleeps until the next frame boundary. pfSync on the other hand not only cleans the libpf scene graph, but always waits until the next frame boundary. So, one or the other is going to sleep for a while. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Sat Jul 2 19:11:02 1994 Message-Id: <9407030210.AA24898@surreal.asd.sgi.com> To: info-performer Subject: SIGGRAPH stuff Date: Sat, 02 Jul 94 19:10:54 -0700 From: Jim Helman There's a lot of Performer-related goings on at SIGGRAPH this year. Just to let you know about a few of the things: Course: The Performer team is giving a course at SIGGRAPH (Wednesday, full day). The course is on designing real-time graphics systems (software and content) for high-end entertainment systems such as theme parks and location-based entertainment. Although the course is not on Performer per se, it does provide some good information on database tuning and rendering tricks. The syllabus is attached below. Paper: And anyone wanting to know more about the architecture and internals of Performer should check out the paper on Friday afternoon: "IRIS Performer: A High-Performance, Multiprocessing Toolkit for Real-Time 3D Graphics." Exhibits, VROOM, etc: In addition, there will be various demos in the SGI booth, several Performer-based applications in the CAVE in VROOM, and a couple simply awesome interactive experiences running on Performer, both at SIGGRAPH and nearby. More on those later. We were also thinking of having a small(?) get together if there's interest. rgds, -jim jimh@surreal.asd.sgi.com 415/390-1151 Course Outline: Designing Real-Time Graphics for Entertainment SIGGRAPH `94 Course #14 Chair: Jim Helman Silicon Graphics Abstract Using examples from actual games, theme attractions, graphics hardware and software toolkits, this course reviews real-time graphics in the design and construction of leading-edge theme park and location-based entertainment systems. The focus is on graphics from hardware through artistic content. The course has two components. The first part covers the methods available to make the best use of current workstation-level graphics technology for high-quality, real-time renderings. The topics include hardware and software architectures, multiprocessing, graphics optimization, database tuning and tricks of the trade from visual simulation. In the second part, the developers of actual systems discuss the use of those techniques as one component in constructing complete location-based or theme park entertainment systems. The topics covered include tools and methods for content generation, software frameworks, audio generation, motion-platform operation, and game design. Presentations: 1. Architecture and Performance of Entertainment Systems 1-1 Jim Helman 1. Introduction 1-1 2. What's New 1-2 3. Platform Hardware and Software 1-5 4. Artistic Content 1-11 5. The Director 1-15 6. Conclusions 1-15 A. Performance Requirements and Human Factors 1-19 2. Lessons Learned from Visual Simulation 2-1 Michael Jones 1. Low-Latency Image Generation 2-1 2. Consistent Frame Rates 2-6 3. Rich Scene Content - Cheap Implementation 2-8 4. Billboard Objects 2-12 5. Animation Sequences 2-13 6. Antialiasing 2-14 3. Multiprocessed Entertainment 3-1 John Rohlf 1. Introduction 3-1 2. What is MP good for? 3-2 3. Design Issues 3-6 4. Implementation Issues 3-10 5. Do It Yourself? 3-12 6. Conclusions 3-12 4. Optimization for Real-Time Entertainment Applications 4-1 Sharon Fischler 1. Introduction 4-1 2. Multiprocessing in Graphics Subsystems 4-5 3. Performance Issues in Graphics Pipelines 4-7 4. Optimizing Performance of a Graphics Pipeline 4-13 5. Database Tuning 4-14 6. Run-Time Diagnostics and Load Management 4-14 7. Tuning Tools 4-14 5. Creating Compelling Real-Time Content 5-1 Michael Limber 1. Introduction 5-1 2. Historical Background 5-3 3. New Opportunities 5-4 4. New Technology Developments 5-5 5. The Necessary Skills 5-6 6. Real-Time Content Production 5-7 7. Angel Studios Background 5-8 8. Human Resources Breakdown 5-10 9. The Software Application 5-13 10. Conclusion 5-16 11. Figures 5-17 6. Sound, Sight and Motion for Real-Time VR Experiences 6-1 Bernard Crowe 1. Slides 6-1 7. High Quality Computer Graphics in Entertainment 7-1 Eric Johnston 1. What we do 7-1 2. Why we do it 7-2 3. How we do it 7-3 4. Figures 7-9 Reprints: 8. IRIS Performer: A High Performance Multiprocessing 8-1 Toolkit for Real-Time 3D Graphics John Rohlf and James Helman 9. The Silicon Graphics 4D/240GTX Superworkstation 9-1 Kurt Akeley 10. Using a Position History-Based Protocol 10-1 for Distributed Object Visualization Sandeep K. Singhal and David R. Cheriton 11. Interactive and Exact Collision Detection 11-1 for Large-Scaled Environments Jonathan D. Cohen, Dinesh Manocha, Ming C. Lin and Madhav K. Ponamgi Speakers JIM HELMAN works in Silicon Graphics' Advanced Graphics Division as a member of the engineering team for IRIS Performer, SGI's real-time graphics toolkit. Before coming to SGI, he was a student in the Applied Physics department at Stanford University where he worked on his PhD in data visualization. His interests include virtual environments, game design, and keeping keeping large green cars running. Email: jimh@sgi.com MICHAEL JONES works in Silicon Graphics' Advanced Graphics Division where he manages the IRIS Performer engineering team. He has worked with high-performance visual simulation systems for the last 5 years Prior to joining Silicon Graphics, he worked in diverse areas, including high-performance visual simulation, color conversion of monochrome films and serials, optimization o f cellular-telephone antenna placement, and the nationwide routing of delivery trucks. He has ben a professional computer programmer since the seventh grade. His personal interests include work and sleep. Email: mtj@sgi.com JOHN ROHLF works in Silicon Graphics' Advanced Graphics Division and is the main architect of IRIS Performer having designed and written the multiprocessing and rendering core of the toolkit. Before coming to SGI he worked on architectural walkthroughs at the University of North Carolina. where he received his Masters in Computer Science. He is also a torquehead with an affection for small block V8's. Email: jrohlf@sgi.com SHARON FISCHLER is a member of the IRIS Performer engineering team in the Advanced Graphics Division at Silicon Graphics where she specializes in performance issues for system implementation and real-time graphics applications. She was a member of the original design team, and before that, was a member of the Graphics Software group where she worked on the development team for the VGX graphics platform. Her interests, besides a real need for speed, include user interfaces, plants and fish (simulated and real). She studied using natural language in graphical user interfaces at the University of California at Santa Cruz where she received her Masters degree in Computer Science. Her Bachelors degree is in Mathematics and Linguistics from the University of California at Berkeley. Email: srf@sgi.com The first four speakers can be reached at: Silicon Graphics Advanced Graphics Division 2011 N. Shoreline Blvd. MS 8U-590 Mountain View, CA 94043 USA FAX: (415) 965-2658 BERNARD CROWE is Vice President of the Commercial Sector of GreyStone Technology, Inc. where he is responsible for developments in simulation, virtual reality, advanced visualizaion, and intelligent systems modeling applied to a variety of applications in the healthcare, transportation, communications and entertainment markets. He was formerly Vice President, Systems Development at Ball Systems Engineering Division, a subsidiary of Ball Corporation, where his responsibilities included development of an advanced image generator computer. Until 1989, he headed the Simulation Products group at Tracor Flight Systems, Santa Ana, CA, founding the artificial intelligence department. He graduated from London University, England, in 1961 with a degree in Aeronautical Engineering, and emigrated to the United States after serving in the Advanced Projects Department of Hawker-Siddelely Dynamics and in the Fluid Dynamics Laboratory of Salford University. GreyStone Technologies Email: gds@charm.isi.edu 15010 Ave of Science St., Suite 200 Phone: (619) 675-7800 San Diego, CA 92128 FAX: (619) 675-7808 MICHAEL LIMBER is a partner at Angel Studios and serves as its Production Director. He has a degree in Architecture from U.C. Berkeley and a Masters in Industrial Design from Pratt Institute. His professional computer graphics career began in 1985 after getting a job at Digital Productions in Los Angeles. Beginning as a modeler and progressing to the position of Technical Director, Michael spent two intense years at the trailblazing computer graphics company, using a Cray XMP and state-of-the-art proprietary software to create commercials, film effects, visualizations, and music videos. After serving as Head Animator at the fully digital Post Perfect, in 1989, he moved to San Diego to work as Director of Computer Animation at Angel Studios with another Digital Productions veteran and colleague, Brad Hunt. Michael worked as Animator and Technical Director on "The Lawnmower Man" and Peter Gabriel's MindBlender, among a multitude of other unique projects. Since that time, Michael and his partners, Diego Angel, Harry Benham, and Jill and Brad Hunt, have endeavored to make Angel Studios a strong producer of extraordinary 3D computer animation, and a pioneering developer of compelling real-time interactive applications and content. Angel Studios Email: michael@angel.com 5962 La Place Courte, Suite 100 Phone: (619) 929-0700 Carlsbad, CA 92008 FAX: (619) 929-0719 ERIC JOHNSTON is the manager and lead engineer of the virtual reality group at Spectrum HoloByte, one of the worlds leading computer game companies. In addition to having worked in the NASA Ames Virtual Environments Lab, Eric has written over twelve published Macintosh games. His credits include Pipe Dream and Indiana Jones and Fate of Atlantis, LucasArts Entertainment, as well as Putt-Putt Joins the Parade and other children's games from Humongous Entertainment. Eric holds a B.S. in electrical engineering and computer science from U.C. Berkeley. Spectrum Holobyte Email: ericj@netcom.com 2490 Mariner Square Loop Phone: (510) 814-3584 Alameda, CA 94501 FAX: (510) 522-3587 # # # From guest Mon Jul 4 19:39:09 1994 Mon, 4 Jul 1994 19:37:43 -0700 for <@ucsd.ucsd.edu:info-performer@sgi.com> From: prwhite@sgva-xs4.ucsd.edu (Payton White) Message-Id: <9407050237.AA04028@sgva-xs4> Subject: Need info... To: info-performer@sgi.sgi.com Date: Mon, 4 Jul 1994 19:37:29 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1108 Status: OR In a letter from Jim Helman: > Looking at the code, I'm not sure what could cause this. It may be a > bug inside libpf or some sort of an application memory stomp. I'll be > out of town for a few days. The best thing to do would be to either > open a call with the hotline or FTP a core file (from the application > compiled with -g and linked against /usr/lib/libp?-g.a) to > ftp.sgi.com:/pub. Two questions: 1) What is the hotline number? 2) What else do I have to do besides ftp'ing a core in order to get a response. Obviously a core alone won't do anybody much good in responding to my problem. Thanks, -- Visualization << SGI >> Simulation -- Payton R. White prwhite@ucsd.edu __ __ __ u27486@sdsc.edu / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From guest Mon Jul 4 20:33:09 1994 Message-Id: <9407050333.AA24601@surreal.asd.sgi.com> To: prwhite@sgva-xs4.ucsd.edu (Payton White) Cc: info-performer@sgi.sgi.com Subject: Re: Need info... In-Reply-To: Your message of "Mon, 04 Jul 94 19:37:29 -0800." <9407050237.AA04028@sgva-xs4> Date: Mon, 04 Jul 94 20:32:59 -0700 From: Jim Helman Status: OR > 1) What is the hotline number? (800) 800-4SGI. This will only work if you purchased support when you bought IRIS Performer (a good idea since you get new versions and Performer will stay on the steep side of the product evolution curve until we run out of cool ideas). >2) What else do I have to do besides ftp'ing a core in order to get > a response. Obviously a core alone won't do anybody much good > in responding to my problem. Send me and aschaffe@sgi.com email. I'm doing some graphical spelunking in Chicago, but can still check out a core file. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jul 5 07:39:10 1994 From: watsen@netcom.com (Kent Watsen) Message-Id: <199407051439.HAA05437@netcom6.netcom.com> Subject: Subface performance in Z buffer? To: info-performer@sgi.sgi.com (performer) Date: Tue, 5 Jul 1994 07:39:37 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1252 Hello all, I have a terrain database which implements some roads as subfaces to the underlying terrain polygons. I also have some buildings which when viewed such that the subfaced roads are on the far side of the building, the roads are still seen. This effect is proportional to the distance from the building the camera is located. Hence, if I am far away, the road is easily seen to be rendered in front of the building polygons, and as I move closer, the roads slowly recede and rendered correctly. This behavior suggests that subfaces in 1.2 are implemented by simply hashing the road polygons one z-buffer-bin higher then the underlying polygon, and thus rendered in front. However, at the same time, the buildings are also hashed into the same z-buffer and false rendering occur. My database is modelled in Multigen and is structured such that a tile of terrain is under a group bead. Under which, in a preorder traversal of object beads, are land (terrain w/ subfaced roads), trees, buildings). The DB is loaded by LoadFlt, so pfFlatten and pfClean are called by default. This DB rendered fine in GVS. Has anyone else experienced anything like this? Kent Watsen Watsen@netcom.com DCS Corporation Simulation Branch 703.683.8430 x369 From guest Tue Jul 5 08:21:48 1994 Date: Tue, 5 Jul 1994 11:33:46 -0400 From: zeus@cs.UMD.EDU (Hillel Steinberg) Message-Id: <199407051533.LAA28794@tove.cs.UMD.EDU> To: info-performer Subject: Dynamic text labels for objects..... Hi, I'm trying to use performer 1.0 to walkthrough a world, and I need all the entities to have dynamic words attatched to them, such as "Hello". Obviously, if the object isn't visible currently, I don't need the label to show up on top of the object. I've tried several ways to do this - but no luck. I put traversal callbacks for pre/post Draw, and when it gets to the object, I domething like: drawmode(NORMALDRAW); mapcolor(1, 255, 255, 0); gflush(); color(1); fmsetfont(fontHandle); cmov(-1.0,0.0,6.0); fmprstr("Hello"); but it doesn't work. I read the chapter on traversals, and I can see something about the draw process (this is a single process application) not having the transformation matrix, but I tried this code also in cull callbacks to no avail. What am I doing wrong, Thanxs in advance, - Hillel From guest Tue Jul 5 10:49:00 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9407051748.AA09889@tubes.asd.sgi.com> Subject: Re: Dynamic text labels for objects..... To: guest (Hillel Steinberg) Date: Tue, 5 Jul 94 10:48:18 PDT Cc: info-performer In-Reply-To: <199407051533.LAA28794@tove.cs.UMD.EDU>; from "Hillel Steinberg" at Jul 5, 94 11:33 am X-Mailer: ELM [version 2.3 PL8] > > > Hi, I'm trying to use performer 1.0 to walkthrough a world, and I need all the > entities to have dynamic words attatched to them, such as "Hello". Obviously, > if the object isn't visible currently, I don't need the label to show up on > top of the object. I've tried several ways to do this - but no luck. I put > traversal callbacks for pre/post Draw, and when it gets to the object, I > domething like: > > drawmode(NORMALDRAW); > > mapcolor(1, 255, 255, 0); > gflush(); > color(1); > fmsetfont(fontHandle); > cmov(-1.0,0.0,6.0); > > fmprstr("Hello"); > > but it doesn't work. I read the chapter on traversals, and I can see > something about the draw process (this is a single process application) > not having the transformation matrix, but I tried this code also in cull > callbacks to no avail. What am I doing wrong, > There are many other GL modes which you need to manage. Try the following: pfPushState(); pfBasicState(); /* Turn off lighting, texturing, etc */ zfunction(ZF_ALWAYS); > drawmode(NORMALDRAW); > > mapcolor(1, 255, 255, 0); > gflush(); > color(1); > fmsetfont(fontHandle); > cmov(-1.0,0.0,6.0); > > fmprstr("Hello"); zfunction(ZF_LEQUAL); pfPopState(); From guest Tue Jul 5 10:51:52 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9407051751.AA09912@tubes.asd.sgi.com> Subject: Re: Subface performance in Z buffer? To: guest (Kent Watsen) Date: Tue, 5 Jul 94 10:51:15 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <199407051439.HAA05437@netcom6.netcom.com>; from "Kent Watsen" at Jul 5, 94 7:39 am X-Mailer: ELM [version 2.3 PL8] > > > Hello all, > > I have a terrain database which implements some roads > as subfaces to the underlying terrain polygons. I > also have some buildings which when viewed such that > the subfaced roads are on the far side of the building, > the roads are still seen. This effect is proportional > to the distance from the building the camera is located. > Hence, if I am far away, the road is easily seen to be > rendered in front of the building polygons, and as I move > closer, the roads slowly recede and rendered correctly. > This behavior suggests that subfaces in 1.2 are implemented > by simply hashing the road polygons one z-buffer-bin higher > then the underlying polygon, and thus rendered in front. > However, at the same time, the buildings are also hashed > into the same z-buffer and false rendering occur. My database > is modelled in Multigen and is structured such that a tile > of terrain is under a group bead. Under which, in a preorder > traversal of object beads, are land (terrain w/ subfaced roads), > trees, buildings). The DB is loaded by LoadFlt, so pfFlatten > and pfClean are called by default. This DB rendered fine in > GVS. > This is a result of the default displacepolygon mode used by pfLayer nodes. From the pfLayer man page: The use of displacements for rendering coplanar geometry can cause visual artifacts such as decals "Z fighting" or "flimmering" when viewed perpendicularly and punching through geometry that should be in front of them when viewed obliquely. In these cases, the database should be modified to eliminate the need for coplanar rendering or PFDECAL_BASE_HIGH_QUALITY/PFDECAL_BASE_STENCIL used.