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 Status: O 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 Sun Jan 2 23:52:41 1994 Date: Mon, 3 Jan 94 19:58:30 -0800 From: shkim@sgiksg.korea.sgi.com (Sunghee Kim) Message-Id: <9401040358.AA03626@sgiksg.korea.sgi.com> To: info-performer@sgi.sgi.com Subject: unsubscribe Cc: shkim@sgiksg.korea.sgi.com Status: O unsubscribe From guest Tue Jan 4 03:04:04 1994 Date: Tue, 4 Jan 94 18:59:09 +0800 From: tchuang Message-Id: <9401041059.AA00758@cube.ep.nctu.edu.tw> To: info-performer@sgi.sgi.com Subject: unsubscribe Status: O unsubscribe From guest Thu Jan 6 09:31:13 1994 From: "Marc SIMON Presales support" Message-Id: <9401061755.ZM7241@girl.paris.sgi.com> Date: Thu, 6 Jan 1994 17:55:48 +0100 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: smoke simulation Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi all, It's not really a Performer question but i hope somebody could help me. I would like to simulate an explosion and "dynamic" smoke . I think one way will be to use texture (with alpha ) and change the projection parameters ( mmode(MTEXTURE) ) to "animate" the smoke , but i'm sure there is other ways to do that , so thanks in advance for any suggestions. Marc SIMON smarc@paris.sgi.com From guest Thu Jan 6 10:19:18 1994 Date: Thu, 6 Jan 94 09:46:13 -0800 From: ib@ivan (Ivan Bach) Message-Id: <9401061746.AA07406@ivan.asd.sgi.com> To: "Marc SIMON Presales support" , info-performer@sgi.sgi.com Subject: Re: smoke simulation Status: O > Marc SIMON writes: I would like to simulate an explosion and "dynamic" smoke. ------------------- copies of old articles ---------------------------- 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)? Status: O 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 10:25:34 1994 Message-Id: <9401061825.AA05457@surreal.asd.sgi.com> To: "Marc SIMON Presales support" Cc: info-performer@sgi.sgi.com Subject: Re: smoke simulation In-Reply-To: Your message of "Thu, 06 Jan 94 17:55:48 +0100." <9401061755.ZM7241@girl.paris.sgi.com> Date: Thu, 06 Jan 94 10:25:27 -0800 From: Jim Helman Status: O In 1.2, libpfutil will have a simple smoke simulator which uses its own point-rotate billboards and multiple, moving and spinning polygons with transparent smoke and flame textures on them. -jim From guest Thu Jan 6 11:23:26 1994 Message-Id: <9401061924.AA08756@Crazypete.AI.SRI.COM> To: "Marc SIMON Presales support" Cc: info-performer@sgi.sgi.com Subject: Re: smoke simulation In-Reply-To: Your message of "Thu, 06 Jan 1994 17:55:48 +0100." <9401061755.ZM7241@girl.paris.sgi.com> Date: Thu, 06 Jan 1994 11:24:36 -0800 From: Stephen Lau Status: O Some people from the Naval Postgraduate School have done some 3-D textures for animating smoke that looks pretty good. It's not "photo-realistic" but it get's the message across and is inexpensive in terms of rendering and CPU time. I can put you in touch with them if you want. 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 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 Status: O 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 Status: O 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 11:54:43 1994 Date: Thu, 6 Jan 94 13:50:27 CST From: reedwhit@skips.dseg.ti.com (Reed Whittington) Message-Id: <9401061950.AA20743@skips.dseg.ti.com> To: iris-performer@sgi.sgi.com Subject: perf-REACT Status: O In an effort to achieve a steady frame rate. I have been using some of the REACT features to isolate/restrict processors and run processes at non degrading priorities. I adapted the sample code from 'procsetup.c'. Every thing works fine except when I run my application with multiple pfPipes. The system hangs. I went back and tryed running perfly under root with multiple pfPipes. This also hangs the system. What could be happening? I suspect the problem is with two or more nondegrading processes runing on the same processor at the same priority. If this is true what is the best way to distribute the processes in and with what priority. My environment: Performer 1.2b72, Onyx(4 CPUs) - RE2(2 pipes) pipe0(4RM,mco) pipe1(2RM) My current application uses two pfPipes on one RE2 pipe and one pfPipe on the other. Every process is forked, so I have 8 processes. cpu-1 | cpu-2 | cpu-3 |---Cull_1---Draw_1 |--> pipe1 App ----| | |---Cull_2---Draw_2 | | | |--> pipe2 | |---Cull_3---Draw_3 | | Isect Thanks in advance. --Reed ******************************** Reed Whittington Texas Instruments Visual Simulation Technology Development reedwhit@dseg.ti.com ******************************** From guest Thu Jan 6 13:54:56 1994 Date: Thu, 6 Jan 94 13:56:13 -0800 From: covingto@gravy3.cs.nps.navy.mil (james covington) Message-Id: <9401062156.AA19023@gravy3.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: request to be added Status: O Dear Sirs: Please add me to your mailing list. Thank you. LT James Covington Naval Postgraduate School Monterey CA 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: O 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 Status: O 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 00:32:35 1994 From: "knut" Message-Id: <9401070905.ZM1944@knut.oslo.sgi.com> Date: Fri, 7 Jan 1994 09:05:58 +0100 X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: info-performer@sgi.sgi.com Subject: Questions RE> Performer Cc: knut@knut.oslo.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I have a number of short questions. I'd be happy if someone could point me in the right directions on these matters.: HW : Onyx RE^2 SW : Performer 1.2a55, IRIX 5.1.1.2 1. Textures on polygon on another polygon ... ============================================= The scene is created using MultiGen. It seems like performer has some problems regarding rendring of "double polygons". As when you have a house wall with window on. These windows are texture mapped. If you move perpendicular with regards to the window performer tart flickering between draing the window and drawing the plain wall. If you have an angle it's ok. For me as an old gl programmer. It seems like performer has problems giving the window a correct z-buffer value. ( since it changes when you move your eye posision away from the polygons normal line) 2. Yello road line gets blurred ================================== We are using road textures to produce a good looking road with a yellow middle line. the problem is that these textures gets blurred in perfromer. They look ok in Multigen but not in Preformer. It seems like some information regarding how the texture is supposed to be mapped onto the polygon is lost when moving from multigen to Performer. 3. Intesity Alpha textures ============================== In multigen -- works ok (i.e. using the whole intensity range) In perfromer -- does not work correctly ( look ditherd ) 4. Textures sometimes vanishes for short while: ================================================ This is probably the strangest problem. If you drive a long a textured road. On certain spotsparts of the road dissappears. My customer has installed a MCO option aswell as a normal screen. If we run the application using MCO and three channels, the texure can dissappear in one of the cannels but not in the others. 5. Releases =========== Maybe problems 1-4 are bugs in Performer .... What is the current release of Performer ? When is a MR version of perforemer 1.2 ready ? If someone can take the time to read this an d help me I'd be "over-happy"!! Thanks and best regards Knut Ivar Foshaug -- ********************************************************************** | Knut Ivar Foshaug | Customer Support | | | Silicon Graphics AS | | | | Engebretsv.3 | knut@oslo.sgi.com | | | N-0275 OSLO | Phone: +47 22 73 20 15 | VoiceMail: 8930 | | Norway | Fax: +47 22 73 22 11 | Mail-Stop: NO-335 | ********************************************************************** 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 Status: O > > 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> Status: O 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 Fri Jan 7 13:03:23 1994 Message-Id: <9401072103.AA14558@surreal.asd.sgi.com> To: "knut" Cc: info-performer@sgi.sgi.com Subject: Re: Questions RE> Performer In-Reply-To: Your message of "Fri, 07 Jan 94 09:05:58 +0100." <9401070905.ZM1944@knut.oslo.sgi.com> Date: Fri, 07 Jan 94 13:03:01 -0800 From: Jim Helman Status: O | | 1. Textures on polygon on another polygon ... | ============================================= | The scene is created using MultiGen. It seems like performer has some | problems regarding rendring of "double polygons". As when you have a house | wall with window on. These windows are texture mapped. | | If you move perpendicular with regards to the window performer tart | flickering between draing the window and drawing the plain wall. | | If you have an angle it's ok. | | For me as an old gl programmer. It seems like performer has problems | giving the window a correct z-buffer value. ( since it changes when you | move your eye posision away from the polygons normal line) You can handle nearly-co-planar polygons with a Z-offset in the model, but will probably run into z-buffer resolution problems at large ranges. Performer supports pfLayer for defining a base polygon and a set of decals to be rendered on top of it. 1.0/1.1 uses stencil for this (render base polygons setting stencil, render decal polygon testing for stencil). This does a perfect job, but stenciling significantly reduces pixel-fill rates both for the base and decal polygons. So 1.2 adds layering based on displacepolygon. This is a lot faster, but can cause artifacts. If you model using "subfaces" in Multigen, the LoadFlt() should convert them to pfLayer's for rendering. | 2. Yello road line gets blurred | ================================== | We are using road textures to produce a good looking road with a yellow | middle line. | | the problem is that these textures gets blurred in perfromer. They look ok | in Multigen but not in Preformer. | | It seems like some information regarding how the texture is supposed to be | mapped onto the polygon is lost when moving from multigen to Performer. You are seeing mipmapping in action. To avoid aliasing and texture scintillation, the graphics hardware selects a subsampled version of the texture based on the sizez relationship between screen pixels and texels projected onto the screen. Mipmapping subsamples by a factor of two in *both* u and v. When you view a square texture very obliquely, as when looking down a road, the graphics hardware has to choose whether to go to a fuzzy version of the image because the texels are densely squished (minified) onto the screen along the road or use a sharp version based on the spread out texels across the road. Since the latter would cause scintallation along the road, the hardware does the former and selects the fuzzier copy. If the road is mainly viewed along it, as when driving. The solution is to make the aspect ratio of the texture image match the *typical* aspect ratio it has when projected onto the screen, e.g. make the texture image 512 pixels wide (across the road) but only 64 pixels long (along the road). This will look great along the road, but fuzzy when the road is viewed perpendicularly. This is how the Performer town/village demos handle the issue. | 3. Intesity Alpha textures | ============================== | In multigen -- works ok (i.e. using the whole intensity range) | | In perfromer -- does not work correctly ( look ditherd ) You are not seeing dithering, but color quantization. For full speed texturing, Performer uses 16bit texels. RGB textures: (R,G,B) (5bits, 6bits, 5bits) RGBA textures: (R,G,B,A) (4bits, 4bits, 4bits, 4bits) If you call pfTexFormat(tex, PFTEX_INTERNAL_FORMAT, TX_RGBA8), you'll get 32bit texels, but pixel-fill will run at half speed for those textures. | 4. Textures sometimes vanishes for short while: | ================================================ | This is probably the strangest problem. If you drive a long a textured | road. On certain spotsparts of the road dissappears. | | My customer has installed a MCO option aswell as a normal screen. If we | run the application using MCO and three channels, the texure can | dissappear in one of the cannels but not in the others. Strange. Maybe someone else has an idea. | 5. Releases | =========== | | Maybe problems 1-4 are bugs in Performer .... 1-3 are not. Don't know about 4. | What is the current release of Performer ? 1.1 for 5.X and 1.0 for 4.0.5. From guest Fri Jan 7 18:47:05 1994 Date: Fri, 7 Jan 94 18:48:23 -0800 From: covingto@elsie.cs.nps.navy.mil (james covington) Message-Id: <9401080248.AA06640@elsie.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: Performer and OSF/Motif Status: O I have reviewed Wade Olsen's sample program which shows how to run Performer inside a Motif application. However when I tried to modify a larger existing Performer application (one which used the standard winopen() call in the pfInitfunc) to run in this manner, I received GL error #114 (ERR_NOGRAPHICS) when I called the GLXlink function. Can you help explain what causes error #114, and what I could possibly do to avoid it? Thanks, James Covington Naval Postgraduate School Monterey CA From guest Sat Jan 8 04:20:48 1994 Date: Sat, 8 Jan 94 04:20:38 -0800 From: ib@ivan (Ivan Bach) Message-Id: <9401081220.AA12665@ivan.asd.sgi.com> To: covingto@elsie.cs.nps.navy.mil (james covington), info-performer@sgi.sgi.com Subject: Re: Performer and OSF/Motif Status: O You should always specify which versions of software you are using when you report a software problem. I will assume that you are using some version of IRIX 4. Motif is just a toolkit that makes it easier to write X programs. You seem to be trying to mix GL and X. If that is what you want to do, you need to write a mixed-model program that calls routines such as: GLXgetconfig GLXwinset GLXlink GLXunlink Please read the man pages for these routines. In the man page for GLXwinset(3G), it says: ------------------------------------------------------------------------- All of the GL routines which access window system controlled features are illegal to call for a mixed model window. Not all of these routines report errors, so here is a list of the routines which mixed model programs cannot call. qdevice, qread, qtest, qenter, getbutton, getvaluator, setvaluator, noise, unqdevice, mapcolor, getmcolor, gconfig, doubelbuffer, singlebuffer, RGBmode, cimode, overlay, underlay, acsize, curstype, defcursor, setcursor, winopen, wintitle, winposition, winmove, foreground, noborder, noport, iconsize, icontitle, keepaspect, maxsize, minsize, step, fudge, prefposition, prefsize The following routines will work, but execute much slower for mixed model windows, and this information should be obtained from the window system if at all possible. Avoid these routines. getsize, getorigin, reshapeviewport, getviewport ------------------------------------------------------------------------- If your program is a mixed-model program, it should not call winopen. Please install 4Dgifts (sample programs from SGI), and look at the sample programs in the directory: /usr/people/4Dgifts/examples/GLX Basically, your program can open a window, and bind it to GL. Once a window is bound to GL, it becomes a mixed-model window, and you can use only GL routines to draw in that window. If you try to use X routines to draw in that window, the results are undefined. Mixed-model programming is also explained in the "Transition Guide: Programming Environment." Please check whether you are linking your program with a shared (libgl_s, -lgl_s) or unshared (libgl, -lgl) version of the graphics library. Only the shared version can do distributed or remote GL (dgl). Enter: printenv or: echo $DISPLAY to check the setting of your environment variable DISPLAY. If DISPLAY points to a remote machine (not set to :0), or if your machine is a gateway and has two entries in the host table (bug in dgl), you can get the error message you reported. Ivan Bach, ib@asd.sgi.com 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 Status: O 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 Sun Jan 9 18:49:18 1994 From: "Sharon Fischler" Message-Id: <9401091849.ZM3737@rose.asd.sgi.com> Date: Sun, 9 Jan 1994 18:49:11 -0800 In-Reply-To: covingto@elsie.cs.nps.navy.mil (james covington) "Performer and OSF/Motif" (Jan 7, 6:48pm) References: <9401080248.AA06640@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 OSF/Motif Cc: wade@rose Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O +>---- On Jan 7, 6:48pm, james covington wrote: > Subject: Performer and OSF/Motif ->I have reviewed Wade Olsen's sample program which shows how to run Performer ->inside a Motif application. However when I tried to modify a larger existing ->Performer application (one which used the standard winopen() call in the ->pfInitfunc) to run in this manner, I received GL error #114 (ERR_NOGRAPHICS) ->when I called the GLXlink function. Can you help explain what causes error ->#114, and what I could possibly do to avoid it? Are you sure that you get this error from GLXlink or did it come from code initializing the GL window? Anyway, you do want to be sure to call pfInitGLXGfx() instead of pfInitGfx() since you are doing a GLX window. Wade can comment on hints for adapting his code. However, Performer does support running a program under GLX. There are a couple of sample programs that demonstrate this in /usr/src/Performer/src/pguide/libpf/progs complex-glx.c - a most minimal roll-your-own glx example utilui.c - uses utilities in libpfutil for setting up a GLX window and also for doing X input handling asynchronously in a separate process. You can also look at /usr/src/Performer/src/lib/libpfutil/xwin.c to see how we set up GLX windows and call GLXlink.\ Look at the routine pfuGLXCreateWindow(). for even more glx exapmles, you can look in /usr/people/4Dgifts/examples/GLX/{gl-Xlib,glxwidget} srf. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Mon Jan 10 08:55:59 1994 Date: Mon, 10 Jan 94 11:58:05 EST From: fyock@capella.tsc.gtefsd.com (Christina Fyock) Message-Id: <9401101658.AA04134@capella.tsc.gtefsd.com> Organization: GTE Federal Systems Division / TSC To: info-performer@sgi.sgi.com Subject: Software Releases Status: O When IRIX 5.1 is released, OpenGL will be released also. Will the next release of performer use OpenGL instead of GL? Christina From guest Mon Jan 10 09:23:40 1994 From: "Michael Jones" Message-Id: <9401100923.ZM9684@babar.asd.sgi.com> Date: Mon, 10 Jan 1994 09:23:33 -0800 In-Reply-To: fyock@capella.tsc.gtefsd.com (Christina Fyock) "Software Releases" (Jan 10, 11:58am) References: <9401101658.AA04134@capella.tsc.gtefsd.com> X-Mailer: Z-Mail (3.0B.1 08dec93 MediaMail) To: fyock@capella.tsc.gtefsd.com (Christina Fyock), info-performer@sgi.sgi.com Subject: Re: Software Releases Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jan 10, 11:58am, Christina Fyock wrote: > Subject: Software Releases : :When IRIX 5.1 is released, OpenGL will be released also. Will the next release :of performer use OpenGL instead of GL? No. The next release is based on IrisGL. The subsequent release will be based on OpenGL. The current plan is to support both IrisGL and OpenGL in the first OpenGL release (by providing two sets of libraries). Here's a question. How anxious are you for an OpenGL IRIS Performer? -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Jan 10 10:56:53 1994 Date: Mon, 10 Jan 94 10:55:28 -0800 From: jrohlf@tubes (John Rohlf) Message-Id: <9401101855.AA10163@tubes.asd.sgi.com> To: Jim Helman , "knut" Subject: Re: Questions RE> Performer Cc: info-performer@sgi.sgi.com Status: O >| 3. Intesity Alpha textures >| ============================== >| In multigen -- works ok (i.e. using the whole intensity range) >| >| In perfromer -- does not work correctly ( look ditherd ) > >You are not seeing dithering, but color quantization. >For full speed texturing, Performer uses 16bit texels. > > RGB textures: (R,G,B) (5bits, 6bits, 5bits) > RGBA textures: (R,G,B,A) (4bits, 4bits, 4bits, 4bits) > >If you call pfTexFormat(tex, PFTEX_INTERNAL_FORMAT, TX_RGBA8), >you'll get 32bit texels, but pixel-fill will run at half speed >for those textures. The "dithered" look may be a result of using screen-door transparency which Performer uses on multisample-capable Onyxes. In this case you will only get a maximum of 16 transparency levels rather than 256 but performance will be much better. If you want smooth transparency you have to use the PFTR_HIGH_QUALITY token. >| 4. Textures sometimes vanishes for short while: >| ================================================ >| This is probably the strangest problem. If you drive a long a textured >| road. On certain spotsparts of the road dissappears. >| >| My customer has installed a MCO option aswell as a normal screen. If we >| run the application using MCO and three channels, the texure can >| dissappear in one of the cannels but not in the others. > >Strange. Maybe someone else has an idea. An older IRIX release had a bug where a specific mipmap level would drop out. What release are you running? From guest Mon Jan 10 11:56:48 1994 Date: Mon, 10 Jan 94 11:46:54 -0800 From: covingto@gravy5.cs.nps.navy.mil (james covington) Message-Id: <9401101946.AA15285@gravy5.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: Performer and OSF/Motif Status: O Last week I wrote: ->I have reviewed Wade Olsen's sample program which shows how to run Performer ->inside a Motif application. However when I tried to modify a larger existing ->Performer application (one which used the standard winopen() call in the ->pfInitfunc) to run in this manner, I received GL error #114 (ERR_NOGRAPHICS) ->when I called the GLXlink function. Can you help explain what causes error ->#114, and what I could possibly do to avoid it? I want to thank you for the EXTREMELY fast response to my last posting on this subject. I sent the mail late on Friday, and really didn't expect any reply before the beginning of the week. Your suggestions were very helpful, and I am still working on the problem. At this point, I have taken a step backward and simply compiled Wade Olsen's sample program with my original makefile and include files. When I ran the program, it ran "successfully," but generated the error message: ERROR #4 ortho2: ERR_BADWINDOW twice, once when I called pfConfig, and again when I called XtRealizeWidget. Can you tell me what conditions generate this error? I am running Performer 1.0 and Motif 1.1 on an IRIS 4D/440 Reality Engine with IRIX 4.0.5G. Thanks. James Covington LT USN Naval Postgraduate School Monterey CA From guest Mon Jan 10 15:13:47 1994 From: "Sharon Fischler" Message-Id: <9401101252.ZM6238@rose.asd.sgi.com> Date: Mon, 10 Jan 1994 12:52:03 -0800 In-Reply-To: covingto@gravy5.cs.nps.navy.mil (james covington) "Performer and OSF/Motif" (Jan 10, 11:46am) References: <9401101946.AA15285@gravy5.cs.nps.navy.mil> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: covingto@gravy5.cs.nps.navy.mil (james covington), info-performer@sgi.sgi.com Subject: Re: Performer and OSF/Motif Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O +>---- On Jan 10, 11:46am, james covington wrote: > Subject: Performer and OSF/Motif ->Last week I wrote: -> ->->I have reviewed Wade Olsen's sample program which shows how to run Performer ->->inside a Motif application. However when I tried to modify a larger existing ->->Performer application (one which used the standard winopen() call in the ->->pfInitfunc) to run in this manner, I received GL error #114 (ERR_NOGRAPHICS) ->->when I called the GLXlink function. Can you help explain what causes error ->->#114, and what I could possibly do to avoid it? -> -> I want to thank you for the EXTREMELY fast response to my last posting ->on this subject. I sent the mail late on Friday, and really didn't expect ->any reply before the beginning of the week. -> -> Your suggestions were very helpful, and I am still working on the problem. -> -> At this point, I have taken a step backward and simply compiled Wade Olsen's ->sample program with my original makefile and include files. When I ran the ->program, it ran "successfully," but generated the error message: -> -> ERROR #4 ortho2: ERR_BADWINDOW This often means ortho() was sent some impossible arguments. You could try using gldebug() to see what commands and values are being sent to the graphics pipeline. -> -> twice, once when I called pfConfig, and again when I called XtRealizeWidget. ->Can you tell me what conditions generate this error? -> -> I am running Performer 1.0 and Motif 1.1 on an IRIS 4D/440 Reality Engine ->with IRIX 4.0.5G. Thanks. Performer 1.2 supports running under GLX (and thus motif) very well. Please forgive my previous mail that described 1.2. You can certainly make GLX work in Performer 1.0/1.1, but it takes a bit more work on your part. srf. FYI: this is a 1.0/1.1 compatible complex-glx.c /* * complex-glx.c * * IRIS Performer example using mixed model (GLX) and * cull and draw process callbacks. Mouse and * keyboard input are read through X in the application * process to reduce overhead in the draw process. * Also demonstrates use of overlay planes with GLX. * * $Revision: 1.1 $ * $Date: 93/07/13 08:18:11 $ * * Run-time controls: * ESC-key: exits * F1-key: profile * Left-mouse: advance * Middle-mouse: stop * Right-mouse: retreat */ #include #include #include #include #include #include #include "pf.h" #include "pfflt.h" #include "pfsgi.h" static void CullChannel(pfChannel *chan, void *data); static void DrawChannel(pfChannel *chan, void *data); static void OpenPipeline(pfPipe *p); static void DrawOverlay(void); static void UpdateView(void); static void GetXInput(void); static void usage(void); #define HISPEED 0.1f #define LOSPEED 0.001f /* * structure that resides in shared memory so that the * application, cull, and draw processes can access it. */ typedef struct { long exitFlag; long inWindow; float mouseX; float mouseY; long mouseButtons; long winOriginX; long winOriginY; long winSizeX; long winSizeY; pfCoord view; float sceneSize; int drawStats; Window xWin; Window glWin; Window overWin; long redrawOverlay; } SharedData; static SharedData *Shared; /* * X Display for opening window and input. In MP mode, each * process separately opens the display. */ static Display *XDpy = NULL; /* light source created and updated in draw-process */ static pfLight *Sun; /* * main() -- program entry point. this procedure * is executed in the application process. */ int main (int argc, char *argv[]) { int arg; int found; pfNode *root; pfChannel *chan; pfScene *scene; pfPipe *p; pfEarthSky *eSky; pfBox bbox; pfCoord view; float far = 10000.0f; if (argc < 2) usage(); pfInit(); pfMultiprocess(PFMP_APPCULLDRAW); /* allocate shared before fork()'ing parallel processes */ Shared = (SharedData*)pfMalloc(sizeof(SharedData), pfGetSharedArena()); Shared->inWindow = 0; Shared->exitFlag = 0; Shared->drawStats = 0; Shared->redrawOverlay = 1; /* initiate multi-processing mode set in pfMultiprocess call */ pfConfig(); scene = pfNewScene(); /* specify directories where geometry and textures exist */ if (pfGetFilePath() == NULL) pfFilePath( "." ":./data" ":../data" ":../../data" ":/usr/src/Performer/data" ); /* load database files named by command line arguments */ for (arg = 1, found = 0; arg < argc; arg++) { if ((root = (pfNode *)LoadFlt(argv[arg])) != NULL) { pfAddChild(scene, root); found++; } } /* if no files successfully loaded, terminate program */ if (!found) usage(); /* determine extent of scene's geometry */ pfGetNodeBBox(scene, &bbox, NULL); p = pfGetPipe(0); pfPhase(PFPHASE_FLOAT); /* Open and configure full screen GL window. */ pfInitPipe(p, OpenPipeline); pfFrameRate(20.0f); chan = pfNewChan(p); pfChanCullFunc(chan, CullChannel); pfChanDrawFunc(chan, DrawChannel); pfChanScene(chan, scene); pfChanNearFar(chan, 0.1f, far); /* Create an earth/sky model that draws sky/ground/horizon */ eSky = pfNewESky(); pfESkyMode(eSky, PFES_BUFFER_CLEAR, PFES_SKY_GRND); pfESkyAttr(eSky, PFES_GRND_HT, -10.0f); pfChanESky(chan, eSky); /* vertical FOV is matched to window aspect ratio */ pfChanFOV(chan, 45.0f, -1.0f); { float sceneSize; /* Set initial view to be "in front" of scene */ /* view point at center of bbox */ pfAddVec3(Shared->view.xyz, bbox.min, bbox.max); pfScaleVec3(Shared->view.xyz, 0.5f, view.xyz); /* find max dimension */ sceneSize = bbox.max[PF_X] - bbox.min[PF_X]; sceneSize = PF_MAX2(sceneSize, bbox.max[PF_Y] - bbox.min[PF_Y]); sceneSize = PF_MAX2(sceneSize, bbox.max[PF_Z] - bbox.min[PF_Z]); sceneSize = PF_MIN2(sceneSize, 0.5f * far); Shared->sceneSize = sceneSize; /* offset so all is visible */ Shared->view.xyz[PF_Y] -= sceneSize; Shared->view.xyz[PF_Z] += 0.25f*sceneSize; pfSetVec3(Shared->view.hpr, 0.0f, 0.0f, 0.0f); pfChanView(chan, Shared->view.xyz, Shared->view.hpr); } /* main simulation loop */ while (!Shared->exitFlag) { /* wait until next frame boundary */ pfSync(); /* Set view parameters. */ UpdateView(); pfChanView(chan, Shared->view.xyz, Shared->view.hpr); /* initiate traversal using current state */ pfFrame(); /* Check the mouse and keyboard */ GetXInput(); } /* terminate cull and draw processes (if they exist) */ pfExit(); /* exit to operating system */ exit(0); } /* * UpdateView() updates the eyepoint based on the information * placed in shared memory by GetXInput(). */ static void UpdateView(void) { static float speed = 0.0f; static float speedLimit = 4.0f; pfCoord *view = &Shared->view; float cp; if (!Shared->inWindow) { speed = 0; return; } switch (Shared->mouseButtons) { case Button1Mask: /* LEFTMOUSE: faster forward or slower backward*/ if (speed > 0.0f) speed *= 1.2f; else speed /= 1.2f; if (PF_ABSLT(speed, LOSPEED * Shared->sceneSize)) speed = LOSPEED * Shared->sceneSize; else if (speed >= HISPEED * Shared->sceneSize) speed = HISPEED * Shared->sceneSize; break; case Button2Mask: /* MIDDLEMOUSE: stop moving and pick */ speed = 0.0f; break; case Button3Mask: /* RIGHTMOUSE: faster backward or slower foreward*/ if (speed < 0.0f) speed *= 1.2f; else speed /= 1.2f; if (PF_ABSLT(speed, LOSPEED * Shared->sceneSize)) speed = -LOSPEED * Shared->sceneSize; else if (speed <= -HISPEED * Shared->sceneSize) speed = -HISPEED * Shared->sceneSize; break; } /* update view direction */ view->hpr[PF_H] -= Shared->mouseX * PF_ABS(Shared->mouseX); view->hpr[PF_P] = Shared->mouseY * PF_ABS(Shared->mouseY) * 90.0f; view->hpr[PF_R] = 0.0f; /* update view position */ cp = cosf(PF_DEG2RAD(view->hpr[PF_P])); view->xyz[PF_X] += speed*sinf(-PF_DEG2RAD(view->hpr[PF_H])*cp); view->xyz[PF_Y] += speed*cosf(-PF_DEG2RAD(view->hpr[PF_H])*cp); view->xyz[PF_Z] += speed*sinf( PF_DEG2RAD(view->hpr[PF_P])); } /* * In Performer1.2: use pfInitGLXGfx() so that * windows can be automatically repositioned and * resized as needed. */ void InitGLXGfx(pfPipe *_pipe, ulong _xwin, ulong _glwin, ulong _overwin) { long zmin, zmax; zmin = getgdesc(GD_ZMIN); zmax = getgdesc(GD_ZMAX); lsetdepth(zmin, zmax); zbuffer(TRUE); subpixel(TRUE); mmode(MVIEWING); cpack(0); clear(); zclear(); swapbuffers(); clear(); zclear(); /* XXX do the "right" thing here or in your own app */ pfEnable(PFEN_TEXTURE); /* * Apply default TV_MODULATE environment so geostates can inherit * for better performance. */ pfApplyTEnv(pfNewTEnv(pfGetSharedArena())); } /* * Prototypes for GLX utility code from * /usr/people/4DGifts/examples/GLX/gl-Xlib/glxh2.c * which appears at the end of this file */ ulong GLXgetvalue(GLXconfig* conf, int buffer, int mode); GLXconfig* GLXCreateWindow(Display* dpy,Window parent, int x,int y, int w,int h, int borderWidth, ...); /* * OpenPipeline() -- create a pipeline: setup the window system, * the IRIS GL, and IRIS Performer. this procedure is executed in * the draw process (when there is a separate draw process). */ static void OpenPipeline(pfPipe *p) { float xSize = 800; float ySize = 500; XSetWindowAttributes swa; XColor gray; GLXconfig *config; if (XDpy == NULL) { XDpy = XOpenDisplay(":0.0"); if (!XDpy) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "OpenPipeline: couldn't open display\n"); } /* * First create the top level X window. The background will be * grey, and the window is only interested in key press events. */ gray.red = 0x7fff; gray.green = 0x7fff; gray.blue = 0x7fff; XAllocColor(XDpy, DefaultColormap(XDpy, DefaultScreen(XDpy)), &gray); swa.background_pixel = gray.pixel; Shared->xWin = XCreateWindow(XDpy, RootWindow(XDpy, DefaultScreen(XDpy)), 100, 100, xSize, ySize, 0, CopyFromParent, InputOutput, CopyFromParent, CWBackPixel, &swa); XStoreName(XDpy, Shared->xWin, "Performer GLX Test"); /* create window for GL rendering */ #ifdef VENICE if (getgdesc(GD_MULTISAMPLE) > 0) config = GLXCreateWindow(XDpy, Shared->xWin, 0, 0, xSize, ySize, 0, GLX_NORMAL, GLX_DOUBLE, TRUE, GLX_NORMAL, GLX_RGB, TRUE, GLX_NORMAL, GLX_ZSIZE, 0, GLX_NORMAL, GLX_STENSIZE, 0, GLX_NORMAL, GLX_MSSAMPLE, 8, GLX_NORMAL, GLX_MSZSIZE, 24, GLX_NORMAL, GLX_MSSSIZE, 1, GLX_OVERLAY, GLX_BUFSIZE, 2, 0, 0, 0); else #endif config = GLXCreateWindow(XDpy, Shared->xWin, 0, 0, xSize, ySize, 0, GLX_NORMAL, GLX_DOUBLE, TRUE, GLX_NORMAL, GLX_RGB, TRUE, GLX_NORMAL, GLX_ZSIZE, GLX_NOCONFIG, GLX_NORMAL, GLX_STENSIZE, 1, GLX_OVERLAY, GLX_BUFSIZE, 2, 0, 0, 0); Shared->glWin = GLXgetvalue(config, GLX_NORMAL, GLX_WINDOW); Shared->overWin = GLXgetvalue(config, GLX_OVERLAY, GLX_WINDOW); XMapWindow(XDpy, Shared->glWin); XMapWindow(XDpy, Shared->xWin); XFlush(XDpy); /* initialize Performer for GLX rendering */ InitGLXGfx(p, Shared->xWin, Shared->glWin, Shared->overWin); /* create a light source in the "south-west" (QIII) */ Sun = pfNewLight(NULL); pfLightPos(Sun, -0.3f, -0.3f, 1.0f, 0.0f); /* create a default texture environment */ pfApplyTEnv(pfNewTEnv(NULL)); /* create a default lighting model */ pfApplyLModel(pfNewLModel(NULL)); /* enable culling of back-facing polygons */ pfCullFace(PFCF_BACK); /* * These enables should be set to reflect the majority of the * database. If most geometry is not textured, then texture * should be disabled. However, you then need to change the * FLIGHT-format file reader. (pfflt.c) */ pfEnable(PFEN_TEXTURE); pfEnable(PFEN_LIGHTING); pfEnable(PFEN_FOG); } /* * CullChannel() -- traverse the scene graph and generate a * display list for the draw process. This procedure is * executed in the cull process. */ static void CullChannel(pfChannel *channel, void *data) { /* * pfDrawGeoSet or other display listable Performer routines * could be invoked before or after pfCull() */ pfCull(); } /* * DrawChannel() -- draw a channel and read input queue. this * procedure is executed in the draw process (when there is a * separate draw process). */ static void DrawChannel (pfChannel *channel, void *data) { /* rebind light so it stays fixed in position */ pfLightOn(Sun); /* erase framebuffer and draw Earth-Sky model */ pfClearChan(channel); /* invoke Performer draw-processing for this frame */ pfDraw(); /* draw Performer throughput statistics */ if (Shared->drawStats) pfDrawChanStats(channel); /* read window origin and size (it may have changed) */ pfGetWindowSize(pfGetChanPipe(channel), &Shared->winSizeX, &Shared->winSizeY); pfGetWindowOrigin(pfGetChanPipe(channel), &Shared->winOriginX, &Shared->winOriginY); if (Shared->redrawOverlay) { Shared->redrawOverlay = 0; DrawOverlay(); } } /* leave FocusChange in XINMASK, since doesn't work in GLINMASK */ #define XINMASK (FocusChangeMask) /* * want motion and button presses only within GL window area, * parent X window focus includes window border */ #define GLINMASK (KeyPressMask | \ ButtonPressMask | \ ButtonReleaseMask | \ ExposureMask | \ PointerMotionMask) static void GetXInput(void) { static long first = 1; XEvent ev; long newMouse = 0; long x, y; /* Display already open in single process mode */ if (XDpy == NULL) { XDpy = XOpenDisplay(":0.0"); if (!XDpy) pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "GetXInput: couldn't open display\n"); } if (first) { XSelectInput(XDpy, Shared->glWin, GLINMASK); XSelectInput(XDpy, Shared->xWin, XINMASK); first = 0; } while (XCheckWindowEvent(XDpy, Shared->glWin, GLINMASK, &ev)) { switch (ev.type) { case Expose: Shared->redrawOverlay = 1; break; case ButtonPress: switch (ev.xbutton.button) { case (1): Shared->mouseButtons = ev.xbutton.state | Button1Mask; break; case (2): Shared->mouseButtons = ev.xbutton.state | Button2Mask; break; case (3): Shared->mouseButtons = ev.xbutton.state | Button3Mask; break; } break; case ButtonRelease: switch (ev.xbutton.button) { case (1): Shared->mouseButtons = ev.xbutton.state & ~Button1Mask; break; case (2): Shared->mouseButtons = ev.xbutton.state & ~Button2Mask; break; case (3): Shared->mouseButtons = ev.xbutton.state & ~Button3Mask; break; } break; case MotionNotify: { newMouse = 1; x = ev.xmotion.x; y = ev.xmotion.y; } break; case KeyPress: { KeySym ks; /* * On a keypress, either rotate and re-display * or exit. */ ks = XLookupKeysym(&ev.xkey, 0); switch (ks) { case XK_F1: { Shared->drawStats = !Shared->drawStats; break; } case XK_Escape: { Shared->exitFlag = 1; break; } } break; } } } while (XCheckWindowEvent(XDpy, Shared->xWin, XINMASK, &ev)) { switch (ev.type) { case FocusIn: break; case FocusOut: Shared->inWindow = 0; break; } } if (newMouse) { long xs, ys; Shared->mouseX = 2.0f*x/(float)Shared->winSizeX - 1.0f; Shared->mouseY = -2.0f*y/(float)Shared->winSizeY + 1.0f; Shared->inWindow = 1; } } static void DrawOverlay(void) { if (GLXwinset(XDpy, Shared->overWin) < 0) { pfNotify(PFNFY_WARN, PFNFY_SYSERR, "GLXwinset for overlay failed\n"); return; } pfPushState(); pfBasicState(); zbuffer(FALSE); pfPushIdentMatrix(); mapcolor(0, 0, 0, 0); mapcolor(1, 71, 9, 82); mapcolor(2, 0, 0, 0); gflush(); color(0); clear(); ortho2(-0.5, Shared->winSizeX - 0.5, -0.5, Shared->winSizeY - 0.5); cmov2(2, 2); color(1); charstr("GLX Overlay Test"); pfPopMatrix(); zbuffer(TRUE); pfPopState(); if (GLXwinset(XDpy, Shared->glWin) < 0) { pfNotify(PFNFY_WARN, PFNFY_SYSERR, "GLXwinset for NORMAL window failed\n"); } } /* * usage() -- print usage advice and exit. This procedure * is executed in the application process. */ static void usage (void) { fprintf(stderr, "Usage: complex-glx file.flt ...\n"); pfExit(); exit(1); } /* * /usr/people/4DGifts/examples/GLX/gl-Xlib/glxh2.c * * This file (companion to mix2.c) provides the helper function * "GLXCreateWindow", which does all the necessary magic to create * an X window suitable for GL drawing to take place within. * see the definition of GLXCreateWindow for a description of how * to call it. */ #include #include #include #include #include /* ** Internal helper routines */ /* extract_visual: * a visual is uniquely identified by a viusal identifier descibing the * visual and screen. this function is used to get back the * GLX_NORMAL-GLX_VISUAL and the GLX_NORMAL-GLX_COLORMAP fields out of * the configuration data for use in creating a window using these data. * XGetVisualInfo() returns a list of visual structures that match the * attributes explicitly specified in the template structure. */ static XVisualInfo* extract_visual(Display* D, int S, GLXconfig *conf, int buffer) { XVisualInfo template, *v; int n; template.screen = S; template.visualid = GLXgetvalue(conf, buffer, GLX_VISUAL); return XGetVisualInfo (D, VisualScreenMask|VisualIDMask, &template, &n); } /* set_window() * search thru the current conf GL window structure looking for the * buffer that matches the mode of GLX_WINDOW so that we can go ahead * and assign the window W, (created via XCreateWindow below in * GLXCreateWindow) to the arg element. We do this because in order * for this stuff to work, the "arg" element of the conf structure * must have the value field set to the X window id of the window * which was created. */ static void set_window(GLXconfig* conf, int buffer, Window W) { int i; for (i = 0; conf[i].buffer; i++) if (conf[i].buffer == buffer && conf[i].mode == GLX_WINDOW) conf[i].arg = W; } /* ** Used to get a value out of the configuration structure returned by ** GLXgetconfig. Scan through the GLX config structure, and, when we ** find the proper buffer-mode combination, return the argument relevant ** for that buffer type. */ unsigned long GLXgetvalue(GLXconfig* conf, int buffer, int mode) { int i; for (i = 0; conf[i].buffer; i++) if (conf[i].buffer == buffer && conf[i].mode == mode) return conf[i].arg; return 0; } /* * GLXCreateWindow(dpy, parent, x, y, w, h, boderWidth, arg_list, ...) * * Return value is the filled in config structure * * Arguments are: * dpy The X "Display*" returned by XOpenDisplay * parent The parent of the newly created window, * a typical value for this is * RootWindow(dpy, DefaultScreen(dpy)) * x,y The location of the window to be created, * y coordinate is measured from the top down. * w,h size of the new window * borderWidth the X border size for this window, should probably * be zero. * arg_list Arguments to fill in initial config structure */ GLXconfig* GLXCreateWindow( Display* dpy, Window parent, int x, int y, int w, int h, int borderWidth, ...) { XSetWindowAttributes init_attr; XWindowAttributes read_attr; GLXconfig init_config[50], *cp; GLXconfig *retconfig; Window win, normal_win; va_list ap; int buf, screen; XVisualInfo *vis; /* ** Loop through the remaining arguments, copying all triples ** up to a zero-triple (or just plain zero if there are no ** triples), into the initial config structure. */ va_start(ap, borderWidth); for (cp = init_config; buf = va_arg(ap, int); cp++) { cp->buffer = buf; cp->mode = va_arg(ap, int); cp->arg = va_arg(ap, int); } cp->buffer = cp->mode = cp->arg = 0; /* ** Now that we have the configuration request, call GLXgetconfig to ** get back real configuration information. */ XGetWindowAttributes(dpy, parent, &read_attr); screen = XScreenNumberOfScreen(read_attr.screen); if ((retconfig = GLXgetconfig(dpy, screen, init_config)) == 0) { pfNotify(PFNFY_FATAL, PFNFY_RESOURCE, "Hardware doesn't support that window type\n"); } /* ** Now we have the information needed to actually create the ** windows. There is always a normal window, so we create that ** one first. ** ** Basically we extract the GLX_NORMAL,GLX_VISUAL and the ** GLX_NORMAL,GLX_COLORMAP fields out of the configuration * data, and create a window using these data. ** When we are done we save the X ID of the new window in ** the configuration structure (using set_window()). GLXlink, ** and the caller of GLXCreateWindow will be interested in ** this value. ** note the explicit definition of the init_attr.colormap ** element: we aren't sure if our visual is the same as our ** parent's, and we'd like to not care. since our colormap ** and visual MUST be of the same depth and class (else the ** BadMatch error will bite), we pass a colormap which we ** know will match our visual. If we don't do this, we ** inherit from our parent and all bets are off.. */ vis = extract_visual(dpy, screen, retconfig, GLX_NORMAL); init_attr.colormap = GLXgetvalue(retconfig, GLX_NORMAL, GLX_COLORMAP); init_attr.border_pixel = 0; /* Must exist, otherwise BadMatch error */ normal_win = XCreateWindow (dpy, parent, x, y, w, h, borderWidth, vis->depth, InputOutput, vis->visual, CWColormap|CWBorderPixel, &init_attr); set_window(retconfig, GLX_NORMAL, normal_win); /* ** If overlay planes were requested in the configuration, and ** they are available, the GLX_OVERLAY,GLX_BUFSIZE arg field in ** the returned configuration will be non zero. If this is the ** case, we create another window, in the overlay planes, a child ** of the normal planes window. The size is 2K x 2K so that the ** overlay window will never have to be resized, it will always ** be clipped by the size of its parent. */ if (GLXgetvalue(retconfig, GLX_OVERLAY, GLX_BUFSIZE)) { vis = extract_visual(dpy, screen, retconfig, GLX_OVERLAY); init_attr.colormap = GLXgetvalue(retconfig,GLX_OVERLAY,GLX_COLORMAP); win = XCreateWindow (dpy, normal_win, 0, 0, 2000, 2000, 0, vis->depth, InputOutput, vis->visual, CWColormap|CWBorderPixel, &init_attr); XMapWindow(dpy, win); set_window(retconfig, GLX_OVERLAY, win); } /* ** Do exactly the same stuff, but this time for the popup planes ** when we are running on a machine that has no OVERLAY planes. */ if (GLXgetvalue(retconfig, GLX_POPUP, GLX_BUFSIZE)) { vis = extract_visual(dpy, screen, retconfig, GLX_POPUP); init_attr.colormap = GLXgetvalue(retconfig,GLX_POPUP,GLX_COLORMAP); win = XCreateWindow (dpy, normal_win, 0, 0, 2000, 2000, 0, vis->depth, InputOutput, vis->visual, CWColormap|CWBorderPixel, &init_attr); XMapWindow(dpy, win); set_window(retconfig, GLX_POPUP, win); } /* now do the final step: configure the X window for GL rendering. ** this informs the GL that we intend to render GL into an X window. ** at this point, the retconfig structure contains all the ** information necessary to ensure that X and GL know about each ** other and will behave in a responsible manner... */ if (GLXlink(dpy, retconfig) < 0) { pfNotify(PFNFY_FATAL, PFNFY_SYSERR, "GLXlink failed\n"); } /* finally do what winopen() always did: explicitly set the current ** GL window to be this new mixed model window. */ GLXwinset(dpy, normal_win); return retconfig; } -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 7L-590 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Mon Jan 10 17:18:47 1994 From: "Wade Olsen" Message-Id: <9401101718.ZM16684@fnord.asd.sgi.com> Date: Mon, 10 Jan 1994 17:18:22 -0800 In-Reply-To: covingto@gravy5.cs.nps.navy.mil (james covington) "Performer and OSF/Motif" (Jan 10, 11:46am) References: <9401101946.AA15285@gravy5.cs.nps.navy.mil> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: covingto@gravy5.cs.nps.navy.mil (james covington), info-performer@sgi.sgi.com Subject: Re: Performer and OSF/Motif Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jan 10, 11:46am, james covington wrote: > Subject: Performer and OSF/Motif > Last week I wrote: > > ->I have reviewed Wade Olsen's sample program which shows how to run Performer > ->inside a Motif application. However when I tried to modify a larger existing > ->Performer application (one which used the standard winopen() call in the > ->pfInitfunc) to run in this manner, I received GL error #114 (ERR_NOGRAPHICS) > ->when I called the GLXlink function. Can you help explain what causes error > ->#114, and what I could possibly do to avoid it? > > I want to thank you for the EXTREMELY fast response to my last posting > on this subject. I sent the mail late on Friday, and really didn't expect > any reply before the beginning of the week. > > Your suggestions were very helpful, and I am still working on the problem. > > At this point, I have taken a step backward and simply compiled Wade Olsen's > sample program with my original makefile and include files. When I ran the > program, it ran "successfully," but generated the error message: > > ERROR #4 ortho2: ERR_BADWINDOW > The sample program has definitions for the GL routines getsize and getorigin. These are faster versions than the GL counterparts because the GL must make a request to the X server and wait for a responce. But since this application watches for resize events it knows what the window size is. But if performer asks for the window size before the app gets some indication of the window size then performer might be using garbage from my version of getsize. A quick and resonable fix might be to stick some default values in win_x_size and win_y_size right after they are allocated out of shared memory. I wrote this example using Perf1.1 on IRIX 5.*. I'll bet that compiler differences and not initializing these variables is the culprit. Sorry. Regarding applying this approach to an existing application, be careful! The order things happen in is very critical. It might be easier to take a working program and make incremental changes (the example for instance) and morph it into your final application. Then again, maybe not :-). I'm trying to come up with a multi-pipe version of this. I'll post it here when I can get it working. > twice, once when I called pfConfig, and again when I called XtRealizeWidget. > Can you tell me what conditions generate this error? > > I am running Performer 1.0 and Motif 1.1 on an IRIS 4D/440 Reality Engine > with IRIX 4.0.5G. Thanks. > > James Covington LT USN > Naval Postgraduate School > Monterey CA > > > > > >-- End of excerpt from james covington -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Mon Jan 10 17:35:25 1994 From: "Wade Olsen" Message-Id: <9401101735.ZM16738@fnord.asd.sgi.com> Date: Mon, 10 Jan 1994 17:35:18 -0800 In-Reply-To: jrohlf@tubes (John Rohlf) "Re: Questions RE> Performer" (Jan 10, 10:55am) References: <9401101855.AA10163@tubes.asd.sgi.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: Questions RE> Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jan 10, 10:55am, John Rohlf wrote: > Subject: Re: Questions RE> Performer > > > >| 4. Textures sometimes vanishes for short while: > >| ================================================ > >| This is probably the strangest problem. If you drive a long a textured > >| road. On certain spotsparts of the road dissappears. > >| > >| My customer has installed a MCO option aswell as a normal screen. If we > >| run the application using MCO and three channels, the texure can > >| dissappear in one of the cannels but not in the others. > > > >Strange. Maybe someone else has an idea. > > An older IRIX release had a bug where a specific mipmap level would > drop out. What release are you running? >-- End of excerpt from John Rohlf First you say the texture disappears but later you say "parts of the road" disappear. Now if you mean the latter, is it possible the bounding boxes of the road are incorrect and therefore culled out? Are the roads procedurally generated? I don't remember what version of performer you are using but I seem to recall some perf1.0 bug about culling multiple levels of DCS's. I'm not sure though. Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems 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 Status: O *** 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 Status: O 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 Status: O > 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 Status: O 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 Status: O > 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 Status: O 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] Status: O 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 Status: O 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 Status: O 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 Status: O 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 Status: O 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 Status: O 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 Status: O 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 Status: O 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? Status: O >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 Status: O 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!) Status: O 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 Status: O 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!) Status: O 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? Status: O 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 Status: O 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 ? Status: O 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 Status: O +>---- 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 Status: O 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> Status: O 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 Status: O 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 Status: O 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 06:49:25 1994 Date: Thu, 20 Jan 94 15:53:27 +0100 From: gce@chenas.inria.fr (Cedric Gautier ) Message-Id: <9401201453.AA07991@bahamas.comete.syseca.fr> To: info-performer@sgi.sgi.com Subject: Inventor loader in Performer 1.2 ... Status: O Question to happy Performer beta 1.2 version users: Is there really an Inventor loader in this version ? If so ... does it take care about all Inventor information as hierarchy, materials, lights, textures, etc ... ? Thanks for answers to this quite basic question ... Bienvenue ... et merci ... Cedric A Virtual Image from SYSECA's Virtuel Image Group Gerard Banel / Cedric Gautier 1qazxsw21qazxsw21qazxsw21qazxsw21qazxsw21qazxsw21qazxsw21qazxsw21qazxsw21qazxs 3edcvfr43edcvfr43edcvfr43edcvfr43edcvfr43edcvfr43edcvfr43edcvfr43edcvfr43edcvf %TGBNHY^%TGBNHY^%TGBNHY^%TGBNHY^%TGBNHY^%TGBNHY^%TGBNHY^%TGBNHY^%TGBNHY^%TGBNH ^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJu7^YhnMJ *iK,>lO9*iK,>lO9*iK,>lO9*iK,>lO9*iK,>lO9*iK,>lO9*iK,>lO9*iK,>lO9*iK,>lO9*iK,>l )P;/"{-=)P;/"{-=)P;/"{)P;/"{)P;/"{)P;/"{)P;/"{)P;/"{9i)P;/"{9i)P;/"{9i)P;/"{9i !@#$%^&*!@#$%^&*!@#$%^!@#$%^!@#$%^!@#$%^!@#$%^!@#$%^8u!@#$%^8u!@#$%^8u!@#$%^8u {}OPuiTY{}OPuiTY{}OPui{}OPui{}OPui{}OPui{}OPui{}OPui6^{}OPui6^{}OPui6^{}OPui6^ ';LKjhGF';LKjhGF';LKjh';LKjh';LKjh';LKjh';LKjh';LKjh5$';LKjh5$';LKjh5$';LKjh5$ +-)9*7^5+-)9*7^5+-)9*7+-)9*7+-)9*7+-)9*7+-)9*7+-)9*7!@+-)9*7!@+-)9*7!@+-)9*7!@ !e^i)[+p!e^i)[+p!e^i)[!e^i)[!e^i)[!e^i)[!e^i)[!e^i)[*9!e^i)[*9!e^i)[*9!e^i)[*9 ];./'[pl];./'[pl];./'[];./'[];./'[];./'[];./'[];./'[$4];./'[$4];./'[$4];./'[$4 Er$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg^kEr$5Tg 'L;Op'L;Op'L;Op'L;Op'L;Op'L;Op'L;Op'L;Op'L;Op'L; z#x$c%v^z#x$c%v^z#x$c%v^z#x$c%v^z#x$c%v^z#x$c%v^z#x$c%v^z#x$c%v^z#x$c%v^z#x$c% -!23$%67-!23$%67-!23$%67-!23$%67-!23$%67-!23$%67-!23$%67-!23$%67-!23$%67-!23$% 5%6^7&8*5%6^7&8*5%6^7&8*5%6^7&8*5%6^7&8*5%6^7&8*5%6^7&8*5%6^7&8*5%6^7&8*5%6^7& | | If you can cross eyes to generate three vertical lines from the bottom two lines, you will be able at last to see a 3D stereoscopic image ... sure !. BE PATIENT, IT'S NOT INSTANTANEOUS ! ------------------------------------------------------------------------------ = 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 = = Virtuel Image Group (3D Simulation/Virtual Reality) - email: gce@syseca.fr = ------------------------------------------------------------------------------ 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 Status: O 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 Status: O 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 Status: O ------- 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:54:02 1994 From: "Michael Jones" Message-Id: <9401201453.ZM18094@babar.asd.sgi.com> Date: Thu, 20 Jan 1994 14:53:47 -0800 In-Reply-To: gce@chenas.inria.fr (Cedric Gautier ) "Inventor loader in Performer 1.2 ..." (Jan 20, 3:53pm) References: <9401201453.AA07991@bahamas.comete.syseca.fr> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: gce@chenas.inria.fr (Cedric Gautier ), info-performer@sgi.sgi.com Subject: Re: Inventor loader in Performer 1.2 ... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jan 20, 3:53pm, Cedric Gautier wrote: > Subject: Inventor loader in Performer 1.2 ... : :Question to happy Performer beta 1.2 version users: : :Is there really an Inventor loader in this version ? Yes. :If so ... does it take care about all Inventor information as hierarchy, :materials, lights, textures, etc ... ? No. It represents the best loader I could write in a single afternoon -- and I'm not that fast. The right thing to do is to parse the grammar, but there was no handy YACC grammar, and since a new "IRIS Open Inventor" product will soon be announced with a somewhat different file format, I did not feel that it was worth the investment of time to generate one. It does read the fifty or so models that come with the current version of IRIS Inventor -- the aircar, pear, space station, and so on. I'd be happy to post it here, but it would do you little good since it relies on several of the new database loader utility functions that you don't yet have. -- 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 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 Status: O 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 Status: O >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 Status: O > 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 Status: O 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 Mon Feb 14 04:08:11 1994 for info-performer@sgi.com To: info-performer@sgi.sgi.com Subject: unsubscribe From: weigner@rcs.de (weigner) Message-Id: Date: Mon, 24 Jan 94 17:55:14 GMT Organization: rcs management gmbh Status: O Please unsubscribe me. Thanks a lot. Jan Weigner weigner@rcs.de --------------------- email: weigner@rcs.de rcs management gmbh dammweg 15 28211 bremen germany fax: +49 421 3477447 From guest Mon Jan 24 17:23:12 1994 Date: Mon, 24 Jan 94 17:24:29 -0800 From: goetzjr@gravy5.cs.nps.navy.mil (john goetz) Message-Id: <9401250124.AA18180@gravy5.cs.nps.navy.mil> To: info-performer@sgi.sgi.com Subject: SegIsect Status: O I am having a problem with performing intersection testing with a pfPlane. Here is the segment of code where I setup the pfPlane and the pfSeg for intersection testing. When the program is executed I get a segmentation violation when pfSegIsectPlane is called. Can anyone please tell me what is wrong. I am running on a Iris 440/4D RE with Performer 1.0. Thank You ************************************************************************** pfPlane *grnd_plane; void main() { pfVec3 grnd_norm; pfVec3 grnd_pos; /* initialize Performer */ pfInit(); pfMultiprocess(PFMP_DEFAULT); pfConfig(); grnd_plane = (pfPlane*)pfMalloc(sizeof(pfPlane), NULL); pfSetVec3(grnd_norm, 0.0f, 0.0f, 1.0f); pfSetVec3(grnd_pos, 0.0f, 0.0f, 0.0f); pfMakeNormPtPlane(grnd_plane, grnd_norm, grnd_pos); pfOffsetPlane(grnd_plane, 0.0f); while (TRUE) { pfSync(); pfChanView(chan, view.xyz, view.hpr); pfFrame(); ground_contact(); } // end while(TRUE) }// end main() void ground_contact() { float *d; pfSeg *foot; foot = (pfSeg*)pfMalloc(sizeof(pfSeg), NULL); PFSET_VEC3(foot->pos, 0.0f, 0.0f, 10.0f); PFSET_VEC3(foot->dir, 0.0f, 0.0f, -1.0f); foot->length = 30.0f; if(pfSegIsectPlane(foot, grnd_plane, d) == PFIS_FALSE) printf("No ground intersection\n"); else printf("ground intersect height = %.3f\n", *d); } ************************************************************************** John Goetz goetzjr@cs.nps.navy.mil From guest Mon Jan 24 21:41:27 1994 Message-Id: <9401250541.AA28849@surreal.asd.sgi.com> To: goetzjr@gravy5.cs.nps.navy.mil (john goetz) Cc: info-performer@sgi.sgi.com Subject: Re: SegIsect In-Reply-To: Your message of "Mon, 24 Jan 94 17:24:29 PST." <9401250124.AA18180@gravy5.cs.nps.navy.mil> Date: Mon, 24 Jan 94 21:41:11 -0800 From: Jim Helman Status: O > float *d; > > ... /* w/no initialization of d */ > > if(pfSegIsectPlane(foot, grnd_plane, d) == PFIS_FALSE) > float d; if(pfSegIsectPlane(foot, grnd_plane, &d) == PFIS_FALSE) will work better. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jan 25 07:15:08 1994 Message-Id: <199401251514.KAA06701@anaconda.cis.ohio-state.edu> To: info-performer@sgi.sgi.com Status: O Subject: Beginner Performer Question Hi all, I'm trying to duplicate GL's window() call using Performer. Normally, one would set up each channel with pfChanFOV, but I can not use a vertically symmetric FOV for this application. For example, the GL code would be near = 20.0f; far = 2000.0f; left = -tan(10.0*DEG2RAD)*near; bottom = -tan(16.0*DEG2RAD)*near; top = tan(25.0*DEG2RAD)*near; window(left, -left, bottom, top, near, far); Can I use pfMakePerspFrustum and then send the matrix to pfChanViewMat ? What is the easiest way to do this on a multichannel/pipe system where two sets of views use a different viewing frustum ? How does pfChanViewMat function ? Do I need to apply the necessary viewpoint rotations and translations before passing the matrix to pfChanViewMat ? My _guess_ is for each channel, do a pfMakePerspFrustum, apply the rotations and translations to the output matrix, and pass the result to pfChanViewMat. I'd try this, but our system is in use and I'm developing offline. I could not find similar examples in the Performer Programming Guide nor in the Performer FAQ. Thank you for any assistance, Mark Visconti From guest Tue Jan 25 07:01:33 1994 Return-Path: From: durand@inrets.fr Request-Delivery-Notification: TRUE Date: Tue, 25 Jan 94 16:01:03 +0100 Message-Id: <9401251501.AA22766@deneb.inrets.fr> To: info-performer@sgi.sgi.com Subject: Medit Status: O Hi, Does anyone know about Medit, a pretty nice and cheap modeller that runs on Sgi ? Thanks for your comments. Chantal Durand 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 Status: O 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 Tue Jan 25 10:28:35 1994 Message-Id: <9401251828.AA08502@surreal.asd.sgi.com> To: Mark Visconti Cc: info-performer@sgi.sgi.com In-Reply-To: Your message of "Tue, 25 Jan 94 10:14:57 EST." <199401251514.KAA06701@anaconda.cis.ohio-state.edu> Date: Tue, 25 Jan 94 10:28:20 -0800 From: Jim Helman Status: O There isn't an easy, clean way to do off-axis viewing frusta in 1.0/1.1. pfChanViewMat only provides an eyepoint and orientation. It says nothing about the projection matrix. You can set up your own projection matrix in the channel draw callback by calling the GL window command directly. However, you also have to change your culling frustum, which in 1.0/1.1 must be syummetric, so that it includes the off-axis one. You can do this by changing the orientation and symmetric FOV of the pfChannel. Here's what the matrix stack looks like in 1.0/1.1 when your channel draw callback is invoked: window(winLeft, winRight, winBottom, winTop, near, far); mmode(MVIEWING); pfMatrix invViewMatrix; pfInvertOrthoNMat(invViewMatrix, viewMatrix); loadmatrix(ident); rot(-90, 'x'); // Convert from GL Z-out, Y-up to viskit // Y-in, Z-up. multmatrix(invViewMatrix); 1.2 supports off-axis frusta, so you won't need to hack the stack. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Jan 26 07:47:52 1994 Date: Wed, 26 Jan 94 17:46:49 +0200 From: rany@bvr.co.il (Ran Yakir) Message-Id: <9401261546.AA01311@amcor.bvr.co.il> To: info-performer@sgi.sgi.com Subject: 1.0/1.1 bug in LoadFlt Status: O Actualy, not in LoadFlt buf in one of its static functions named - getTexture (and resides in pfflt/geom.c). getTexture attepts to read the attributes file (.attr) using the line read(ifd, (char*)&texAttr, stbuf.st_size); where : 1. stbuf is the buffer returned by stat(), and stbuf.st_size containts the attributes file size. 2. texAttr is a structure that will contain the full contents of the file. If, for some reason, the .attr file is larger then its minimal size, the read command will run over texAttr right into the rest of the stack, and mess things up. You won't notice it at first, but then some malloc() will core you dump (or dump your core). What should be done (and is easy to do on-site) is replacing the line with : read(ifd, (char*)&texAttr, sizeof texAttr); Good luck Ran Yakir __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest Wed Jan 26 07:56:26 1994 Date: Wed, 26 Jan 94 17:55:20 +0200 From: rany@bvr.co.il (Ran Yakir) Message-Id: <9401261555.AA01675@amcor.bvr.co.il> To: info-performer@sgi.sgi.com Subject: 1.0/1.1 bug in LoadFlt Status: O From guest Wed Jan 26 08:13:38 1994 From: "Michael Jones" Message-Id: <9401260812.ZM15156@babar.asd.sgi.com> Date: Wed, 26 Jan 1994 08:12:22 -0800 In-Reply-To: rany@bvr.co.il (Ran Yakir) "1.0/1.1 bug in LoadFlt" (Jan 26, 5:46pm) References: <9401261546.AA01311@amcor.bvr.co.il> X-Mailer: Z-Mail (3.0.110 10jan94 MediaMail) To: rany@bvr.co.il (Ran Yakir), info-performer@sgi.sgi.com Subject: Re: 1.0/1.1 bug in LoadFlt Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jan 26, 5:46pm, Ran Yakir wrote: > Subject: 1.0/1.1 bug in LoadFlt : :Actualy, not in LoadFlt buf in one of its static functions named - :getTexture (and resides in pfflt/geom.c). :getTexture attepts to read the attributes file (.attr) using the line : : read(ifd, (char*)&texAttr, stbuf.st_size); : :where : :1. stbuf is the buffer returned by stat(), and stbuf.st_size containts : the attributes file size. :2. texAttr is a structure that will contain the full contents of the file. : :If, for some reason, the .attr file is larger then its minimal size, :the read command will run over texAttr right into the rest of the stack, and :mess things up. You won't notice it at first, but then some malloc() will :core you dump (or dump your core). : :What should be done (and is easy to do on-site) is replacing the line :with : : : read(ifd, (char*)&texAttr, sizeof texAttr); Good observation. This was indeed a bug in LoadFlt() and the fix given by Ran Yakir is the right one. -- Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From rany Wed Jan 26 17:46:46 1994 To: info-performer@sgi.com Subject: 1.0/1.1 bug in LoadFlt Status: OR Actualy, not in LoadFlt buf in one of its static functions named - getTexture (and resides in pfflt/geom.c). getTexture attepts to read the attributes file (.attr) using the line read(ifd, (char*)&texAttr, stbuf.st_size); where : 1. stbuf is the buffer returned by stat(), and stbuf.st_size containts the attributes file size. 2. texAttr is a structure that will contain the full contents of the file. If, for some reason, the .attr file is larger then its minimal size, the read command will run over texAttr right into the rest of the stack, and mess things up. You won't notice it at first, but then some malloc() will core you dump (or dump your core). What should be done (and is easy to do on-site) is replacing the line with : read(ifd, (char*)&texAttr, sizeof texAttr); Good luck Ran Yakir __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il __ | Ran Yakir /_) _ __ \ / _ / o __ | Phone : / )_ (_(_) ) \/ (_(_/<_(_)( | Work : 972-3-5715671 _/ | Res. : 972-3-6995364 | E-mail : rany@bvr.co.il From guest 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 Status: O 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 Status: O 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 Status: O >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 Status: O >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 Status: O > 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 Status: O 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 Status: O >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: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 Status: O 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: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 Status: O 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 Status: O 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? Status: O Is there the document which contains all of the new features of Performer1.2 and is available now? From guest Mon Jan 31 09:40:57 1994 From: "Angus Henderson" Message-Id: <9401311528.ZM1168@death.reading.sgi.com> Date: Mon, 31 Jan 1994 15:28:56 +0000 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: info-performer@sgi.sgi.com Subject: Medit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Chantal Durand of INRETS in France asked about Medit the low cost database modeling software. Myself and a few colleagues around Europe have been aware of this software for some time although it is not yet released as a product. I think version 1.0 will be generally available in a couple of months. I have an early release ( version 0.95 ) which I have been evaluating and it looks like it will be a very useful tool for database modeling for Performer (there is a Performer loader) or Inventor. If anyone is interested they should write or send a fax to... Mr Colin Dooley Medit Productions S.A. Plaza Jose Maria Orense 12, Pta. 5 46022 Valencia SPAIN Fax +34 6 372 6063 ... for a demo copy ( you don't need a license unless you want to save stuff ) a.t.b. Angus Henderson The Reality Centre