From guest Wed Jun 1 15:37:48 1994 From: "Wade Olsen" Message-Id: <9406011536.ZM3519@fnord.asd.sgi.com> Date: Wed, 1 Jun 1994 15:36:37 -0700 In-Reply-To: fair@iss.nus.sg (Kim Michael Fairchild) "real-time video in texture memory" (May 25, 6:54pm) References: <9405251054.AA18362@bochap.iss.nus.sg> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: fair@iss.nus.sg (Kim Michael Fairchild), info-performer@sgi.sgi.com Subject: Re: real-time video in texture memory Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 25, 6:54pm, Kim Michael Fairchild wrote: > Subject: real-time video in texture memory > Hi, > > Is it possible to get video into texture memory on a reality-engine? I > would like do something like you see in "the 7th guest" cd-rom game, > so I would like to be able to take a video source and "play" it into a > texture. > > possible? > > thanks, Kim. > > > >-- End of excerpt from Kim Michael Fairchild Yes. How depends on where the video comes from: If the video comes from an external source (e.g. a camera, vcr...) and you want brodcast quality video resolution, then the Sirius board is what you want. Video can be read from a source, change color spaces (like betacam -> rgb), and load directly into texture memory. If the video comes from memory, like little animation sequences, then no extra hardware need be purchased. There are two demos that show this effect. "tele" shows digital video effects applied to video from Sirius, memory and disk. "camcorder" shows a model of a camera with a working view finder. The view finder texture is updated everyframe and shows whatever the camera is pointing at. Pester your sales rep if you want to see this work. The relevant GL man pages are: texdef2d (use the FASTDEFINE token) and subtexload. For performer, see: pfTexFormat, pfGetGLHandle. Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Wed Jun 1 23:59:06 1994 From: grap@itia.mi.cnr.it Organization: C.N.R.-I.T.I.A. Message-Id: <9406020857.AA03398@vib4.itia.mi.cnr.it> Subject: subscribe me! To: Info-Performer@sgi.sgi.com Date: Thu, 2 Jun 94 8:57:22 "MET" Mailer: Elm [revision: 70.85] Status: O -- --------------------------------------------------------------------- | _?_ | | Marco Sacco /. .\ | I.T.I.A - CNR | | Via Betti 85 { | } | National Research Council of Italy | | 20151 Milano \ - / | V.le Lombardia, 20/A | | ITALY \_/ | 20131 Milano ITALY | | | | | | grap@itia.mi.cnr.it | | Tel. +39 2 38008149 | | | | Tel. +39 2 70633449 | | | Fax. 39 2 2665558 | --------------------------------------------------------------------- From guest Thu Jun 2 00:00:04 1994 From: grap@itia.mi.cnr.it Organization: C.N.R.-I.T.I.A. Message-Id: <9406020858.AA03406@vib4.itia.mi.cnr.it> Subject: subscribe me! To: Info-performer@sgi.sgi.com Date: Thu, 2 Jun 94 8:58:45 "MET" Mailer: Elm [revision: 70.85] Status: O -- --------------------------------------------------------------------- | _?_ | | Marco Sacco /. .\ | I.T.I.A - CNR | | Via Betti 85 { | } | National Research Council of Italy | | 20151 Milano \ - / | V.le Lombardia, 20/A | | ITALY \_/ | 20131 Milano ITALY | | | | | | grap@itia.mi.cnr.it | | Tel. +39 2 38008149 | | | | Tel. +39 2 70633449 | | | Fax. 39 2 2665558 | --------------------------------------------------------------------- From guest Thu Jun 2 00:01:52 1994 From: grap@itia.mi.cnr.it Organization: C.N.R.-I.T.I.A. Message-Id: <9406020900.AA03416@vib4.itia.mi.cnr.it> Subject: subscribe me! To: info-Performer@sgi.sgi.com Date: Thu, 2 Jun 94 9:00:31 "MET" Mailer: Elm [revision: 70.85] Status: O -- --------------------------------------------------------------------- | _?_ | | Marco Sacco /. .\ | I.T.I.A - CNR | | Via Betti 85 { | } | National Research Council of Italy | | 20151 Milano \ - / | V.le Lombardia, 20/A | | ITALY \_/ | 20131 Milano ITALY | | | | | | grap@itia.mi.cnr.it | | Tel. +39 2 38008149 | | | | Tel. +39 2 70633449 | | | Fax. 39 2 2665558 | --------------------------------------------------------------------- From guest Thu Jun 2 00:02:40 1994 From: grap@itia.mi.cnr.it Organization: C.N.R.-I.T.I.A. Message-Id: <9406020901.AA03424@vib4.itia.mi.cnr.it> Subject: subscribe me! To: info-performer@sgi.sgi.com Date: Thu, 2 Jun 94 9:01:14 "MET" Mailer: Elm [revision: 70.85] Status: O -- --------------------------------------------------------------------- | _?_ | | Marco Sacco /. .\ | I.T.I.A - CNR | | Via Betti 85 { | } | National Research Council of Italy | | 20151 Milano \ - / | V.le Lombardia, 20/A | | ITALY \_/ | 20131 Milano ITALY | | | | | | grap@itia.mi.cnr.it | | Tel. +39 2 38008149 | | | | Tel. +39 2 70633449 | | | Fax. 39 2 2665558 | --------------------------------------------------------------------- From guest Thu Jun 2 12:59:41 1994 From: fred@vsl.ist.ucf.edu (Frederic Meraud) Message-Id: <9406021959.AA01503@thoth.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: source code Status: O Hi, I'd like to know if there is a way to get the source code of the demonstration programs. I am particularly interested in the 'Ideas In Motion' and 'Fast Shadows'. In fact, anything uses lightning and shadows would be useful. Thanks / \ / _ \ | / \ | || || _______ || || |\ \ || || ||\ \ || || || \ | || || || \__/ || || || || \\_/ \_/ \_// / _ _ \ / \ | O O | | \ ___ / | / \ \_/ / \ / ----- | --\ \ | \__/|\__/ \ | \ |_|_| / \_____ _____/ \ / | | ******* ****** ** ** ** ** ******** ****** ** **** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **** ******** ***** ** ** ** ** ******* ***** ** ******** ** ** ** ** ** ******** **** ** ** ** ** ** ** ** ** ** ** ****** ***** ** ** ** ** ** ** ****** ***** ** ** ** ** Beep beep ............is it a bird! is it a plane!...no, it's simply me!!!! From aschaffe Thu Jun 2 14:54:49 1994 From: aschaffe (Allan Schaffer) Message-Id: <9406021454.ZM26432@holodeck.asd.sgi.com> Date: Thu, 2 Jun 1994 14:54:44 -0700 In-Reply-To: fred@vsl.ist.ucf.edu (Frederic Meraud) "source code" (Jun 2, 3:59pm) References: <9406021959.AA01503@thoth.vsl.ist.ucf.edu> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: fred@vsl.ist.ucf.edu (Frederic Meraud), info-performer@sgi.sgi.com Subject: Re: source code Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 2, 3:59pm, Frederic Meraud wrote: > > I'd like to know if there is a way to get the source code of the > demonstration programs. I am particularly interested in the 'Ideas In > Motion' and 'Fast Shadows'. In fact, anything uses lightning and > shadows would be useful. The source for most of these demos (written in IRIS GL) are available on the "Developers Toolbox" CD that members of the Developer Program get. You can get information about the Dev program via your sales rep. The algorithm behind the 'ideas' demo is also in an old issue of IRIS Universe: Thant Tessman, "Casting shadows on flat surfaces", IRIS Universe, winter 1989, pg 16 enjoy.. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Fri Jun 3 02:04:38 1994 Return-Path: Message-Id: <9406030903.AA35840@ns.trl.ibm.com> To: info-performer@sgi.sgi.com Subject: summary Date: Fri, 03 Jun 1994 18:03:40 +0900 From: hirota@trl.ibm.co.jp Status: O Does somebody know how to get summary of this mailing list? -Gentaro From guest Fri Jun 3 07:26:44 1994 From: "Michael Jones" Message-Id: <9406030726.ZM29835@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 07:26:35 -0700 In-Reply-To: aschaffe@holodeck (Allan Schaffer) "Re: source code" (Jun 2, 2:54pm) References: <9406021959.AA01503@thoth.vsl.ist.ucf.edu> <9406021454.ZM26432@holodeck.asd.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: aschaffe (Allan Schaffer), fred@vsl.ist.ucf.edu (Frederic Meraud), info-performer@sgi.sgi.com Subject: Re: source code Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 2, 2:54pm, Allan Schaffer wrote: > Subject: Re: source code :On Jun 2, 3:59pm, Frederic Meraud wrote: :> :> I'd like to know if there is a way to get the source code of the :> demonstration programs. I am particularly interested in the 'Ideas In :> Motion' and 'Fast Shadows'. In fact, anything uses lightning and :> shadows would be useful. :The algorithm behind the 'ideas' demo is also in an old :issue of IRIS Universe: : : Thant Tessman, "Casting shadows on flat surfaces", : IRIS Universe, winter 1989, pg 16 You may also want to read: James F. Blinn, "Me and My (Fake) Shadow", IEEE Computer Graphics and Applications, 9(1), January 1988, pp. 82-86. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 07:36:35 1994 From: "Michael Jones" Message-Id: <9406030736.ZM29887@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 07:36:16 -0700 In-Reply-To: barrus@merl.com (John W. Barrus) "Re: real-time video in texture memory" (May 25, 8:55am) References: <9405251255.AA22816@merl.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: barrus@merl.com (John W. Barrus), fair@iss.nus.sg (Kim Michael Fairchild) Subject: Re: real-time video in texture memory Cc: info-performer@sgi.sgi.com, stro@merl.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 25, 8:55am, John W. Barrus wrote: > Subject: Re: real-time video in texture memory :We were told that the Sirius video board from SGI (~$25,000) would allow :video in texture. Unfortunately, the board we ordered more than 6 months :ago still has not shipped because they are still ironing out hardware bugs. :The latest date given for shipment is the end of May, but I'm not holding :my breath. Since I can't hold my breath for more than four minutes, I'd have to agree with you. On the other hand, I do know that we've been swamped with orders for Sirius and that the factory is working (quite literally) around the clock to assemble and test over 150 of these boards for shipment this month. Such are the problems with popularity--it seems that everybody wants a Sirius video board, and wants it right now. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 07:53:19 1994 From: "Michael Jones" Message-Id: <9406030753.ZM29906@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 07:53:05 -0700 In-Reply-To: Robert Rossow "Inexpensive Modelers?" (May 24, 1:43pm) References: <199405241737.KAA00832@sgi.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Robert Rossow , info-performer@sgi.sgi.com Subject: Re: Inexpensive Modelers? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 24, 1:43pm, Robert Rossow wrote: > Subject: Inexpensive Modelers? :Does anyone know of any (inexpensive) modelers capable of generating :hierarchical, texture mapped, polygonal and maybe even articulated :objects for import to Performer? The lowest cost modeler is i3dm, which is free and ships with IRIS Performer 1.2 in the "Friends of Performer" section of the CD. If it does what you need, the price will certainly be low enough. :If so, do you have a phone number or company name/location so :that I may contact them? We know of many modeling tools that can be used with IRIS Performer. Some of the advanced ones, such as MultiGen from Software Systems, have lower-cost Junior versions that may meet your needs. Here is a list of tools. MultiGen (and ModelGen, a kind of MultiGen Jr.) Software Systems 1884 The Alameda San Jose, CA 95126 Phone: (408) 247-4326 Fax: (408) 247-4329 Designer's Workbench Coryphaeus Software 985 University Avenue Suite 31 Los Gatos, CA 95030 Phone: (408) 395-4537 Fax: (408) 395-6351 Wavefront Technology, Inc. 530 East Montecito Street Santa Barbara, CA 93103 Phone: (805) 962-8117 Fax: (805) 962-1311 Alias Research, Inc. 110 Richmond St East Toronto, Canada M5C 1P1 Phone: (416) 362-9181 Fax: (416) 362-0630 Prisims Side Effects Software Inc. Toronto, Ontario Canada Phone: (416) 366-4607 People have also used the TDI Explore modeler, have used SOGITEC's SINDBAD, have used Symbolics S-Model, have use the S1000 database generation system, and I have been told, a new modeler (named "medit" ?) that works well with IRIS Performer and is in popular use in Europe. Note modeling tool vendors: If you're not on my list, please email me at mtj@sgi.com and you'll appear the next time this question is asked. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 07:59:31 1994 From: "Michael Jones" Message-Id: <9406030759.ZM29911@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 07:59:22 -0700 In-Reply-To: hirota@trl.ibm.co.jp ".poly and Prisms" (May 24, 9:45pm) References: <9405241245.AA66604@ns.trl.ibm.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: hirota@trl.ibm.co.jp, info-performer@sgi.sgi.com Subject: Re: .poly and Prisms Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 24, 9:45pm, hirota@trl.ibm.co.jp wrote: > Subject: .poly and Prisms :Roughly speaking, Prisms is an animation package like SoftImage or :Wavefront, and is developed by a Canadian company, Side Effects :Software Inc. : :The software can save polygon data in an ascii file, whose format is :called ".poly". : :I found in FAQ, that IRIS Performer 1.2 includes a file loader for :.poly. : :Now, is this just coincidence? Sadly, it is just that. I would never have named my polyhedron file format ".poly" if I had realized that Prisims uses ".poly" and ".bpoly". I'll rename the "/usr/src/Performer/friends/models/poly" datasets to something else (".euclid" ?) for the next release of IRIS Performer. I later recieved information about Prisims and a working loader for Prisims files into IRIS Performer does now exist. We will be working with Side Effects to get this support released for those users who use their modeling tools. This will be important since Prisims provides such complete support for animated characters and that's a big topic now in the many companies where IRIS Performer is being used to build interactive entertainment applications. Let me know if you want to help test the Prisims loaders. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 08:06:31 1994 From: "Michael Jones" Message-Id: <9406030806.ZM29961@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 08:06:21 -0700 In-Reply-To: Richard Gallery "How to relect/mirror a Performer window" (May 19, 11:11am) References: <9403240123.AA06427@holodeck.asd.sgi.com> <9405191111.ZM24648@unknown.zmail.host> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Richard Gallery , info-performer@sgi.sgi.com Subject: Re: How to relect/mirror a Performer window Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 19, 11:11am, Richard Gallery wrote: > Subject: How to relect/mirror a Performer window :Hi : :I have an application where I wish to relect or mirror :the viewport of a Performer window. Specifically, I :need to do this for a home-grown HMD that requires :mirrored images for correct display, but also I can :imagine situations such as a car simulator, in which :the user sees a mirrored image representing the view :out the back window of the car simulator that they are :driving, in which it would be necessary to do this. Several ideas are at work here. Pick and choose from: 1. Compute a mirror projection DCS and change the culling mode to be the opposite: cull-front and draw back faces. 2. Compute the virtual eyepoint and render a channel with that eyepoint. Like this: + virtual eye \ \ -------- mirror / / + normal eye -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 08:12:53 1994 From: "Michael Jones" Message-Id: <9406030812.ZM29983@babar.asd.sgi.com> Date: Fri, 3 Jun 1994 08:12:41 -0700 In-Reply-To: "Simon Kelsall" "Inventor2Performer" (May 12, 5:15pm) References: <9405121715.ZM1149@haddaway.reading.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Simon Kelsall" , info-performer@sgi.sgi.com Subject: Re: Inventor2Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On May 12, 5:15pm, Simon Kelsall wrote: > Subject: Inventor2Performer :Hello, : :Have I just dreamt this or is there an Inventer to Performer (.flt) :converter. :I need to modify a database I have in Inventor format using Multigen :and then load it into a performer application. Alas, 'twas but a dream. There *is* an IRIS Inventor datafile loader for IRIS Performer 1.2, but we ship no function to dump out a complete scene graph in the Software Systems FLIGHT format. Do you really need what you're asking for? If all you want to do is fly through an Inventor file with the speed that Performer can provide, all you need is the Inventor loader. A basic loader for the IRIS Inventor format comes with IRIS Performer 1.2, and a more elaborate loader is also available from me for testing. Let me know. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 3 08:20:31 1994 Return-Path: Message-Id: <9406031519.AA51924@ns.trl.ibm.com> To: info-performer@sgi.sgi.com Cc: ohbuchi@trl.ibm.co.jp, miyazawt@trl.ibm.co.jp, aono@trl.ibm.co.jp, ssuda@vnet.ibm.co.jp Subject: Re: .poly and Prisms In-Reply-To: "Michael Jones" Your message of "Fri, 03 Jun 1994 07:59:22 MST." <9406030759.ZM29911@babar.asd.sgi.com> Date: Sat, 04 Jun 1994 00:19:49 +0900 From: hirota@trl.ibm.co.jp Status: O > On May 24, 9:45pm, hirota@trl.ibm.co.jp wrote: > > Subject: .poly and Prisms > :Roughly speaking, Prisms is an animation package like SoftImage or > :Wavefront, and is developed by a Canadian company, Side Effects > :Software Inc. > : > :The software can save polygon data in an ascii file, whose format is > :called ".poly". > : > :I found in FAQ, that IRIS Performer 1.2 includes a file loader for > :.poly. > : > :Now, is this just coincidence? > > Sadly, it is just that. I would never have named my polyhedron > file format ".poly" if I had realized that Prisims uses ".poly" and > ".bpoly". I'll rename the "/usr/src/Performer/friends/models/poly" > datasets to something else (".euclid" ?) for the next release of > IRIS Performer. > > I later recieved information about Prisims and a working loader > for Prisims files into IRIS Performer does now exist. We will be > working with Side Effects to get this support released for those > users who use their modeling tools. > > This will be important since Prisims provides such complete > support for animated characters and that's a big topic now > in the many companies where IRIS Performer is being used to > build interactive entertainment applications. > > Let me know if you want to help test the Prisims loaders. > Of course I want. I have a data set from Veiwpoint in .poly format, so first of all, I'd like to try it. Prisms itself will be available for us soon, then more intensive tests will be possible. Thanks ---------------------------------- Gentaro Hirota IBM Japan, Ltd. e-mail : hirota@trl.ibm.co.jp telephone : +81-462-73-4926 facsimili : +81-462-73-7428 From guest Fri Jun 3 10:10:10 1994 Date: Fri, 3 Jun 94 18:59:42 +0200 From: fsanchez@viva.paris.sgi.com (FRANCOIS SANCHEZ) Message-Id: <9406031659.AA13532@viva.paris.sgi.com> To: info-performer@giraffe Subject: pfChanPick on secondary channel Status: O A developer writing a multichannel Performer application on RE (no MCO option - Irix 5.2 Performer 1.2), claims than pfChanPick only works on the main channel . Is there any restriction or is it a user error? I tried to reproduce that with pickfly -c but I'm not sure what I'm doing since it mentions MCO settings Thank you Francois Sanchez From guest Fri Jun 3 11:47:55 1994 From: "Wade Olsen" Message-Id: <9406031137.ZM7526@fnord.asd.sgi.com> Date: Fri, 3 Jun 1994 11:37:22 -0700 In-Reply-To: fraser@BanffCentre.AB.CA (Glen Fraser) "Re: real-time video in texture memory" (Jun 3, 10:59am) References: <9406031659.AA11938@moose.BanffCentre.AB.CA> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: fraser@BanffCentre.AB.CA (Glen Fraser) Subject: Re: real-time video in texture memory Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 3, 10:59am, Glen Fraser wrote: > Subject: Re: real-time video in texture memory > > Yes. How depends on where the video comes from: > > > > If the video comes from an external source (e.g. a camera, vcr...) and you > < stuff deleted > > > > If the video comes from memory, like little animation sequences, then no > < stuff deleted > > > > What about if the video comes from disk? Is there some suitable way > of getting long pre-generated animations from disk into texture memory > in or near real-time? Is there an SGI animation format which would > facilitate this? > > Thanks, > Glen. Video from disk is dealt with the same way as video from memory, with the added task of reading the frames from disk to memory. There are a number of tools availble to deal with video. Check out the dmedia (digital media) development stuff. Unfortunatly, I don't know much about it. One thing to think about when choosing how to store the data on disk is it should be read into memory in the format expected by texdef2d or subtexload (i.e. scanlines are padded to 4 bytes, see "pixmode" also). The best way to do video from disk to graphics is to "sproc" another process to do disk I/O or to use the asynchronous I/O commands (see "man aio_init"). The disk process should be busy reading the next frame or frames while the graphics process is using a frame that has already been loaded. The processes could be synchronized using semaphores (see "man usnewsema"). Here is a c++ library I used to do fast disk I/O for video. It sets up a another process to read ahead: ----------------------------------file_io.h-------------------------------- class file_io { public: file_io(char * file_name, int mode); ~file_io(); virtual void read(void * buffer, int start_block, int num_blocks); virtual void write(void * buffer, int start_block, int num_blocks); protected: int file_handle; char * file_name; }; class raw_file_io : public file_io { public: raw_file_io(char * file_name, int mode, int first_block); virtual void read(void * buffer, int start_block, int num_blocks); virtual void write(void * buffer, int start_block, int num_blocks); private: int first_block; }; file_io * open_a_file(char * name, int start_block); file_io * create_a_file(char * name, int start_block); ----------------------------------file_io.c++------------------------------ #include #include #include #include #include #include #include #include #include #include "file_io.h" #define BLOCKSIZE 512 static char * raw_name = "/dev/rdsk/"; file_io * open_a_file(char * name, int start_block) { file_io * f; if (strncmp(raw_name, name, strlen(raw_name)) == 0) f = new raw_file_io(name, O_RDONLY, start_block); else f = new file_io(name, O_RDONLY); return f; } file_io * create_a_file(char * name, int start_block) { file_io * f; if (strncmp(raw_name, name, strlen(raw_name)) == 0) f = new raw_file_io(name, O_WRONLY|O_CREAT, start_block); else f = new file_io(name, O_WRONLY|O_CREAT); return f; } file_io::file_io(char * name, int mode) { file_name = name; file_handle = open(file_name, mode, 0644); if (file_handle < 0) { fprintf(stderr, "Can't open file %s: %s.\n", file_name, strerror(errno)); exit(1); } } file_io::~file_io() { close(file_handle); } raw_file_io::raw_file_io(char * name, int mode, int start) : file_io(name, mode) { first_block = start; } void file_io::read(void * buffer, int block, int blocks) { long err = lseek(file_handle, block * BLOCKSIZE, SEEK_SET); if (err == -1) { fprintf(stderr, "Can't seek to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } err = ::read(file_handle, buffer, blocks * BLOCKSIZE); if (err == -1) { fprintf(stderr, "Can't read from block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } void file_io::write(void * buffer, int block, int blocks) { long err = lseek(file_handle, block * BLOCKSIZE, SEEK_SET); if (err == -1) { fprintf(stderr, "Can't seek to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } err = ::write(file_handle, buffer, blocks * BLOCKSIZE); if (err == -1) { fprintf(stderr, "Can't write from block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } void raw_file_io::read(void * buffer, int block, int blocks) { long err = syssgi(SGI_READB, file_handle, buffer, block + first_block, blocks); if (err == -1) { fprintf(stderr, "Can't read to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } void raw_file_io::write(void * buffer, int block, int blocks) { long err = syssgi(SGI_WRITEB, file_handle, buffer, block + first_block, blocks); if (err == -1) { fprintf(stderr, "Can't write to block %0d in %s: %s.\n", block, file_name, strerror(errno)); exit(1); } } ----------------------------------reader.h------------------------------- #include #include #include #include "file_io.h" class reader { public: reader(int numbuffers, int buffer_size, file_io * file, int transfers); unsigned long * read(); private: usema_t * produce_sema; usema_t * consume_sema; int produce_buffer; int consume_buffer; file_io * file_handle; int num_buffers; unsigned long ** buffers; void read_data(); pid_t reader_task; pid_t parent_task; int transfers; // image buffer parameters int blocks_per_transfer; }; -----------------------------------reader.c++------------------------------ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "reader.h" reader::reader(int numbuffers, int buffer_size, file_io * file, int trans) { transfers = trans; usptr_t * arena = usinit("/usr/tmp/raw_arena"); produce_sema = usnewsema(arena, 0); consume_sema = usnewsema(arena, 0); produce_buffer = 0; consume_buffer = 0; file_handle = file; blocks_per_transfer = buffer_size; if (blocks_per_transfer == 0) { fprintf(stderr, "reader: transfer size is zero!\n"); exit(1); } num_buffers = numbuffers; int bytes_per_transfer = blocks_per_transfer * 512; fprintf(stderr, "Allocating %0d buffers of %0d bytes\n", num_buffers, bytes_per_transfer); buffers = (unsigned long **) malloc(sizeof(unsigned long *) * num_buffers); for (int i = 0; i < num_buffers; i++) { buffers[i] = (unsigned long *) malloc(sizeof(unsigned long) * bytes_per_transfer); if (mpin (buffers[i], bytes_per_transfer)) fprintf(stderr, "Can't pin %0d bytes for buffer %0d: %s\n", bytes_per_transfer, i, strerror(errno)); } usinitsema(produce_sema, num_buffers -1); parent_task = getpid(); reader_task = sproc((void (*)(void *))reader::read_data, PR_SALL, this); } unsigned long * reader::read() { if (ustestsema(produce_sema) == 0) fprintf(stderr, "Waiting for disk reader!\n"); uspsema(consume_sema); /* Wait until the next buffer is available. */ unsigned long * buffer = buffers[consume_buffer]; consume_buffer = (consume_buffer + 1) % num_buffers; usvsema(produce_sema); /* Wake the reader. */ return buffer; } void reader::read_data() { prctl(PR_TERMCHILD); while (1) for (int i = 0; i < transfers; i++) { uspsema(produce_sema); /* Wait for an empty buffer. */ int read_block = (i + 1) * blocks_per_transfer; file_handle->read(buffers[produce_buffer], read_block, blocks_per_transfer); usvsema(consume_sema); /* Wake the consumer, the frame is ready. */ produce_buffer = (produce_buffer +1) % num_buffers; } } --------------------------------------------------------------------------- Wade -- ------------------------------------------------------------------------------- Wade Olsen, wade@sgi.com, 415-390-1023, Silicon Graphics Computer Systems From guest Fri Jun 3 13:21:45 1994 From: "Bob Buckley" Message-Id: <9406031250.ZM21460@grimmy.mss.ctaeng.com> Date: Fri, 3 Jun 1994 12:50:48 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Spot lights/landing light lobes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 753 Status: O What would be the proper technique to model landing light lobes or spot lights in Performer? With the assumption that these are accomplished by direct GL calls are there any plans to incorporate these capabilities into Performer functionality? Thanks. =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Fri Jun 3 15:16:13 1994 From: "Sharon Fischler" Message-Id: <9406031515.ZM18966@rose.asd.sgi.com> Date: Fri, 3 Jun 1994 15:15:54 -0700 In-Reply-To: reedwhit@skips.dseg.ti.com (Reed Whittington) "Fun with pfChanPick" (May 31, 9:07pm) References: <9406010207.AA10582@skips.dseg.ti.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: reedwhit@skips.dseg.ti.com (Reed Whittington), iris-performer@sgi.sgi.com Subject: Re: Fun with pfChanPick Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O +>---- On May 31, 9:07pm, Reed Whittington wrote: > Subject: Fun with pfChanPick -> [ ... ] ->I also have found that pfChanViewOffsets don't get accounted for ->in pfChanPick. I'm afraid that this is indeed true. The pick traversal looks at the current view(xyz,hpr), near/far, and fov. You will have to set the Channel Viewpoint in each of the channels individually, or set/reset around the pick traversal. This may also account for some troubles other folks have been having doing picking on secondary channels. Thanx for the report! srf. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Fri Jun 3 19:07:47 1994 From: hildebra@vsl.ist.ucf.edu (Andrew Hildebrand ) Message-Id: <9406040206.AA07566@onyx.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: Performer 1.2 Bounding Spheres Status: O I have a question about the bounding spheres in Performer 1.2. I have been trying to do collision detection between 2 objects using pfSphereIsectSphere. The 2 objects are in Flight format and are set up as DCSs. I get the bounding sphere from the DCS and then check to see if the 2 objects are intersecting. I get different results than what appears to be happening. I get a result of maybe|true if the objects are nowhere near each other I printed out the scene and found that the DCS bounding sphere is moving with the object, but the Geode bounding sphere beneath the DCS is not moving, is this a BUG???? ALSO if anyone has sample code for collision detection between 2 objects that are DCSs, I would love to see it. THANKS ______________________________________________________________________________ Andrew Hildebrand The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) hildebra@vsl.ist.ucf.edu _______________________________________________________________________________ From guest Fri Jun 3 20:09:56 1994 Message-Id: <9406040309.AA15701@surreal.asd.sgi.com> To: hildebra@vsl.ist.ucf.edu (Andrew Hildebrand ) Cc: info-performer@sgi.sgi.com Subject: Re: Performer 1.2 Bounding Spheres In-Reply-To: Your message of "Fri, 03 Jun 94 22:06:54 EDT." <9406040206.AA07566@onyx.vsl.ist.ucf.edu> Date: Fri, 03 Jun 94 20:09:35 -0700 From: Jim Helman Status: O > I printed out the scene and found that the DCS bounding sphere > is moving with the object, but the Geode bounding sphere beneath > the DCS is not moving, is this a BUG???? Not a bug. When you get the bounding volume on a geode, the bounding volume contains the geometry beneath it without any regard to what lies above it in the scene graph. That's how hierarchical bounding volumes work. It's really the only way. Suppose the geode were instanced several times in the scene graph under different DCSes. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Jun 6 03:51:28 1994 Message-Id: From: crux@artcom.de (Dirk Luesebrink) Subject: multi threading with libpf objects To: info-performer@sgi.sgi.com Date: Mon, 6 Jun 1994 12:50:29 +0100 (MDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1822 Status: O hi there, i'm searching for a way to make it safe to create libpf objects from a thread. im now running in APP_CULL_DRAW mode. the application process make an sproc for a communication thread which takes cmds from the outside world. one such command is "load world". then in this thread a loader is started which shuold create the performer tree which belongs to that world. if this is finished the thread terminates. the new tree is then added to the rest by adding it to group node. This happens in the application process. for most of my testmodels this mechanism works fine most of the time. when i make APPCULLDRAW it work in general. the problem is, that with more complicated scenes to load, i get Performer Warning (13): Attempt to modify deleted object but still most of the time it works, but sometimes it dumpes core. now i tried the following. // main simulation loop while (!Shared->exitFlag) { pfSync(); viewer->update(); plexControl.stopAll(); pfFrame(); plexControl.contAll(); updateScene(); } there stopAll and contAll will stop (cont) all threads which are started from somewhere in the application. the idea is, to have the extra threads in perfect sync with the application process. when i do that, Performer Warning (13) disapears. so far so good. But, then after while of loading, the whole applicatio wil hang. pfFrame does not return any more. it looks like one of the threads aquires some resources, then gets blocked, pfFrame starts and waits for that resource, but will never get it because the holding thread is stopped. off course i could stop the application for running completly through the thread and continue afterwards, but thats not what i want. any help or hint is greatly appriciated. dirk Luesebrink From guest Mon Jun 6 10:31:27 1994 Message-Id: <199406061731.MAA01666@jadoube> Subject: WIREFRAME toggling question To: info-performer@sgi.sgi.com Date: Mon, 6 Jun 1994 12:31:14 -0500 (CDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1219 Status: O Hello Fellow Performers: We are attempting to toggle wireframe in our GeoState model by setting pfGStateMode(gstates[i], PFSTATE_ENWIREFRAME, PF_ON); then, by pfApplyGState(gstate[i]) where `i` is the particular part of the model we are interested in toggling. However, instead of applying the wireframe mode locally to the particular part, the entire GeoSet (ie. gstates[0] .. gstates[n]) gets switched to wireframe. -- What gives? Interestingly enough, when we first define these geostates, we don't need to use "pfApplyGState" and we can have different parts with different "pfGStateModes". The difficulty seems to come in when we try to do toggling. Also, does anyone know of a performer site which houses all the traffic on this newsgroup, and/or bonus code samples, etc. ? Nihar Gokhale Graphics/Animation Group Mathematics and Computer Sciences Division Argonne National Laboratory Argonne, Illinois USA 60439 /\\ gokhale@mcs.anl.gov // \\ 708-252-2815 (voice) //_ o _\\ 708-252-5986 (FAX) \- --/ Mosaic: http://www.mcs.anl.gov/home/gokhale/gokhale.html The goal of Computer Science is to build something that will last at least until we've finished building it. From guest Mon Jun 6 11:05:19 1994 From: "Michael Jones" Message-Id: <9406061105.ZM4523@babar.asd.sgi.com> Date: Mon, 6 Jun 1994 11:05:01 -0700 In-Reply-To: Nihar Gokhale "WIREFRAME toggling question" (Jun 6, 12:31pm) References: <199406061731.MAA01666@jadoube> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Nihar Gokhale , info-performer@sgi.sgi.com Subject: Re: WIREFRAME toggling question Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 6, 12:31pm, Nihar Gokhale wrote: > Subject: WIREFRAME toggling question : :Hello Fellow Performers: : :We are attempting to toggle wireframe in our GeoState :model by setting : : pfGStateMode(gstates[i], PFSTATE_ENWIREFRAME, PF_ON); : :then, by : : pfApplyGState(gstate[i]) : :where `i` is the particular part of the model we :are interested in toggling. All you need is the first part of this, which specifies the wireframe mode for those geosets you care about. The apply() function is called for you during the traversal. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Jun 6 11:49:14 1994 Message-Id: <9406061848.AA07753@sgi.sgi.com> Date: 6 Jun 94 14:37:00 EST From: "Robert Reif" Subject: stereo version of libpfutil xwin.c ? To: "info-performer" Status: O Does anyone have a modified version of the libpfutil module xwin.c that supports stereo on an ONYX RE2? Thanks. Robert Reif reif@ntsc-rd.navy.mil From guest Mon Jun 6 15:44:54 1994 From: "Drew Hess" Message-Id: <9406061346.ZM4341@airy.arc.nasa.gov> Date: Mon, 6 Jun 1994 13:46:20 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfFog and fog density Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I need to explicitly set the fog density parameter of Performer fog. As far as I can tell the only way to do this is with PFFOG_PIX_SPLINE, but what I'd actually like to do is use PFFOG_PIX_EXP or PFFOG_VTX_EXP. Basically I need the extra parameter that fogvertex(3G) uses for density, but in looking at the Performer documentation it's not clear how to do this without going to the GL, which I'd like to avoid if possible. It appears that the only controls over fog, besides with the SPLINE type, are color and the near and far fog planes. Am I missing something obvious? How does Performer calculate the density parameter for fog by default? Thanks -dwh- dhess@vision.arc.nasa.gov From guest Mon Jun 6 14:03:23 1994 Date: Mon, 6 Jun 94 17:06:24 -0400 Message-Id: <9406062106.AA18911@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com From: darken@enews.nrl.navy.mil (Rudy Darken) Subject: line rendering in performer Cc: darken@enews.nrl.navy.mil X-Attachments: :Macintosh HD:2:email.txt: Status: O I've had this problem before but have never found the solution. If you include the function LoadGrid (below) in with a typical performer application like smallfly which is rendering geometry, what you get is interference in the graphics state from the other geometry when rendering the lines. When I have this grid loaded exactly as written here while running "smallfly esprit.flt" (my call is "LoadGrid (clr, 100, 1)" where clr={0, 0, 1, 1}) I get a blue grid (as expected) as long as the car is not in view. If the car is in view, the grid changes to some other color which seems to be different depending on what type of machine I'm on. Furthermore, this behavior changes with distance from the geometry. From far off, it will look fine. As you get close to the car, the grid will change colors. In a typical application, the effect is line rendering which flickers greatly. We have never been able to render anything in performer with line geometry like this which has operated as expected. We'd appreciate any comments you might have or if you can try this, let us know how it works for you. Thanks. Rudy _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ /* * Build a geode of color of square size extent x extent with spacing * between lines of gap. */ #define Z 0.0f; pfGeode * LoadGrid (pfVec4 color, long extent, long gap) { long numLines; void *arena; pfGeode *geode; pfMaterial *material; pfGeoState *geostate; pfGeoSet *gset; pfVec3 *vertices; pfVec4 *colors; short ctr, i, j, c; if (extent % gap) { pfNotify (PFNFY_WARN, PFNFY_RESOURCE, "Extent not divisible by gap"); return NULL; } arena = pfGetSharedArena (); geode = pfNewGeode (); /*material = pfNewMtl (arena);*/ /*pfMtlColor (material, PFMTL_AMBIENT, color[0], color[1], color[2]);*/ /*pfMtlColor (material, PFMTL_DIFFUSE, color[0], color[1], color[2]);*/ /*pfMtlColorMode (material, PFMTL_FRONT, LMC_AD);*/ geostate = pfNewGState (arena); /*pfGStateAttr (geostate, PFSTATE_FRONTMTL, material);*/ /*pfGStateMode (geostate, PFSTATE_CULLFACE, PFCF_OFF);*/ gset = pfNewGSet (arena); pfGSetPrimType (gset, PFGS_LINES); /*pfGSetGState (gset, geostate);*/ numLines = 2 * ((extent / gap)+1); vertices = (pfVec3 *) pfMalloc (numLines * 2 * sizeof (pfVec3), arena); colors = (pfVec4 *) pfMalloc (numLines * 2 * sizeof (pfVec4), arena); pfGSetNumPrims (gset, numLines); ctr = 0; for (i=-(extent/2), c=0; c<2; c++) { if (!c) { for (j=-(extent/2); j<=(extent/2); j+=gap) { vertices[ctr][0] = i; vertices[ctr][1] = j; vertices[ctr++][2] = Z; vertices[ctr][0] = -i; vertices[ctr][1] = j; vertices[ctr++][2] = Z; } } else { for (j=-(extent/2); j<=(extent/2); j+=gap) { vertices[ctr][0] = j; vertices[ctr][1] = i; vertices[ctr++][2] = Z; vertices[ctr][0] = j; vertices[ctr][1] = -i; vertices[ctr++][2] = Z; } } } for (i=0; i Message-Id: <9406061620.ZM4967@babar.asd.sgi.com> Date: Mon, 6 Jun 1994 16:20:46 -0700 In-Reply-To: "Drew Hess" "pfFog and fog density" (Jun 6, 1:46pm) References: <9406061346.ZM4341@airy.arc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Drew Hess" , info-performer@sgi.sgi.com Subject: Re: pfFog and fog density Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 6, 1:46pm, Drew Hess wrote: > Subject: pfFog and fog density :I need to explicitly set the fog density parameter of Performer fog. As far as :I can tell the only way to do this is with PFFOG_PIX_SPLINE, but what I'd :actually like to do is use PFFOG_PIX_EXP or PFFOG_VTX_EXP. No problem. To quote from the new IRIS Performer 1.2 Programming Guide: "You can set the near and far edges of the fog with pfFogRange(). For exponential fog functions, the near edge of fog is always zero in eye coordinates. The near edge is where the onset of fog blending occurs, and the far edge is where all pixels are 100% fog color." :Basically I need the extra parameter that fogvertex(3G) uses for density, but :in looking at the Performer documentation it's not clear how to do this without :going to the GL, which I'd like to avoid if possible. The opaque distance is (in a sense) equivalent to the density. Since fog density is a function of distance, it's possible to define fog as a (density, distance) pair. It was decided to use an implied density=1 in the IRIS Performer API such that "at the opaque fog range, the fog density is 1.0". Given this, only the distance need be specified. If f = 1 - e**(-k*d), and you want to specify the general (f,d) pair, just solve for the appropriate f=1 case and use the new d' in your IRIS Performer calls. The only problem here is that you can't really solve for f=1 above and need to accept 255/256th's or so. :It appears that the only controls over fog, besides with the SPLINE type, are :color and the near and far fog planes. Am I missing something obvious? How :does Performer calculate the density parameter for fog by default? The opaque and opaqueOffest parameters are used to define the density in the fogvertex() command as shown in this code extract (from IRIS Performer's fog application code): switch (fog->type) { case PFFOG_VTX_LIN: case PFFOG_PIX_LIN: props[0] = fog->onset + fog->onsetOffset; props[1] = fog->opaque + fog->opaqueOffset; if (props[1] < props[0]) props[1] = props[0]; props[2] = fog->color[0]; props[3] = fog->color[1]; props[4] = fog->color[2]; break; case PFFOG_VTX_EXP: case PFFOG_PIX_EXP: case PFFOG_VTX_EXP2: case PFFOG_PIX_EXP2: props[0] = 1.0f/(fog->opaque + fog->opaqueOffset); props[1] = fog->color[0]; props[2] = fog->color[1]; props[3] = fog->color[2]; break; -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Jun 6 16:53:59 1994 Message-Id: <9406062353.AA26896@surreal.asd.sgi.com> To: darken@enews.nrl.navy.mil (Rudy Darken) Cc: info-performer@sgi.sgi.com Subject: Re: line rendering in performer In-Reply-To: Your message of "Mon, 06 Jun 94 17:06:24 EDT." <9406062106.AA18911@enews.nrl.navy.mil> Date: Mon, 06 Jun 94 16:53:48 -0700 From: Jim Helman Status: O Try adding: pfGStateMode(geostate, PFSTATE_ENTEXTURE, PF_OFF); to the geostate you use for rendering the lines. By default, Performer enables texturing (pfEnable(PFEN_TEXTURE)) when it initializes graphics state on machines with fast texturing. You haven't turned texturing off for this pfGeoState, so it inherits the texture enable. Unfortunately, this means that you get the color of whatever texel coresponded to the last texture coordinate sent down the pipe. (We do things this way because it's more efficient to specify the most common setting of a mode in the global state and leave it unspecified in the individual pfGeoStates. Since most FLT databases are textured, the FLT loader doesn't enable texture explicitly in every pfGeoState instead leaving it to be inherited from the default state.) rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Jun 6 17:51:55 1994 From: "Michael Jones" Message-Id: <9406061751.ZM6361@babar.asd.sgi.com> Date: Mon, 6 Jun 1994 17:51:41 -0700 In-Reply-To: darken@enews.nrl.navy.mil (Rudy Darken) "line rendering in performer" (Jun 6, 5:06pm) References: <9406062106.AA18911@enews.nrl.navy.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com Subject: Re: line rendering in performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Actually, the problem is that the geoset you build does not specify a geostate at all -- the code that binds the new geostate to the geoset's been commented out. What does this mean? It means that you are explicitly saying to IRIS Performer "I don't care what the state of the graphics pipeline is -- just draw the geometry and hope for the best". In your case, as you move about, the sorting of libpf is changing what gets drawn just before the grid: sometimes the sky, sometimes a textured part of the car, etc. Whatever it is, it's color and material properties are used by your grid. If you change it to use the newly created geostate, then you'll not have this problem. Or, you could specify appearance properties in the geostate that would cause the grid to always be drawn with the same graphics state. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Jun 7 11:54:34 1994 id AA21642; Tue, 7 Jun 94 11:53:46 -0700 Date: Tue, 7 Jun 1994 11:53:45 +0059 (PDT) From: Paul Bishop Skibitzke Subject: Please excuse me... To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O ...for posting to you all, but I was told about this mailing list by a friend who didnt know the info on how to get subscribed on this mailing list +****************************************************************************+ = Paul B. Skibitzke = = San Diego Supercomputer Center = = Sonification Project / "In The Bag" Virtual Shopping Mall Project = = pauls@sdsc.edu = =++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= From guest Tue Jun 7 06:47:57 1994 Date: Tue, 7 Jun 94 15:47:40 +0200 From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) Message-Id: <9406071347.AA01270@ligsg16.epfl.ch> To: info-performer@sgi.sgi.com Subject: windows / NURBS Reply-To: matomira@epfl.ch Status: O Hello, I have two questions. When are we getting: a) The ability to open/destroy windows arbitrarily at runtime? b) NURBS Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Tue Jun 7 09:06:22 1994 Date: Tue, 7 Jun 94 12:09:21 -0400 Message-Id: <9406071609.AA28383@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com From: darken@enews.nrl.navy.mil (Rudy Darken) Subject: line rendering in performer (the sequel) Cc: darken@enews.nrl.navy.mil Status: O What I want to do is the following: 1. Create a geode 2. Create a material 3. Set the material colors (diffuse & ambient) 4. Create line geometry 5. Bind the material to the lines 6. Return the geode for inclusion in the performer rendering database It would seem that this should be a common thing to want to do. Obviously, I want the material properties of the lines to remain constant throughout the process. I don't want them inheriting state from other geometry. In fact, since line rendering does not benefit greatly by a lighting model, I don't even care if they are lighted, provided other objects in my scene still can be. I have tried all suggestions so far with the same results. Hasn't anyone rendered lines before? How do you get line geometry to keep its state without inheriting? void *arena; pfGeode *geode; pfMaterial *material; pfGeoState *geostate; pfGeoSet *gset; pfVec3 *vertices; pfVec4 *colors; arena = pfGetSharedArena (); geode = pfNewGeode (); material = pfNewMtl (arena); pfMtlColor (material, PFMTL_AMBIENT, color[0], color[1], color[2]); pfMtlColor (material, PFMTL_DIFFUSE, color[0], color[1], color[2]); // What goes here? // pfMtlColorMode ()? // pfMtlSide ()? geostate = pfNewGState (arena); // Is this correct? pfGStateAttr (geostate, PFSTATE_FRONTMTL, material); pfGStateMode (geostate, PFSTATE_CULLFACE, PFCF_OFF); gset = pfNewGSet (arena); pfGSetPrimType (gset, PFGS_LINES); pfGSetGState (gset, geostate); // Load geometry here pfGSetAttr (gset, PFGS_COORD3, PFGS_PER_VERTEX, vertices, NULL); pfGSetAttr (gset, PFGS_COLOR4, PFGS_PER_VERTEX, colors, NULL); pfAddGSet (geode, gset); return geode; _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From guest Tue Jun 7 10:43:49 1994 From: "Michael Jones" Message-Id: <9406071043.ZM7605@babar.asd.sgi.com> Date: Tue, 7 Jun 1994 10:43:36 -0700 In-Reply-To: darken@enews.nrl.navy.mil (Rudy Darken) "line rendering in performer (the sequel)" (Jun 7, 12:09pm) References: <9406071609.AA28383@enews.nrl.navy.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com Subject: Re: line rendering in performer (the sequel) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 7, 12:09pm, Rudy Darken wrote: > Subject: line rendering in performer (the sequel) : : void *arena; : pfGeode *geode; : pfMaterial *material; : pfGeoState *geostate; : pfGeoSet *gset; : pfVec3 *vertices; : pfVec4 *colors; : : arena = pfGetSharedArena (); : geode = pfNewGeode (); : material = pfNewMtl (arena); : pfMtlColor (material, PFMTL_AMBIENT, color[0], color[1], color[2]); : pfMtlColor (material, PFMTL_DIFFUSE, color[0], color[1], color[2]); : : // What goes here? : // pfMtlColorMode ()? : // pfMtlSide ()? /* Here's what you need */ pfMtlColorMode(material, PFMTL_FRONT, LMC_AD); : geostate = pfNewGState (arena); : : // Is this correct? : pfGStateAttr (geostate, PFSTATE_FRONTMTL, material); : pfGStateMode (geostate, PFSTATE_CULLFACE, PFCF_OFF); : : gset = pfNewGSet (arena); : pfGSetPrimType (gset, PFGS_LINES); : pfGSetGState (gset, geostate); : // Load geometry here : pfGSetAttr (gset, PFGS_COORD3, PFGS_PER_VERTEX, vertices, NULL); : pfGSetAttr (gset, PFGS_COLOR4, PFGS_PER_VERTEX, colors, NULL); : pfAddGSet (geode, gset); : return geode; -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Jun 7 11:17:48 1994 Date: Tue, 7 Jun 94 14:20:49 -0400 Message-Id: <9406071820.AA01623@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com From: darken@enews.nrl.navy.mil (Rudy Darken) Subject: line rendering in performer (part 3) Cc: darken@enews.nrl.navy.mil Status: O Summary: What I want to do is the following: 1. Create a geode 2. Create a material 3. Set the material colors (diffuse & ambient) 4. Create line geometry 5. Bind the material to the lines 6. Return the geode for inclusion in the performer rendering database This is the third pass at this problem. There have been two suggestions made by Michael Jones and Jim Helman which have been incorporated into the code stub below. The problem persists. When the only object in view is the grid, it is drawn in blue (as expected). However, when another object enters the view, the grid loses its color and goes dark. I have this code written into smallfly so it is the only non-sgi code in the application. The problem has to be in the way I define the geostate for the grid. >It would seem that this should be a common thing to want to do. Obviously, >I want the material properties of the lines to remain constant throughout >the process. I don't want them inheriting state from other geometry. In >fact, since line rendering does not benefit greatly by a lighting model, >I don't even care if they are lighted, provided other objects in my scene >still can be. I have tried all suggestions so far with the same results. >Hasn't anyone rendered lines before? How do you get line geometry to keep >its state without inheriting? void *arena; pfGeode *geode; pfMaterial *material; pfGeoState *geostate; pfGeoSet *gset; pfVec3 *vertices; pfVec4 *colors; arena = pfGetSharedArena (); geode = pfNewGeode (); material = pfNewMtl (arena); pfMtlColor (material, PFMTL_AMBIENT, 0.0f, 0.0f, 1.0f); pfMtlColor (material, PFMTL_DIFFUSE, 0.0f, 0.0f, 1.0f); // Michael Jones had me add this line pfMtlColorMode (material, PFMTL_FRONT, LMC_AD); geostate = pfNewGState (arena); pfGStateAttr (geostate, PFSTATE_FRONTMTL, material); pfGStateMode (geostate, PFSTATE_CULLFACE, PFCF_OFF); // Jim Helman had me add this line pfGStateMode (geostate, PFSTATE_ENTEXTURE, PF_OFF); gset = pfNewGSet (arena); pfGSetPrimType (gset, PFGS_LINES); pfGSetGState (gset, geostate); // Load geometry here pfGSetAttr (gset, PFGS_COORD3, PFGS_PER_VERTEX, vertices, NULL); pfGSetAttr (gset, PFGS_COLOR4, PFGS_PER_VERTEX, colors, NULL); pfAddGSet (geode, gset); return geode; _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From guest Tue Jun 7 12:41:30 1994 Message-Id: <9406071941.AA13906@surreal.asd.sgi.com> To: darken@enews.nrl.navy.mil (Rudy Darken) Cc: info-performer@sgi.sgi.com Subject: Re: line rendering in performer (part 3) In-Reply-To: Your message of "Tue, 07 Jun 94 14:20:49 EDT." <9406071820.AA01623@enews.nrl.navy.mil> Date: Tue, 07 Jun 94 12:41:20 -0700 From: Jim Helman Status: O For the same reason as with texturing, the default in perfly is to have lighting enabled in the default state. If you're not specifying normals with the lines and have lighting explicitly enabled or inherited, you'll just get lighting from whatever normal was sent to the pipe last via GL. Try: pfGStateMode(gs, PFSTATE_ENTEXTURE, PF_OFF); pfGStateMode(gs, PFSTATE_ENLIGHTING, PF_OFF); Or bind normals to the pfGeoSet. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 7 12:57:27 1994 Message-Id: <9406071957.AA13960@surreal.asd.sgi.com> To: matomira@epfl.ch Cc: info-performer@sgi.sgi.com Subject: Re: windows / NURBS In-Reply-To: Your message of "Tue, 07 Jun 94 15:47:40 +0200." <9406071347.AA01270@ligsg16.epfl.ch> Date: Tue, 07 Jun 94 12:57:18 -0700 From: Jim Helman Status: O > a) The ability to open/destroy windows arbitrarily at runtime? This is complicated when multiprocessed because it requires creating and destroying multiple processes and the associated software pipeline. It's not on the list now. If and when depends on demand. Is this important to people? > b) NURBS NURBS aren't usually regarded as useful for maximum performance rendering. There are two sides to NURBS: tessellation and evaluation. In OpenGL, the GLU library does the tessellation on the host CPU and then calls OpenGL gfx commands to have the graphics hardware evaluate them. Because the tessellation is very CPU intensive, the gfx pipe is left idle during this computation and that means NURBS cannot come close to peak gfx performance. The high-performance path to NURBS rendering would have one or more processes, doing the tessellation and sending the rendering process functions and points for evaluation. As for NURBS and Performer, if you have your own tessellation code, you could either tessellate at load-time or do it at run-time using user data and callbacks in the scene graph. In either case, the DRAW process could just send down points for evaluation. If anyone has an interest in this, I'd like to hear why NURBS are important to you in real-time rendering. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 7 13:37:17 1994 From: "Michael Jones" Message-Id: <9406071337.ZM8021@babar.asd.sgi.com> Date: Tue, 7 Jun 1994 13:37:06 -0700 In-Reply-To: darken@enews.nrl.navy.mil (Rudy Darken) "line rendering in performer (part 3)" (Jun 7, 2:20pm) References: <9406071820.AA01623@enews.nrl.navy.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: darken@enews.nrl.navy.mil (Rudy Darken), info-performer@sgi.sgi.com Subject: Re: line rendering in performer (part 3) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 7, 2:20pm, Rudy Darken wrote: > Subject: line rendering in performer (part 3) :This is the third pass at this problem. There have been two suggestions :made by Michael Jones and Jim Helman which have been incorporated into :the code stub below. The problem persists. When the only object in view :is the grid, it is drawn in blue (as expected). However, when another :object enters the view, the grid loses its color and goes dark. I have :this code written into smallfly so it is the only non-sgi code in the :application. The problem has to be in the way I define the geostate for :the grid. What's your experience with the code below? It's my attempt to draw lines, and seems to work. I added it to Perfly and all seems well. /* * Make a "grid of lines" graphic object */ pfNode * MakeGrid (void) { void *arena = NULL; pfMaterial *material = NULL; pfGeoState *geostate = NULL; pfGeoSet *geoset = NULL; pfGeode *geode = NULL; pfVec3 *v = NULL; pfVec3 *vp = NULL; pfVec4 *c = NULL; int nx = 30; int ny = 30; float x0 = -10.0f; float y0 = -10.0f; float z0 = 5.0f; float x1 = 10.0f; float y1 = 10.0f; float dx = x1 - x0; float dy = y1 - y0; int x; int y; /* access the global shared-memory arena */ arena = pfGetSharedArena(); /* make a material that specifies LMC_AD mode */ material = pfNewMtl(arena); pfMtlColor(material, PFMTL_AMBIENT, 0.1, 0.1, 0.1); pfMtlColor(material, PFMTL_SPECULAR, 0.8, 0.8, 0.8); pfMtlColorMode(material, PFMTL_FRONT, LMC_AD); /* specify material but inherit all other geostate attributes */ geostate = pfNewGState(arena); pfGStateAttr(geostate, PFSTATE_FRONTMTL, material); /* create geoset at attach geostate to it */ geoset = pfNewGSet(arena); pfGSetPrimType(geoset, PFGS_LINES); pfGSetGState(geoset, geostate); /* build and attach vertex array */ vp = v = (pfVec3 *)pfMalloc((2*nx + 2*ny)*sizeof(pfVec3), arena); for (x = 0; x < nx; x++) { pfSetVec3(vp++, x0 + x*dx/(nx-1), y0, z0); pfSetVec3(vp++, x0 + x*dx/(nx-1), y1, z0); } for (y = 0; y < ny; y++) { pfSetVec3(vp++, x0, y0 + y*dy/(ny-1), z0); pfSetVec3(vp++, x1, y0 + y*dy/(ny-1), z0); } pfGSetAttr(geoset, PFGS_COORD3, PFGS_PER_VERTEX, v, NULL); pfGSetNumPrims(geoset, nx + ny); /* build and attach color array */ c = (pfVec4 *)pfMalloc(sizeof(pfVec4), arena); pfSetVec4(c, 1.0f, 0.0f, 0.0f, 1.0f); pfGSetAttr(geoset, PFGS_COLOR4, PFGS_OVERALL, c, NULL); /* create geode and attach geoset to it */ geode = pfNewGeode(); pfAddGSet(geode, geoset); /* return address of geode to caller */ return (pfNode *)geode; } -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Jun 7 13:31:53 1994 Message-Id: <9406072031.AA21080@sgi.sgi.com> From: Robert Rossow Subject: Nurbs... To: info-performer@sgi.sgi.com Date: Tue, 7 Jun 94 16:38:07 EDT Mailer: Elm [revision: 66.25] Status: O I believe that the ability to use NURBS to define geometry within Performer would be extremely beneficial. I understand that these cannot be dynamically tesselated (to a particular view) because of the expense in CPU time. It would be quite helpful if instead the NURBS could be tesselated according to a user-specified chord-height tolerance during initialization; before the real-time simulation loop is entered. If this were the case, many more models would become available, and the user could be relieved of both the tesselation and texture/normal specifications on a per-vertex basis. Also, the levels of detail could be specified by adjusting the chord-height tolerance. Sounds too good to be true. What do you think? Robert Rossow rossow@gsc.gsi.com From guest Tue Jun 7 16:56:39 1994 From: "Drew Hess" Message-Id: <9406071656.ZM6289@airy.arc.nasa.gov> Date: Tue, 7 Jun 1994 16:56:56 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: z-buffer and Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I am trying to set a record for the most questions asked on the info-performer list in one week :) I am hacking the perfly source in an attempt to read z-buffer values for the currently displayed frame. At this point I'm a little overwhelmed by the number of parameters that seemingly can have an effect on the z-buffer at any given time in Performer. For starters, I know I've got to turn off multisampling on an RE2 pipeline in the perfly window (thanks Allan Schaffer). It also seems that pfESkyMode affects the z-buffer (PFES_SKY_GRND should set the z-buffer to a known state, which is what I want, I think). Then there's pfClear() to worry about.... (maybe?) According to the readsource() man page, I should also make sure that drawmode() is NORMALDRAW, which shouldn't be a problem as long as I don't try to read the z-buffer while any GUI elements are being drawn. Ideally, here's what I want to be able to do: readsource(SRC_ZBUFFER); n = lrectread(...., zbuf); /* operate on values in zbuf */ I'd like to get the z-buffer that corresponds to the frame currently being displayed in the viewport. If I'm viewing a runway with a jet and buildings and mountains in the distance, I want to have the correct depth values for these objects. I don't care about real-time performance, though it would be nice to maintain it. Can I lrectread from the z-bufer at any state in Performer, or should I only do this immediately before/after pfDraw(), for example? I believe that on an MP machine, Performer will render multiple frames on different processors to keep up with the requested frame rate; does this mean that the z-buffer could be in an inconsistent state? Thanks for your patience and for any help, -dwh- dhess@vision.arc.nasa.gov dhess@cs.stanford.edu From guest Tue Jun 7 17:48:38 1994 From: "Michael Jones" Message-Id: <9406071748.ZM8482@babar.asd.sgi.com> Date: Tue, 7 Jun 1994 17:48:17 -0700 In-Reply-To: "Drew Hess" "z-buffer and Performer" (Jun 7, 4:56pm) References: <9406071656.ZM6289@airy.arc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Drew Hess" , info-performer@sgi.sgi.com Subject: Re: z-buffer and Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 7, 4:56pm, Drew Hess wrote: > Subject: z-buffer and Performer :I am trying to set a record for the most questions asked on the info-performer :list in one week :) That's what the mailing list is for. :I am hacking the perfly source in an attempt to read z-buffer values for the :currently displayed frame. At this point I'm a little overwhelmed by the :number of parameters that seemingly can have an effect on the z-buffer at any :given time in Performer. Never fear. Info-Performer's here. :For starters, I know I've got to turn off :multisampling on an RE2 pipeline in the perfly window (thanks Allan Schaffer). True. You can't read the multisample Z value. : It also seems that pfESkyMode affects the z-buffer (PFES_SKY_GRND should set :the z-buffer to a known state, which is what I want, I think). All of the clear modes except PFES_TAG will reset the Z-buffer. If your image looks good, then the Z-buffer's in a happy state. :Then there's pfClear() to worry about.... (maybe?) The earth/sky model does the pfClear for you. You can ignore this detail. Just read the Z-buffer *after* calling pfDraw() in the channel draw callback. Look for "PostDraw()" since you're using perfly. :According to the readsource() man page, :I should also make sure that drawmode() is NORMALDRAW, which shouldn't be a :problem as long as I don't try to read the z-buffer while any GUI elements are :being drawn. Fine. :Ideally, here's what I want to be able to do: : : readsource(SRC_ZBUFFER); : n = lrectread(...., zbuf); : /* operate on values in zbuf */ : :I'd like to get the z-buffer that corresponds to the frame currently being :displayed in the viewport. If I'm viewing a runway with a jet and buildings :and mountains in the distance, I want to have the correct depth values for :these objects. This is what you'll get. :I don't care about real-time performance, though it would be :nice to maintain it. It goes pretty fast. Something similar is used in the "view depth complexity" mode of the statistics. Check out perfly with the stats set to "fill stats" for an example of reading the stencil bits and then writing a pseudocolor image. :Can I lrectread from the z-bufer at any state in Performer, or should I only do :this immediately before/after pfDraw(), for example? You can read the Z-buffer whenever you want. It will be represent the exact state of rendering at the moment the call is made. In practice, you will *want* to read it just after the pfDraw() call. The only way to read the Z-buffer "in the middle of things" is to bind a node draw callback to something in the database and read the Z-buffer from with that callback. :I believe that on an MP :machine, Performer will render multiple frames on different processors to keep :up with the requested frame rate; does this mean that the z-buffer could be in :an inconsistent state? Nope. The multiple frames that will be in process will be in the application and culling stages, not in drawing, so there'll be no graphics effect. You *will* need to read the Z-buffer from the draw process, which makes the channel draw callback function the natural spot. :Thanks for your patience and for any help, Sure. You've not mentioned it, but it will save you time if you consult the little equation below. This is how to interpret (decode) the Z-buffer values which you are seeking. It can be tedious to work out by hand. ;-) z = value in z buffer after rendering (input) range = distance to pixel in database units (output) np = distance to near clipping plane (database units) fp = distance far clipping plane (database units) nz = near-clip z value (lsetdepth) fz = far-clip z value (lsetdepth) where you (or Performer on your behalf) did: lsetdepth(nz, fz); you must evaluate this equation for each Z-buffer value: fp*np(fz-nz) ------------ fp-np - range = -------------------------- (fp+np)(fz-nz) fz+nz z - -------------- - ----- 2(fp-np) 2 -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Jun 7 18:49:35 1994 From: "Drew Hess" Message-Id: <9406071849.ZM6362@airy.arc.nasa.gov> Date: Tue, 7 Jun 1994 18:49:14 -0700 In-Reply-To: "Michael Jones" "Re: z-buffer and Performer" (Jun 7, 5:48pm) References: <9406071656.ZM6289@airy.arc.nasa.gov> <9406071748.ZM8482@babar.asd.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Michael Jones" Subject: Re: z-buffer and Performer Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Thanks much for the great info. Is the info-performer list archived yet? The note I got upon subscribing to the list said this was being worked on, and it would be a great resource for questions like mine that may have been asked before. danke -dwh- dhess@vision.arc.nasa.gov dhess@cs.stanford.edu From guest Tue Jun 7 20:05:03 1994 From: hildebra@vsl.ist.ucf.edu (Andrew Hildebrand ) Message-Id: <9406080302.AA23993@onyx.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: pfSwitch Node Cc: barras@vsl.ist.ucf.edu Status: O My question has to do with the Performer node pfSwitch. First, is there any way to set up this type of node in Multigen and have the Multigen loader convert it? Second, is there a work around, so I can set up a node in Multigen (like a group) and then in my code (** easily **) change that group node to a pfSwitch node?? THANKS ______________________________________________________________________________ Andrew Hildebrand The University of Central Florida Virtual Reality Research Team (TOY SCOUTS) hildebra@vsl.ist.ucf.edu _______________________________________________________________________________ From guest Tue Jun 7 20:58:33 1994 Message-Id: <9406080358.AA22185@surreal.asd.sgi.com> To: hildebra@vsl.ist.ucf.edu (Andrew Hildebrand ) Cc: info-performer@sgi.sgi.com, barras@vsl.ist.ucf.edu Subject: Re: pfSwitch Node In-Reply-To: Your message of "Tue, 07 Jun 94 23:02:54 EDT." <9406080302.AA23993@onyx.vsl.ist.ucf.edu> Date: Tue, 07 Jun 94 20:58:21 -0700 From: Jim Helman Status: O I don't think FLT supports Performer's notion of switch nodes, but replacing one is fairly straightforward. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 pfSwitch *Group2Switch(pfGroup *grp) { int i, numPar, numChild; pfSwitch *sw; sw = pfNewSwitch(); numPar = pfGetNumParents(grp); numChild = pfGetNumChild(grp); /* add group's children to switch, in same order */ for (i = 0 ; i < numChild ; i++) { pfNode *child; child = pfGetChild(grp, i); pfAddChild(sw, child); } /* remove children from group */ for (i = 0 ; i < numChild ; i++) { pfNode *child; child = pfGetChild(grp, i); pfRemoveChild(grp, child); } /* replace group with switch under parent */ for (i = 0 ; i < numPar ; i++) { pfGroup *par; par = pfGetParent(grp, i); pfReplaceChild(par, grp, sw); } pfDelete(grp); return sw; } From guest Wed Jun 8 00:40:43 1994 Message-Id: <9406080740.AA24036@surreal.asd.sgi.com> To: "Ran Yakir" Cc: info-performer@sgi.sgi.com Subject: Re: DCS matrix during perf. stages In-Reply-To: Your message of "Wed, 08 Jun 94 09:43:45 -0000." <9406080943.ZM7919@rea1.bvr.co.il> Date: Wed, 08 Jun 94 00:40:29 -0700 From: Jim Helman Status: O > Now, why is this not true for the DRAW process too ? When there is a separate DRAW process (CULL_DRAW or CULLoDRAW), it doesn't have a copy of the scene graph because it doesn't need one. The DRAW does not traverse the scene graph, but merely consumes commands from a pfDispList generated by the CULL. All matrices are copied by the CULL into this display list, so everything does happen frame accurately. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 7 23:45:23 1994 From: "Ran Yakir" Message-Id: <9406080943.ZM7919@rea1.bvr.co.il> Date: Wed, 8 Jun 1994 09:43:45 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: DCS matrix during perf. stages Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi I read in some older letter ("Re: multiprocessing/ multibuffering ???" by Jim Helman), that Performer keeps a separate copy of the scene graph for the APP and CULL stages (I'm ignorring ISECT now). The exact words were : >> When Performer runs multiprocessed, the scene graph is >> multibuffered with the APP, ISECT and each pfPipe's CULL process >> having its own copy of each scene graph node. Updates propagate >> frame-accurately from the APP stage of the pipeline. Each frame, >> all changes to the scene graph (e.g. - a change to a DCS matrix or >> to the scene graph topology) are copied from the APP by the ISECT >> and CULL processes. Now, why is this not true for the DRAW process too ? I know the draw process can not change the scene. For example, it can not change a DCS matrix. However, if a DCS matrix is changed in the APP for frame # (n), the change will enter CULL only at next frame, because CULL is doing frame # (n-1), but DRAW will see the change immediately, even though it renders frame (n-2) now. I've tried that with a DCS, and it was as stated above. It seems that this could lead to problems with DCS's close to the eyepoint, which will be rendered in a 'future' position as far as DRAW process knows. Am I wrong ? If I'm right, is there a solution ? Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Wed Jun 8 13:03:07 1994 From: "Darin C. Partridge" Message-Id: <9406081402.ZM15794@paradox.idec.sdl.usu.edu> Date: Wed, 8 Jun 1994 14:02:48 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Clouds?...Sounds easy enough. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I'm a beginner with performer, however, I've imported several satellite terrain data sets. I usually hack on the Wavefront loader and perfly to accomplish this. It's worked good so far but now I would like to have clouds over the terrain. Since clouds are not included in the environment menu used in perfly I tried to add it. I realize I could be out to lunch since I still haven't got my man pages installed correctly, but here is the perfly module I modified: perfly/gui.c: static pfuGUIString ESky_strs[] = {"Sky/Clear","Overcast","Sky/Grnd","Sky", "Clear","PFES_SKY","Tag"}; static long ESky_vals[] = { PFES_SKY_CLEAR,PFES_OVERCAST,PFES_SKY_GRND,PFES_SKY, PFES_FAST, PFES_SKY, PFES_TAG}; common/env.c: void updateEnvironment(void) { pfEarthSky *es = ViewState->eSky; static long eSkyMode = -1; static long fogType = -1; static float fogNear = 0.0f, fogFar = 0.0f; if ((eSkyMode == ViewState->earthSkyMode) && (fogType == ViewState->fog) && (fogNear == ViewState->nearFogRange) && (fogFar == ViewState->farFogRange)) return; if (ViewState->fog != PFFOG_OFF) { pfFogType(fog, ViewState->fog); pfFogRange(fog, ViewState->nearFogRange, ViewState->farFogRange); pfESkyFog(es, PFES_GENERAL, fog); } else pfESkyFog(es, PFES_GENERAL, NULL); if( ViewState->earthSkyMode == PFES_OVERCAST ) { pfESkyMode(es, PFES_CLOUDS, ViewState->earthSkyMode); pfESkyAttr(es, PFES_CLOUD_TOP, 30.0f ); pfESkyAttr(es, PFES_CLOUD_BOT, 20.0f ); pfESkyColor(es, PFES_CLOUD_TOP, 0.1f, 0.1f, 0.2f, 1.0f); pfESkyColor(es, PFES_CLOUD_BOT, 0.2f, 0.2f, 0.1f, 1.0f); } else pfESkyMode(es, PFES_BUFFER_CLEAR, ViewState->earthSkyMode); /* update static values */ fogType = ViewState->fog; fogFar = ViewState->farFogRange; eSkyMode = ViewState->earthSkyMode; } Thanks for any help, Darin (darin@paradox.idec.sdl.usu.edu) From guest Wed Jun 8 13:18:20 1994 From: "Drew Hess" Message-Id: <9406081318.ZM7401@airy.arc.nasa.gov> Date: Wed, 8 Jun 1994 13:18:15 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfFog again Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O When I enable fog in perfly and then take a screen snapshot using the pfuSaveImage function, with readsource() set to SRC_FRONT, the captured image has a much different fog density than the on-screen image. How is fog implemented on the RE2, and what is the proper way to get the same image in a snapshot that I see on the screen? Do I need to readsource() and lrectread() from multiple buffers and somehow blend the images? Thanks -dwh- dhess@vision.arc.nasa.gov dhess@cs.stanford.edu From guest Wed Jun 8 13:23:14 1994 Date: Wed, 8 Jun 94 16:26:13 -0400 Message-Id: <9406082026.AA17815@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com From: darken@enews.nrl.navy.mil (Rudy Darken) Subject: line rendering in performer (conclusion; happy ending) Status: O Below is Michael Jones' code to create a grid of lines. I added it as is to smallfly as I had done for my LoadGrid function which was included in an earlier post. The same results were observed. The grid was red only when the other geometry (esprit.flt in my case) was not in view. However, as suggested by Jim Helman, adding the line noted by ** in the code below which disables lighting for the lines does eliminate the problem. Thanks very much for your assistance and patience. This problem has been hanging on for months. I finally got stubborn enough to fix it. rudy *** Begin Michael Jones' code *** What's your experience with the code below? It's my attempt to draw lines, and seems to work. I added it to Perfly and all seems well. /* * Make a "grid of lines" graphic object */ pfNode * MakeGrid (void) { void *arena = NULL; pfMaterial *material = NULL; pfGeoState *geostate = NULL; pfGeoSet *geoset = NULL; pfGeode *geode = NULL; pfVec3 *v = NULL; pfVec3 *vp = NULL; pfVec4 *c = NULL; int nx = 30; int ny = 30; float x0 = -10.0f; float y0 = -10.0f; float z0 = 5.0f; float x1 = 10.0f; float y1 = 10.0f; float dx = x1 - x0; float dy = y1 - y0; int x; int y; /* access the global shared-memory arena */ arena = pfGetSharedArena(); /* make a material that specifies LMC_AD mode */ material = pfNewMtl(arena); pfMtlColor(material, PFMTL_AMBIENT, 0.1, 0.1, 0.1); pfMtlColor(material, PFMTL_SPECULAR, 0.8, 0.8, 0.8); pfMtlColorMode(material, PFMTL_FRONT, LMC_AD); /* specify material but inherit all other geostate attributes */ geostate = pfNewGState(arena); pfGStateAttr(geostate, PFSTATE_FRONTMTL, material); ** pfGStateAttr(geostate, PFSTATE_ENLIGHTING, PF_OFF); /* create geoset at attach geostate to it */ geoset = pfNewGSet(arena); pfGSetPrimType(geoset, PFGS_LINES); pfGSetGState(geoset, geostate); /* build and attach vertex array */ vp = v = (pfVec3 *)pfMalloc((2*nx + 2*ny)*sizeof(pfVec3), arena); for (x = 0; x < nx; x++) { pfSetVec3(vp++, x0 + x*dx/(nx-1), y0, z0); pfSetVec3(vp++, x0 + x*dx/(nx-1), y1, z0); } for (y = 0; y < ny; y++) { pfSetVec3(vp++, x0, y0 + y*dy/(ny-1), z0); pfSetVec3(vp++, x1, y0 + y*dy/(ny-1), z0); } pfGSetAttr(geoset, PFGS_COORD3, PFGS_PER_VERTEX, v, NULL); pfGSetNumPrims(geoset, nx + ny); /* build and attach color array */ c = (pfVec4 *)pfMalloc(sizeof(pfVec4), arena); pfSetVec4(c, 1.0f, 0.0f, 0.0f, 1.0f); pfGSetAttr(geoset, PFGS_COLOR4, PFGS_OVERALL, c, NULL); /* create geode and attach geoset to it */ geode = pfNewGeode(); pfAddGSet(geode, geoset); /* return address of geode to caller */ return (pfNode *)geode; } _______________________________________________________________ Rudy Darken <202> 767-6814 darken@enews.nrl.navy.mil The U.S. Naval Research Laboratory darken@seas.gwu.edu The George Washington University _______________________________________________________________ From guest Wed Jun 8 15:02:49 1994 Return-Path: abramsh@tabor.mitre.org id AA24894; Wed, 8 Jun 94 18:02:41 EDT From: "Howard Abrams" Message-Id: <9406081802.ZM19211@tabor> Date: Wed, 8 Jun 1994 18:02:38 -0400 In-Reply-To: Jim Helman "Re: pfSwitch Node" (Jun 7, 8:58pm) References: <9406080358.AA22185@surreal.asd.sgi.com> X-Face: "K/fJ/f?*WE_#;z\|CNp$+h^E2!&gQ81\C'^AU,bHw*Fnw7"kIpq-_CHK*U(9;@W(dH?6A-:K'G#O>"?FJN#x`G^|O[OoJ&\]90&gj,gCE}bd]s%(y9`rVDKoqA(7S$9neB8J7}h;G3P^'7Sz^`:h{[,x->n~e*#'D})GpI"f^l^eiTkXeg+p'J()_<3Rx))]QJ=*p&l8iS~1NjHB49cVV+W/E\9,*rg={To@d;uSmNJ|b<+DSKUSbtc1Z@&@TMM}7vtL{ud!ULX/vbz,^!0HFzcj?p71>9i>&[^ZK`nj~VtL X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: pfSwitch Node Cc: plevy@tabor.mitre.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Just in case there are people out there who tried this code, there is a small bug: > pfSwitch *Group2Switch(pfGroup *grp) > { > int i, numPar, numChild; > pfSwitch *sw; > sw = pfNewSwitch(); > numPar = pfGetNumParents(grp); > numChild = pfGetNumChild(grp); > > /* add group's children to switch, in same order */ > for (i = 0 ; i < numChild ; i++) > { > pfNode *child; > child = pfGetChild(grp, i); > pfAddChild(sw, child); > } > > /* remove children from group */ > for (i = 0 ; i < numChild ; i++) > { > pfNode *child; > child = pfGetChild(grp, i); ^--- this should be 0 If you remove child 0, child 1 becomes child 0. The next time through the for if you then try to get child 1, and there were only two children, pfGetChild returns NULL, causing pfRemoveChild to core dump. Just my $0.02, Howard -- Howard Abrams (abramsh@mitre.org) The MITRE Corporation Mail Stop W273 Interactive Simulation Technology The Mitre Corporation I-Lab Envisioning Group McLean, VA 22102 Phone (703) 883-7421 These are not Mitre's opinions.... Hell, they're not even mine! From guest Wed Jun 8 15:05:30 1994 Return-Path: abramsh@tabor.mitre.org id AA24899; Wed, 8 Jun 94 18:05:00 EDT From: "Howard Abrams" Message-Id: <9406081804.ZM19263@tabor> Date: Wed, 8 Jun 1994 18:04:57 -0400 X-Face: "K/fJ/f?*WE_#;z\|CNp$+h^E2!&gQ81\C'^AU,bHw*Fnw7"kIpq-_CHK*U(9;@W(dH?6A-:K'G#O>"?FJN#x`G^|O[OoJ&\]90&gj,gCE}bd]s%(y9`rVDKoqA(7S$9neB8J7}h;G3P^'7Sz^`:h{[,x->n~e*#'D})GpI"f^l^eiTkXeg+p'J()_<3Rx))]QJ=*p&l8iS~1NjHB49cVV+W/E\9,*rg={To@d;uSmNJ|b<+DSKUSbtc1Z@&@TMM}7vtL{ud!ULX/vbz,^!0HFzcj?p71>9i>&[^ZK`nj~VtL X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfPartition Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O No one ever answered the question about pfPartitions. Do they, or do they not, speed culling? The man page says 'yes', but someone had said 'no'. Howard -- Howard Abrams (abramsh@mitre.org) The MITRE Corporation Mail Stop W273 Interactive Simulation Technology The Mitre Corporation I-Lab Envisioning Group McLean, VA 22102 Phone (703) 883-7421 These are not Mitre's opinions.... Hell, they're not even mine! From guest@holodeck.asd.sgi.com Wed Jun 8 18:48:50 1994 -0700 for /usr/lib/sendmail info-performer-dist id AA09742; Wed, 8 Jun 94 15:21:40 -0700 for info-performer@holodeck.asd.sgi.com id AA23364; Wed, 8 Jun 94 15:24:04 -0700 for info-performer@giraffe.asd.sgi.com id AA06527; Wed, 8 Jun 94 15:21:36 -0700 ; Wed, 8 Jun 1994 18:21:35 -0400 From: "Howard Abrams" Message-Id: <9406081821.ZM19322@tabor> Date: Wed, 8 Jun 1994 18:21:31 -0400 X-Face: "K/fJ/f?*WE_#;z\|CNp$+h^E2!&gQ81\C'^AU,bHw*Fnw7"kIpq-_CHK*U(9;@W(dH?6A-:K'G#O>"?FJN#x`G^|O[OoJ&\]90&gj,gCE}bd]s%(y9`rVDKoqA(7S$9neB8J7}h;G3P^'7Sz^`:h{[,x->n~e*#'D})GpI"f^l^eiTkXeg+p'J()_<3Rx))]QJ=*p&l8iS~1NjHB49cVV+W/E\9,*rg={To@d;uSmNJ|b<+DSKUSbtc1Z@&@TMM}7vtL{ud!ULX/vbz,^!0HFzcj?p71>9i>&[^ZK`nj~VtL X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.com Subject: FadeLOD & Lightpoints == BUG Cc: plevy@tabor.mitre.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Apparently Lightpoints don't fade with LOD's which isn't that bad execpt that during the fade transition of an lod, they disappear, causing a 'black out' until the next lod is compleatly faded in. Does anyone know of a work-around for this? PS. Is there anyone out there using libpfflt who has the need for directional lights as they appear in MultiGen? Or better yet, has anyone fixed LoadFLT to do directional lights correctly? -- Howard Abrams (abramsh@mitre.org) The MITRE Corporation Mail Stop W273 Interactive Simulation Technology The Mitre Corporation I-Lab Envisioning Group McLean, VA 22102 Phone (703) 883-7421 These are not Mitre's opinions.... Hell, they're not even mine! From guest Wed Jun 8 15:21:40 1994 Return-Path: abramsh@tabor.mitre.org id AA25051; Wed, 8 Jun 94 18:21:34 EDT From: "Howard Abrams" Message-Id: <9406081821.ZM19322@tabor> Date: Wed, 8 Jun 1994 18:21:31 -0400 X-Face: "K/fJ/f?*WE_#;z\|CNp$+h^E2!&gQ81\C'^AU,bHw*Fnw7"kIpq-_CHK*U(9;@W(dH?6A-:K'G#O>"?FJN#x`G^|O[OoJ&\]90&gj,gCE}bd]s%(y9`rVDKoqA(7S$9neB8J7}h;G3P^'7Sz^`:h{[,x->n~e*#'D})GpI"f^l^eiTkXeg+p'J()_<3Rx))]QJ=*p&l8iS~1NjHB49cVV+W/E\9,*rg={To@d;uSmNJ|b<+DSKUSbtc1Z@&@TMM}7vtL{ud!ULX/vbz,^!0HFzcj?p71>9i>&[^ZK`nj~VtL X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: FadeLOD & Lightpoints == BUG Cc: plevy@tabor.mitre.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Apparently Lightpoints don't fade with LOD's which isn't that bad execpt that during the fade transition of an lod, they disappear, causing a 'black out' until the next lod is compleatly faded in. Does anyone know of a work-around for this? PS. Is there anyone out there using libpfflt who has the need for directional lights as they appear in MultiGen? Or better yet, has anyone fixed LoadFLT to do directional lights correctly? -- Howard Abrams (abramsh@mitre.org) The MITRE Corporation Mail Stop W273 Interactive Simulation Technology The Mitre Corporation I-Lab Envisioning Group McLean, VA 22102 Phone (703) 883-7421 These are not Mitre's opinions.... Hell, they're not even mine! From guest Wed Jun 8 21:47:57 1994 From: "Drew Hess" Message-Id: <9406082147.ZM8523@airy.arc.nasa.gov> Date: Wed, 8 Jun 1994 21:47:40 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: more pfFog fun Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I've done some playing around since I posted my last message stating that I was having problems with scenes with fog not looking the same as snapshots of those scenes taken using pfuSaveImage(). In case you're actually following along, here's the basic problem: if I render a scene with pfFog turned on, and then take a snapshot of the scene using the Performer pfuSaveImage() function, the snapshot as displayed by imgview(1) is visibly different than the scene rendered by Performer. The difference is that the far fog plane, that is the distance at which all pixels fade to fog color, appears to be missing in the snapshot, and the effect is that you have a much greater visible range in the snapshot than you do in the rendered Performer scene. Here's what I've established so far: a) this problem occurs when running Performer in full-screen GL mode on an Indigo2 with an XL framebuffer as well as on an Onyx with an RE2. b) this problem does *not* occur when a GUI panel is being displayed; that is, both Performer and the snapshot show the GUI, but the scene looks *exactly* the same in Performer as it does when I use imgview(1) to view the snapshot. c) if I create a smaller window, using the -W x,y parameter to perfly, for instance, the snapshot fades to the far fog plane properly, so visible range is the same in both images; but strangely, the fog color in the snapshot is always white (1.0, 1.0, 1.0) despite the fact that the fog color in the Performer scene is, say, grey (0.7, 0.7, 0.7). I don't think this is a gamma correction effect because when I set the fog color in the Performer scene to pure white, the fog colors are identical (both pure white). d) if I create a less-than-fullscreen GLX window (-x in perfly), the snapshot is exactly the same as the Performer scene (except that I need to tweak the window sizes that get passed to lrectread() in pfuSaveImage a bit because it captures part of the window manager border around the GLX window -- note this does not occur in a small window where I don't specify the -x option to perfly). (I also get the overlay plane in my snapshot in this case, evident by the "IRIS Performer" label in the upper right-hand corner of the snapshot.) Anyway, originally I figured that the RE^2 was doing some funky buffering to generate hardware fog that caused readsource(SRC_FRONT) to miss part of the fog layers; now I know that it's not just the RE^2 since the XL produces a similar (though not identical) effect. Still it would be nice if some kind soul at SGI who's bothered to read this far could explain how the RE^2 produces fog :) The pfuSaveImage routine produces a 24-bit RGB image and basically strips off anything but the first 24bits of the pixel, as far as I can tell; but I don't think it's a pixel-depth problem because I'm getting bad results on the XL, which is purely 24-bit, as well as on the variable-depth RE^2. I don't know what mode Performer operates in on such a beast. I've also noticed that playing with the pfESkyMode settings has an effect on the way fog is rendered; I might look into this next if no one has a simple answer for me. Sorry I'm so long-winded, but it's a very curious problem and I thought I should accurately document what I'm talking about. The bottom line is that I want to make snapshots of foggy scenes in any mode I want on any machine (ok, I'll settle for full-screen GL-mode snapshots on the RE^2 only at this point :) ) for image processing, and I want the snapshot to look identical to the rendered scene in Performer. What am I doing wrong? Thanks again to the Performer people, -dwh- dhess@vision.arc.nasa.gov dhess@cs.stanford.edu From guest Thu Jun 9 09:37:09 1994 Date: Thu, 9 Jun 1994 09:37:06 -0700 From: "Carlo L. Tiana" Message-Id: <199406091637.JAA28788@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: Movie generation/format conversion Status: O I hope this question is relevant enought for this list. I have a number of snapshots taken from renderings of a scene by Performer. THey are all .rgb files. I would like to compose a movie from them. THe number is high enough (150 frames) that using moviemaker to load each frame manually is a little painful. In addition, I am trying to use ImageVision Library to process the resulting movie, and IL does not seem to recognize the movie format moviemaker generates. What I am wondering is (in order of decreasing appeal!): - are there tools to take a number of .rgb files and create an IL movie (and if so are there tools that will do the reverse (take an IL movie and split it into a number of .rgb files) - are three tools that will take a number of .rgb files and create a 'moviemaker' format movie (whatever that is) (and the reverse would be nice too). Sorry if this is far off the mark for this list. Carlo Tiana NASA Ames Research Center From guest Thu Jun 9 10:01:30 1994 Date: Thu, 9 Jun 94 10:01:22 -0700 From: ib@ivan (Ivan Bach) Message-Id: <9406091701.AA10839@ivan.asd.sgi.com> To: info-performer@sgi.sgi.com, "Carlo L. Tiana" Subject: Re: Movie generation/format conversion Status: O Try to use /usr/sbin/movie from the subsystem eoe2.sw.imagetools in 5.2. Just enter: movie file1.rgb file2.rgb ... If you want to slow down the movie, enter: movie file1.rgb file1.rgb file2.rgb file2.rgb ... Ivan Bach, ib@sgi.com From guest Thu Jun 9 10:39:34 1994 Message-Id: <9406091837.ZM2284@unknown.zmail.host> Date: Thu, 9 Jun 1994 18:37:40 +0100 In-Reply-To: "Carlo L. Tiana" "Movie generation/format conversion" (Jun 9, 9:37am) References: <199406091637.JAA28788@descartes.arc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: How to black out a channel Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi I'm in the midle of making a multi-user Performer demo. I have up to 4 channels, each representing a different users viewpoint. I have a VTX, with an MCO, so all the channels render to the same virtual screen, and I then send the video to diffreent monitors (up to 4), via an MCO. I have set things up so that all channels share thins like SWAPBUFFERS, EARTHSKY etc.. At various points within the application I wish to turn off arbitrary channels. I would like the view point in these channels to be then set to black (or some other constant colour). My question is, how do I do that. I tried pfChanTravMode ( chan, PFTRAV_DRAW, PFDRAW_OFF); but this only stops any more rendering. I also tried having pfChanShare (chan, PFCHAN_SWAPBUFFERS); pfClearChan(chan); for two frames before the rendering stops, to clear the channel, but that did not seem to work. Anyway, I'm sure there is a simple way to do what I want. Anyone know how? I suppose I could just write the data r,g,b=0,0,0 by hand into the frame buffer) but is there an easier way. Thanks Richard Gallery From guest Thu Jun 9 13:51:10 1994 From: hill_b@ameig1.navsea.navy.mil (Brian Hill) Message-Id: <199406092200.AA13153@ameig1.navsea.navy.mil> Subject: Re. NURBS too! To: info-performer@sgi.sgi.com (Performer list) Date: Thu, 9 Jun 94 17:00:45 CDT X-Mailer: ELM [version 07.00.00.00 (2.3 PL11)] Status: O Robert Rossow wrote in a previous message related to NURBS > > I believe that the ability to use NURBS to define geometry within > Performer would be extremely beneficial...... > ... > ... > If this were the case, many more models would become available, > and the user could be relieved of both the tesselation and > texture/normal specifications on a per-vertex basis. > ... > Sounds too good to be true. What do you think? > As a related matter, almost all of my geometry originates as an engineering CAD model (ie NURBS) that has to be converted with a combination of automatic and manual techniques. There are times when I don't need to develop a pituresque model using exotic texturing and materials, I only need a functional rendering. It would be nice to be able to load the original IGES NURB data into Performer. How about an IGES loader for Performer????? Thanks, =================================================================== Brian Hill | Advanced Marine Enterprises, Inc.| CSD Section Chief | Suite 1300 | (703)415-3080 | 1725 Jefferson Davis Hwy. | hill_b@ameig1.navsea.navy.mil | Arlington VA, 22202 | =================================================================== From guest Thu Jun 9 19:56:42 1994 Message-Id: <00581.2854023880.1445@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Thu, 9 Jun 1994 14:51:56 PST Subject: Re: pfSwitch Node Status: O Reply to: RE>pfSwitch Node From: Andrew Hildebrand Date: Tue, 7 Jun 94 23:02:54 -0400 Message-Id: <9406080302.AA23993@onyx.vsl.ist.ucf.edu> To: info-performer@sgi.com Subject: pfSwitch Node >My question has to do with the Performer node pfSwitch. First, >is there any way to set up this type of node in Multigen and have >the Multigen loader convert it? Second, is there a work around, so >I can set up a node in Multigen (like a group) and then in my code >(** easily **) change that group node to a pfSwitch node?? MultiGen V14.1 will include a new OpenFlight switch bead type that will be translated into Performer a pfSwitch node by the OpenFlight loader. Regards, Mark Barnes Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 247 4326 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Thu Jun 9 17:21:15 1994 id AA29386; Thu, 9 Jun 94 17:20:25 -0700 Date: Thu, 9 Jun 1994 17:20:23 -0700 (PDT) From: Robert Russ Sender: Robert Russ Reply-To: Robert Russ Subject: Re: Re. NURBS too! To: Brian Hill Cc: Performer list In-Reply-To: <199406092200.AA13153@ameig1.navsea.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O Hi all, my $0.02 on the nurbs thingy: The current loaders (ie: for .sgo, .obj, .dxf, etc) are all for handling polygonal data exclusively for a seemingly very good reason: Performer eventually needs polygons to render and reading in polygons is fairly straight-forward - the readers are fairly "dumb" in that they don't interpret data, only read it in and translate it to the data structure Performer needs. On the other hand, a nurbs -> poly's reader requires some smarts to translate the surfaces into polygons. Important issues pertaining to subdivision levels, error factors for resolving the surfaces to polygons, limitations of the target machine, etc are all important in determining exactly how to represent a spline model with polygons. We've found it to be much more beneficial to go into a program and somewhat manually convert spline models to polygons based on the above concerns. We use Alias for all of our VR stuff and have written a .tri reader (.tri is a triangle file format Alias creates) which works quite nicely. Although this isn't as automated as a "spline file reader", it seems to me that this would be a rather complex issue to automate well. Rob -------------------------------------------------------------------- Robert H. Russ russ@sdsc.edu 3D Computer Animation / Post Production OFC: (619) 534-5030 Visualization Technology Group LAB: (619) 534-5162 San Diego Supercomputer Center FAX: (619) 534-5152 -------------------------------------------------------------------- On Thu, 9 Jun 1994, Brian Hill wrote: > Robert Rossow wrote in a previous message related to NURBS > > > > I believe that the ability to use NURBS to define geometry within > > Performer would be extremely beneficial...... > > ... > > ... > > If this were the case, many more models would become available, > > and the user could be relieved of both the tesselation and > > texture/normal specifications on a per-vertex basis. > > ... > > Sounds too good to be true. What do you think? > > > As a related matter, almost all of my geometry originates as an > engineering CAD model (ie NURBS) that has to be converted with a > combination of automatic and manual techniques. There are times > when I don't need to develop a pituresque model using exotic > texturing and materials, I only need a functional rendering. > It would be nice to be able to load the original IGES NURB data > into Performer. How about an IGES loader for Performer????? > > Thanks, > > =================================================================== > Brian Hill | Advanced Marine Enterprises, Inc.| > CSD Section Chief | Suite 1300 | > (703)415-3080 | 1725 Jefferson Davis Hwy. | > hill_b@ameig1.navsea.navy.mil | Arlington VA, 22202 | > =================================================================== > > > > > > > From guest Thu Jun 9 18:22:48 1994 Message-Id: <9406100116.AA14440@surreal.asd.sgi.com> To: "Howard Abrams" Cc: info-performer@sgi.sgi.com Subject: Re: pfPartition In-Reply-To: Your message of "Wed, 08 Jun 94 18:04:57 EDT." <9406081804.ZM19263@tabor> Date: Thu, 09 Jun 94 18:16:19 -0700 From: Jim Helman Status: O pfPartitions are only currently intended to improve intersection performance. For culling they behave exactly like a group. It appears that there are some bugs in 1.2 regarding pfPartitions. I'd advise against using them until we work through the pproblems. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 9 23:42:52 1994 Date: Fri, 10 Jun 1994 08:44:06 +0059 (MDT) From: Henrik Tramberend Subject: Re: Movie generation/format conversion To: "Carlo L. Tiana" Cc: info-performer@sgi.sgi.com In-Reply-To: <199406091637.JAA28788@descartes.arc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 9 Jun 1994, Carlo L. Tiana wrote: > I would like to compose a movie from them. THe number is > high enough (150 frames) that using moviemaker to load > each frame manually is a little painful. In addition, Try 'man makemovie'. That's what you need. Regards, Henrik ------------------------------------------------------------------------ Henrik Tramberend Phone: +49(30)262.94.01 Art+Com e.V. Fax: +49(30)261.90.36 Berlin, Germany E-Mail: henrik@artcom.de From guest Mon Jun 13 10:24:05 1994 Date: Mon, 13 Jun 1994 10:23:56 -0700 From: "Carlo L. Tiana" Message-Id: <199406131723.KAA00482@descartes.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: SUMMARY Re: Movie generation/format conversion Status: O Thanks for the many helpful hints. I recently posted this question: > I hope this question is relevant enought for this list. > I have a number of snapshots taken from renderings of > a scene by Performer. THey are all .rgb files. > I would like to compose a movie from them. THe number is > high enough (150 frames) that using moviemaker to load > each frame manually is a little painful. In addition, > I am trying to use ImageVision Library to process the > resulting movie, and IL does not seem to recognize the > movie format moviemaker generates. > What I am wondering is (in order of decreasing appeal!): > - are there tools to take a number of .rgb files and > create an IL movie (and if so are there tools that will > do the reverse (take an IL movie and split it into a > number of .rgb files) > - are three tools that will take a number of .rgb files > and create a 'moviemaker' format movie (whatever that is) > (and the reverse would be nice too). > > Sorry if this is far off the mark for this list. > Carlo Tiana > NASA Ames Research Center A number of people pointed me to a number of tools, and I myself remembered the existence of others. In particular: /usr/sbin/movie will take a series of .rgb files and play them as a movie. Not too flexible otherwise (and I could not find a way to save that movie). This has a man page. /usr/sbin/makemovie more flexible than the above and will let you save the movie. Has a man page. Movie created can be edited manually with moviemaker. moviemaster this was suggested by the list, though it's not on my system so I can't comment on it. ilcat/ilmovie these 2 'demo quality' tools come with the ImageVision library in source form (in /usr/people/4Dgifts/examples/ImageVision). ilcat will take a bunch of .rgb (and others) files and make a movie ImageVision recognizes as such (I have not compared this format to that of the other tools mentioned), and ilmovie will play this movie as well as allowing one to perform some image processing operations on the movie (frame by frame). Unfortunately the processed movie cannot be saved, although since the source code for this is available this is a simple addition one can make. These guys did it for me, since my requirement was to create a movie that IL would be able to operate on. Thanks to all for their help. Carlo Tiana NASA/Ames Research Center. From guest Tue Jun 14 05:40:20 1994 Date: Tue, 14 Jun 94 15:38:44 +0300 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406141238.AA05524@fred.bvr.co.il> To: info-performer@sgi.sgi.com Subject: Seperate ISECT process Status: O Hi All, My application uses a seperate process for intersection calls. (pfMultiprocess(PFMP_FORK_ISECT)). My problem is the lack of a two-way path between the APP process and the ISECT process. Currently changes done, in the ISECT structure, in the APP process are passed down to isect_func() (the ISECT cb), but sadly enough it is not true the other way around. Is there a way to pass the altered ISECT structure back to the APP other than using some globally-defined shared data structure? Below are some relevant code lines from my application static void isect_func(void *userData) { IsectData *isect_data; isect_data = (IsectData *)userData; . . . } main() { . . . /* Initializing the ISECT cb */ pfIsectFunc(isect_func); isect_data = (IsectData *)pfAllocIsectData(sizeof(IsectData)); . . /* Main loop */ while (1) { . . . pfPassIsectData(); pfFrame(); } } Thanks Alon \________ \___ \_________ \__________ \___ \__________ \___ \___ \___ \___ \___ Alon J Rosenfeld \___ \___ \___ \___ \___ BVR Technologies Ltd. \__________ \___ \___ \_________ 1 Korazim st. Givatayim, Israel \__________ \___ \___ \_________ Tel: 972-3-571 5671 \___ \___ \__________ \___ \___ Fax: 972-3-571 5668 \___ \___ \________ \___ \___ Home: 972-3-683 6020 \___ \___ \______ \___ \___ Email: alon@bvr.co.il From guest Tue Jun 14 08:54:34 1994 Date: Tue, 14 Jun 94 08:54:29 -0700 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9406141554.AA05891@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: Re: How to black out a channel Status: O We are working on a VGXT, no RE (yet!), running Performer 1.0 The way we clear the channel is by setting a Draw callback with pfChanDrawFunc( channel, drawfunction ). We allocate a PassData structure which holds a "clear channel only" flag with pfAllocChanData( channel, sizeof( PassData ) ). In drawfunction we call pfClearChan( channel ) and return if the "clear channel only" flag is set, otherwise render the channel. -------------------+------------------------------+------------------------ William Briggs | MailStop 262-2 | "The computer screen NASA Ames Research | PO Box 1000 | has become the retina (415) 604-6438 | Moffett Field, CA 94035-1000 | of the mind's eye." -------------------+------------------------------+------------------------ From guest Tue Jun 14 09:09:37 1994 Date: Tue, 14 Jun 94 09:09:30 -0700 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9406141609.AA05949@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: 2-D Overlay Status: O I am using IRIX 4.0.5 and Performer 1.0 on a SkyWriter (no RE...yet :^) Is it possible to do a two-dimensional overlay in a channel? Up until now, I have drawn a crosshair with a draw callback. I transform to the viewpoint and then in front of it. However, roundoff error causes the crosshair lines to wiggle, forcing me to put them farther away. With them farther away, they interact with the terrain, dissapearing behind it when the viewpoint is too close. From guest Tue Jun 14 11:45:20 1994 Date: Tue, 14 Jun 94 11:43:34 PDT From: ling@cod.nosc.mil (Ling Vongsouthy) Message-Id: <9406141843.AA04987@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Diffuse Color Status: O Hi there, I am a beginner on Performer. I have questions about changing diffuse color of objects using the smallfly program. The following is a portion of smallfly.c that I modified: Void InitScene(void) { .... .... .... for(i = 0; i < Numfiles; i++) { material = pfNewMtl(pfGetSharedArena()); pfMtlColorMode(material, PFMTL_FRONT, LMC_AD); gstate = pfNewGState(pfGetSharedArena()); root = (pfGroup *)LoadFile(DatabaseFiles[i], gstate); pfGStateAttr(gstate, PFSTSTE_FRONTMTL, material); pfMtlColor(material, PFMTL_DIFFUSE, 1.0, 0.0, 0.0); ..... ..... The modified smallfly program compiled no problem. However I can change the color of .obj files only. What do I have to do to change the color on other file formats (.dxf, .sv, etc). Thanks From aschaffe Tue Jun 14 13:30:37 1994 From: aschaffe (Allan Schaffer) Message-Id: <9406141330.ZM12638@holodeck.asd.sgi.com> Date: Tue, 14 Jun 1994 13:30:22 -0700 In-Reply-To: stimpy@niesten.arc.nasa.gov (William Briggs) "2-D Overlay" (Jun 14, 9:09am) References: <9406141609.AA05949@niesten.arc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: stimpy@niesten.arc.nasa.gov (William Briggs) Subject: Re: 2-D Overlay Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 14, 9:09am, William Briggs wrote: > I am using IRIX 4.0.5 and Performer 1.0 on a SkyWriter (no RE...yet :^) > > Is it possible to do a two-dimensional overlay in a channel? Up until > now, I have drawn a crosshair with a draw callback. I transform to the > viewpoint and then in front of it. However, roundoff error causes the > crosshair lines to wiggle, forcing me to put them farther away. With > them farther away, they interact with the terrain, dissapearing behind > it when the viewpoint is too close. You might try changing the Z buffer state right before and after you draw the crosshairs. This will force them to always be drawn "over" the scene. pfDraw(); ... zfunction(ZF_ALWAYS); zwritemask(0x0); draw crosshairs zfunction(ZF_LEQUAL); zwritemask(0xffffffff); Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Tue Jun 14 14:10:21 1994 From: "chris mcmahan" Message-Id: <9406141412.ZM8849@totally.cs.nps.navy.mil> Date: Tue, 14 Jun 1994 14:12:00 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Please unsubscribe me Thank you -- My opinions are my own, otherwise they wouldn't be my opinions... ------------------------------------------------------------------ | Chris McMahan | mcmahan@cs.nps.navy.mil | | Naval Postgraduate School | CMcMahan@aol.com | | Monterey, CA 93940 | | ------------------------------------------------------------------ From guest Tue Jun 14 17:39:14 1994 Date: Tue, 14 Jun 94 17:37:27 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406150037.AA11600@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Problem Loading mulitple obj Files - it only flickers Cc: goodhart@cod.nosc.mil Status: O I've been loading multiple models (obj format) into perfly using perfly -X 100 file1.obj file1.obj file1.obj The response is that the "Welcome to Performer" message comes up in the Performer window, and the GUI comes up. But the scene never comes up and instead the Performer window starts flickering. I try changing things near plane far plane, etc but with no success. I can load the obj file by itself or load many of them without using the -X explode option and that works ok, excpet of course the objects are all loaded ontop of each other. I am using Performer 1.2 and the latest IRIX release (I can't remember the number right now) on an ONYX (and also running all processes on a single processor for now) Has anyone seen this type of behavior before? Can anyone offer any suggestions? Thanks, Curt Goodhart From guest Wed Jun 15 10:00:50 1994 Date: Wed, 15 Jun 94 17:48:36 +0100 From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9406151648.AA07390@death.reading.sgi.com> To: info-performer@sgi.sgi.com Subject: Mouse input Status: O What is the best way of determining which channel the mouse is in, on a 3 chaannel, 3 pipe performer application ? I am using pfuGetMouse, but I need to collectInput in whichever channel/pipe has the mouse. I am using GL input. a.t.b ANgus The Sharks Are Swimming Again "Imagine your witty quote here" From guest Wed Jun 15 11:56:18 1994 Message-Id: <9406151852.AA26987@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA X-Sender: barrus@mailhost.merl.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jun 1994 14:52:12 -0400 To: Marcus From: barrus@merl.com (John W. Barrus) Subject: Re: Part Number Cc: info-performer@sgi.sgi.com Status: O > REGARDING Part Number >Does anyone know the part number to purchase the Performer 1.2 manual set? >I called SGI DIRECT and they don't have it listed ... > >Thanks in advance, >Mark Barnes, Member Technical Staff >MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 >PH: (408) 261 4110 FX: (408) 247 4329 >EMAIL: multigen!marcus@uunet.UU.NET From DOC # 201-206-05 Silicon Graphics Material Packing List Description: UPDATE, CD, IRIS PERFORMER 1.2 Part Number: 026-7242-003 Component Part Number Description Rvsn Quant 812-0126-003 CD ASSY, IRIX5 IRIS PERFORMER 1.2 A 1 812-0107-003 CD ASSY, IRIX4 IRIS PERFORMER 1.2 A 1 007-1680-020 MNL, IRIS PERFORMER, PROGRAMMERS GD A 1 007-1681-020 MNL, IRIS PERFORMER, MAN PAGES A 1 007-1689-020 MNL, IRIS PERFORMER, QUICK REF CARD A 1 Have fun, John B. ------------------------- John Barrus barrus@merl.com Mitsubishi Electric Research Laboratories 617.621.7535 (VOICE) 201 Broadway 617.621.7550 (FAX) Cambridge, MA 02139 From guest Wed Jun 15 11:26:17 1994 Message-Id: <00581.2854523998.1473@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 15 Jun 1994 11:11:23 PST Subject: Part Number Status: O REGARDING Part Number Does anyone know the part number to purchase the Performer 1.2 manual set? I called SGI DIRECT and they don't have it listed ... Thanks in advance, Mark Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4110 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From aschaffe Wed Jun 15 12:16:23 1994 From: aschaffe (Allan Schaffer) Message-Id: <9406151216.ZM15793@holodeck.asd.sgi.com> Date: Wed, 15 Jun 1994 12:16:02 -0700 In-Reply-To: barrus@merl.com (John W. Barrus) "Re: Part Number" (Jun 15, 2:52pm) References: <9406151852.AA26987@merl.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Marcus Subject: Re: Part Number Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 15, 2:52pm, John W. Barrus wrote: > >Does anyone know the part number to purchase the Performer 1.2 manual set? > >I called SGI DIRECT and they don't have it listed ... > From DOC # 201-206-05 > Silicon Graphics Material Packing List > > Description: UPDATE, CD, IRIS PERFORMER 1.2 > Part Number: 026-7242-003 > > Component Part Number Description Rvsn Quant > 812-0126-003 CD ASSY, IRIX5 IRIS PERFORMER 1.2 A 1 > 812-0107-003 CD ASSY, IRIX4 IRIS PERFORMER 1.2 A 1 > 007-1680-020 MNL, IRIS PERFORMER, PROGRAMMERS GD A 1 > 007-1681-020 MNL, IRIS PERFORMER, MAN PAGES A 1 > 007-1689-020 MNL, IRIS PERFORMER, QUICK REF CARD A 1 Thanks John -- I didn't have this info handy anywhere, I will add it to the FAQ. The manuals are also available separately (same part number). The product code is: M4-PERF-1.2 MANUAL SET Only Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Jun 15 11:20:22 1994 Wed, 15 Jun 1994 11:20:08 -0700 for <@ucsd.ucsd.edu:info-performer@sgi.com> From: prwhite@sgva-xs4.ucsd.edu (Payton White) Message-Id: <9406151820.AA12228@sgva-xs4> Subject: Multi-process problem To: info-performer@sgi.sgi.com Date: Wed, 15 Jun 1994 11:19:59 -0800 (PDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1358 Status: O This should be a simple problem, but it has been causing us much trouble. We have been developing a scaled down application on some single cpu machines with Performer 1.2 with no problems. When we recompile and run it on a RE (OS 5.2) we get plenty of crashes. As per the manual, this means we are probably doing something wrong with (not) allocating things in our shared memory structure. We have _everything_ (scene, pipe, channel, env, light model material, etc) in our shared structure and we malloc for it before pfConfig when the processes split. Through debugging we have found it crashes on pfShadeModel, pfApplyLModel, pfApplyMtl, pfApplyGState. My question is, just what exactly must be allocated in the shared structure, how and when? Adapting perfly or other examples is not an alternative that we welcome, but any solutions and ideas about this problem are. Thanks, -- Visualization << SGI >> Simulation -- Payton R. White __ __ __ prwhite@ucsd.edu / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From guest Wed Jun 15 12:24:54 1994 From: (Randy Hudson ("Better Living Through Mathematics")) Message-Id: <9406151426.ZM2647@eecs.uic.edu> Date: Wed, 15 Jun 1994 14:26:15 -0500 X-Mailer: Z-Mail (3.1b.0 09feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Texture Mapping Cc: gokhale@mcs.anl.gov Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi. Our Performer application reads in several Inventor-format models and builds a scene hierarchy. The files do not, as far as we know, contain texture coordinates. Is it possible to texture map one or more of the models without knowing anything about their internal makeup (e.g., the geosets they may be built from)? Thanks. R. Hudson. -- Randy Hudson Electronic Visualization Lab hudson@eecs.uic.edu University of Illinois at Chicago (M/C 154) (312) 996-3002 851 S. Morgan, room 1120 SEO (312) 413-7585 FAX Chicago, IL 60607-7053 From guest Wed Jun 15 05:56:12 1994 Message-Id: Date: Wed, 15 Jun 94 14:56 MDT From: matomira@ligsg2.epfl.ch (Fernando D. Mato Mira) To: info-performer Subject: threaded Performer Reply-To: matomira@epfl.ch Status: O Hello, Have you thought about giving the possibility to the users of choosing how the processes should be spawned (that is, using sproc instead of fork). When using sproc the drawing, culling process callbacks should take one more argument (the private data block). I think this would be quite easy to implement. This is very important for people who have a HUGE application that they do not want to clone for every process. (in my case, I run Performer from Lisp, and I do not want to copy 20Mb of developent environment, libraries, GUI toolkit, application on things that might even not need Lisp (for example if the cull callbacks are all writen in C). When the callbacks need Lisp, I might want to refer to things in my app (I have multiple processes, locks, etc in Lisp, too), so it has to be ONE Lisp. What's more, even in the case when you fork the processes, and I replicate Lisps, I might need to initialize the Lisp in the other process, if I am going to call Lisp routines as callbacks, or in C callbacks. This is possible for the draw process (pfInitPipe), but not for the cull process. When processes are spawned via sproc, I might need to initilize a lisp process representing the corresponding Unix thread (this assumes a lisp where processes are implemented using Unix threads). Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Wed Jun 15 14:30:21 1994 Date: Wed, 15 Jun 94 14:28:26 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406152128.AA27499@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Coloring Models in Performer Cc: goodhart@cod.nosc.mil Status: O I am using perfly to implement a specific type of object selection algorithm. I want to be able to change the color of some model dynamically. For example at some given time I want to change the color of the geometry under node X to red. Currently I think that node X is a DCS. The data files that I've tried this with are flt format files, obj files, and iv files. When I do what follows below all that happens is that the model turns grey instead of the desired color. 1) Let's say I load 4 data files (4 separate objects) such as 4 enterprise.flt files. ie: perfly enterprise.flt enterprise.flt enterprise.flt enterprise.flt c) My SW selects one of those objects (models) and attempts to change its color. I do this in a node call back function during the draw traversal. So I execute the following when I am reading in the model files. ptrToNode is a pointer to the node that gets set up when perfly loads a file. int mydata; pfNodeTravFuncs(ptrToNode, PFTRAV_DRAW, clgpreDraw, clgpostDraw); pfNodeTravData(ptrToNode, PFTRAV_DRAW, &mydata); In the preDraw function I intend to color the object red when test is set: long clgpreDraw(pfTraverser *trav, void *data) { int test; static int firsttime = 0; static pfMaterial *ahaPreselectMtl; /* Please forgive this hack of setting the material here * I intend to move it to an initialization file when I * get things working. */ if (!firsttime) { firsttime = 1; ahaPreselectMtl = pfNewMtl(NULL); } test = *(int *) data; if (test) { pfPushState(); pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_CMODE_COLOR); /* I also tried it with the following statement included - nodifference * pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_AD); */ pfMtlColor(ahaPreselectMtl, PFMTL_DIFFUSE, 1.0, 0.0, 0.0); pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_ON); pfApplyMtl(ahaPreselectMtl); } return PFTRAV_CONT; } The postDraw function to restore the state is: long clgpostDraw(pfTraverser *trav, void *data) { int test; test = *(int *)data; if (test) { pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_OFF); pfPopState(); } return PFTRAV_CONT; } The idea is that whenever test is 1 I want to change the color of that object to red. When I use what I show you above the material of the selected object becomes gray rather than red. This code seems to work ok when I change the selected object to wireframe rather than coloring the object red (ie I just do a pfEnable(PFEN_WIREFRAME) in the preDraw, and a pfDisable(PFEN_WIREFRAME) in the postDraw. 3) We are running on an Onyx running IRIX 5.2 and using Performer 1.2. Thank you, Curt Goodhart From aschaffe Wed Jun 15 17:27:45 1994 From: aschaffe (Allan Schaffer) Message-Id: <9406151727.ZM17353@holodeck.asd.sgi.com> Date: Wed, 15 Jun 1994 17:27:34 -0700 In-Reply-To: prwhite@sgva-xs4.ucsd.edu (Payton White) "Multi-process problem" (Jun 15, 11:19am) References: <9406151820.AA12228@sgva-xs4> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: prwhite@sgva-xs4.ucsd.edu (Payton White), info-performer@sgi.sgi.com Subject: Re: Multi-process problem Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 15, 11:19am, Payton White wrote: > > This should be a simple problem, but it has been causing us much > trouble. We have been developing a scaled down application on some > single cpu machines with Performer 1.2 with no problems. When we > recompile and run it on a RE (OS 5.2) we get plenty of crashes. As > per the manual, this means we are probably doing something wrong > with (not) allocating things in our shared memory structure. We have > _everything_ (scene, pipe, channel, env, light model material, etc) > in our shared structure and we malloc for it before pfConfig when the > processes split. Just for a sanity check -- be sure that you're using pfMalloc (and not malloc). Also that the pfMalloc for your shared struct is between pfInit() and pfConfig(), ie.. /* Initialize Performer */ pfInit(); /* Use default multiprocessing mode based on number of processors. */ pfMultiprocess (PFMP_DEFAULT); /* Malloc storage in shared memory region for shared data */ shared = (SharedData *) pfMalloc(sizeof(SharedData),pfGetSharedArena()); /* Configure multiprocessing mode and start parallel processes */ pfConfig(); > Through debugging we have found it crashes on > pfShadeModel, pfApplyLModel, pfApplyMtl, pfApplyGState. It's likely then that you're calling these routines from the APP process. They are libpr routines that make GL calls, so they can only be called from within the DRAW. On an MP machine, the APP, CULL, and DRAW stages can each be different processes. Only the DRAW process has access to the rendering pipeline, so you can only make those calls in the pipe initialization callback, channel draw callback, or node draw callbacks. When Performer runs on a 1-CPU machine this doesn't matter so much, since the APP, CULL, and DRAW are all part of the same process. That's probably why you didn't see the problem before. And as always, take a look in /usr/src/Performer/src/pguide/libpf/progs for some samples. Allan -- Allan Schaffer Silicon Graphics aschaffe@sgi.com From guest Wed Jun 15 18:40:00 1994 Return-Path: Message-Id: <9406160140.AA23125@ns.trl.ibm.com> To: info-performer Cc: aono@trl.ibm.co.jp Subject: X-Motif + performer sample program Date: Thu, 16 Jun 1994 10:40:03 +0900 From: Masaki Aono Status: O Dear Sirs/Madams: Is there a sample program that uses OSF/Motif as GUI in Performer's program? I find that the sample program "intersect.c" uses GL(qdevice(),qtest(), and qread()) as GUI (see "Pipeline", March/April 1994, Vol.5, No.2). What I'd like to get is a sample program that uses Performer's libraries and X/Motif's widgets (such as Push Button widget to quit) alone, without including GL libraries such as "" and "". Specifically, is it possible to replace Openpipeline() and DrawChannel() by similar functions using Motif widgets? Regards, Masaki Aono E-mail: aono@trl.ibm.co.jp From guest Thu Jun 16 01:30:08 1994 Date: Thu, 16 Jun 94 09:54:29 +0100 From: arnaud@thomson-dsi.fr (AST ) Message-Id: <9406160854.AA23933@thodsic.cergy.thomson-dsi.fr> To: info-performer@sgi.sgi.com Subject: Textured geosets in multiple windows Status: O I seem unable to draw one textured geoset in 2 separate windows created by winopen. The call to pfDrawGSet in the 1st window gives a correct result, but I get no texture in the 2nd window. Any ideas ? Here is one simple code that reproduces this bug: void main( int argc, char *argv[] ) { pfGeoSet *gset; pfGeoState *gset_state; pfTexture *tex; pfTexEnv *tex_env; /* ---------------------------- Initialization of Performer ---------------------------- */ pfInit(); arena = pfGetSharedArena(); /* ----------------------- Creation of one geoset ----------------------- */ gset = build_gset(); pfInitState(NULL); pfNewState(); gset_state = pfNewGState(arena); pfGStateMode(gset_state, PFSTATE_ENTEXTURE, PFTR_ON); /* -------------------------------------------- Creation of one pfTexture and one pfTexEnv -------------------------------------------- */ tex = pfNewTex(arena); tex_env = pfNewTEnv(arena); pfLoadTexFile(tex, "image.rgb"); pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex); pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex_env); /* ------------------------------------ Creation of 2 windows with winopen ------------------------------------ */ init_windows(); /* ------------------------------------ Drawing of geoset in first window --> correctly textured ------------------------------------ */ winset(wid1); pfApplyTEnv(tex_env); pfApplyTex(tex); pfEnable(PFEN_TEXTURE); pfDrawGSet(gset); sleep(1); /* ------------------------------------ Drawing of geoset in second window --> no texture !? ------------------------------------ */ winset(wid2); pfApplyTEnv(tex_env); pfApplyTex(tex); pfEnable(PFEN_TEXTURE); pfDrawGSet(gset); sleep(10); } From guest Thu Jun 16 02:32:34 1994 From: "Sharon Fischler" Message-Id: <9406160230.ZM11111@rose.asd.sgi.com> Date: Thu, 16 Jun 1994 02:30:58 -0700 In-Reply-To: arnaud@thomson-dsi.fr (AST ) "Textured geosets in multiple windows" (Jun 16, 9:54am) References: <9406160854.AA23933@thodsic.cergy.thomson-dsi.fr> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: arnaud@thomson-dsi.fr (AST ), info-performer@sgi.sgi.com Subject: Re: Textured geosets in multiple windows Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O +>---- On Jun 16, 9:54am, AST wrote: > Subject: Textured geosets in multiple windows -> ->I seem unable to draw one textured geoset in 2 separate windows created by winopen. The call to ->pfDrawGSet in the 1st window gives a correct result, but I get no texture in the 2nd window. ->Any ideas ? No problem. You simply need a separate pfState for each window and select corresponding state for the current window (pfSelectState). A full working test program (adapted from your test case) is included below. -> ->Here is one simple code that reproduces this bug: FYI: your test case also did have one bad typo: -> pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex); -> pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex_env); ^^^^^^^^^^^^^^ should be PFSTATE_TEXENV #include "Performer/pr.h" pfVec3 coords[] ={ {-1.0f, -1.0f, -5.0f }, { 1.0f, -1.0f, -5.0f }, { 1.0f, 1.0f, -5.0f }, {-1.0f, 1.0f, -5.0f } }; pfVec4 colors[] ={ {1.0f, 1.0f, 1.0f, 1.0f}, {0.0f, 0.0f, 1.0f, 1.0f}, {1.0f, 0.0f, 0.0f, 1.0f}, {0.0f, 1.0f, 0.0f, 1.0f} }; pfVec2 texcoords[]={ {0.0f, 0.0f}, {1.0f, 0.0f}, {1.0f, 1.0f}, {0.0f, 1.0f} }; long Wid1, Wid2; static void init_windows(void); static pfGeoSet *build_gset(void); long main( int argc, char *argv[] ) { pfGeoSet *gset; pfGeoState *gset_state; pfTexture *tex; pfTexEnv *tex_env; pfState *s1, *s2; /* ---------------------------- Initialization of Performer ---------------------------- */ pfInitState(NULL); s1 = pfNewState(); s2 = pfNewState(); /* ----------------------- Creation of one geoset ----------------------- */ gset = build_gset(); gset_state = pfNewGState(NULL); pfGSetGState (gset, gset_state); pfGStateMode(gset_state, PFSTATE_ENTEXTURE, PFTR_ON); /* -------------------------------------------- Creation of one pfTexture and one pfTexEnv -------------------------------------------- */ tex = pfNewTex(NULL); tex_env = pfNewTEnv(NULL); pfLoadTexFile(tex, "brick.rgba"); pfGStateAttr(gset_state, PFSTATE_TEXTURE, tex); pfGStateAttr(gset_state, PFSTATE_TEXENV, tex_env); /* ------------------------------------ Creation of 2 windows with winopen ------------------------------------ */ init_windows(); winset(Wid1); pfSelectState(s1); pfDrawGSet(gset); sleep(1); winset(Wid2); pfSelectState(s2); pfDrawGSet(gset); sleep(10); return 0; } static void init_windows(void) { long xs, ys; foreground(); prefposition(0, 400, 0, 400); Wid1 = winopen("Performer cubes"); RGBmode(); gconfig(); mmode(MVIEWING); lsetdepth(getgdesc(GD_ZMIN), getgdesc(GD_ZMAX)); subpixel(TRUE); backface(FALSE); getsize(&xs, &ys); ortho(-1, 1, -1, 1, 1, 10); prefposition(0, 400, 400, 800); foreground(); Wid2 = winopen("Performer cubes"); RGBmode(); gconfig(); mmode(MVIEWING); lsetdepth(getgdesc(GD_ZMIN), getgdesc(GD_ZMAX)); subpixel(TRUE); backface(FALSE); getsize(&xs, &ys); ortho(-1, 1, -1, 1, 1, 10); } pfGeoSet* build_gset(void) { pfGeoSet *gset; gset = pfNewGSet(NULL); pfGSetAttr(gset, PFGS_COORD3, PFGS_PER_VERTEX, coords, NULL); pfGSetAttr(gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, texcoords, NULL); pfGSetAttr(gset, PFGS_COLOR4, PFGS_PER_VERTEX, colors, NULL); pfGSetPrimType(gset, PFGS_QUADS); pfGSetNumPrims(gset, 1); return gset; } -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Thu Jun 16 01:40:28 1994 From: desmond@iss.nus.sg (Desmond Hii Toh Onn) Message-Id: <9406160846.AA12867@charon> Subject: TG_CONTOUR To: info-performer@sgi.sgi.com Date: Thu, 16 Jun 1994 01:46:25 -0800 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 277 Status: O Greetings, I've implemented texgen using the predraw and postdraw callbacks and it works pretty well for TG_SPHEREMAP So one day, I tried it with TG_CONTOUR and It doesn't look like it's working. Is there anything that i missed. The effect is like TG_LINEAR. thanks des' From guest Thu Jun 16 11:25:19 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406161825.AA05103@tubes.asd.sgi.com> Subject: Re: Coloring Models in Performer To: guest (Curtis L. Goodhart) Date: Thu, 16 Jun 94 11:25:06 PDT Cc: info-performer@sgi.sgi.com, goodhart@cod.nosc.mil In-Reply-To: <9406152128.AA27499@cod.nosc.mil>; from "Curtis L. Goodhart" at Jun 15, 94 2:28 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > I am using perfly to implement a specific type of object selection > algorithm. I want to be able to change the color of some model > dynamically. For example at some given time I want to change the > color of the geometry under node X to red. Currently I think that > node X is a DCS. > > The data files that I've tried this with are flt format files, > obj files, and iv files. > > When I do what follows below all that happens is that the model turns > grey instead of the desired color. > > 1) Let's say I load 4 data files (4 separate objects) such as > 4 enterprise.flt files. > ie: > > perfly enterprise.flt enterprise.flt enterprise.flt enterprise.flt > > c) My SW selects one of those objects (models) and attempts to change > its color. I do this in a node call back function during > the draw traversal. > > So I execute the following when I am reading in the model files. > ptrToNode is a pointer to the node that gets set up when perfly > loads a file. > > int mydata; > pfNodeTravFuncs(ptrToNode, PFTRAV_DRAW, clgpreDraw, clgpostDraw); > pfNodeTravData(ptrToNode, PFTRAV_DRAW, &mydata); > > In the preDraw function I intend to color the object red > when test is set: > > long > clgpreDraw(pfTraverser *trav, void *data) > { > int test; > static int firsttime = 0; > static pfMaterial *ahaPreselectMtl; > > /* Please forgive this hack of setting the material here > * I intend to move it to an initialization file when I > * get things working. > */ > if (!firsttime) > { > firsttime = 1; > ahaPreselectMtl = pfNewMtl(NULL); > } > > test = *(int *) data; > if (test) > { > pfPushState(); > pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_CMODE_COLOR); > > /* I also tried it with the following statement included - nodifference > * pfMtlColorMode(ahaPreselectMtl, PFMTL_BOTH, LMC_AD); > */ > pfMtlColor(ahaPreselectMtl, PFMTL_DIFFUSE, 1.0, 0.0, 0.0); > pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_ON); > pfApplyMtl(ahaPreselectMtl); > } > return PFTRAV_CONT; > } > > The postDraw function to restore the state is: > > long > clgpostDraw(pfTraverser *trav, void *data) > { > int test; > > test = *(int *)data; > > if (test) > { > pfOverride(PFSTATE_FRONTMTL | PFSTATE_BACKMTL, PF_OFF); > pfPopState(); > } > return PFTRAV_CONT; > } > > > > The idea is that whenever test is 1 I want to change the color > of that object to red. > > When I use what I show you above the material of the selected > object becomes gray rather than red. > > This code seems to work ok when I change the selected object to > wireframe rather than coloring the object red (ie I just do a > pfEnable(PFEN_WIREFRAME) in the preDraw, and a > pfDisable(PFEN_WIREFRAME) in the postDraw. > > > 3) We are running on an Onyx running IRIX 5.2 and using > Performer 1.2. > > > Thank you, > > Curt Goodhart > > > > > > From guest Thu Jun 16 12:06:18 1994 From: "Sharon Fischler" Message-Id: <9406161206.ZM12134@rose.asd.sgi.com> Date: Thu, 16 Jun 1994 12:06:02 -0700 In-Reply-To: goodhart@cod.nosc.mil (Curtis L. Goodhart) "Coloring Models in Performer" (Jun 15, 2:28pm) References: <9406152128.AA27499@cod.nosc.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: goodhart@cod.nosc.mil (Curtis L. Goodhart), info-performer@sgi.sgi.com Subject: Re: Coloring Models in Performer Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O +>---- On Jun 15, 2:28pm, Curtis L. Goodhart wrote: > Subject: Coloring Models in Performer -> ->I am using perfly to implement a specific type of object selection ->algorithm. I want to be able to change the color of some model ->dynamically. For example at some given time I want to change the ->color of the geometry under node X to red. Currently I think that ->node X is a DCS. -> Performer highlighting was implemented in 1.2 specifically for this purpose. You can temporarily change the color of an object, draw it with outlines, or interesting multi-color patterns, and even make them transparent - all without destroying the man pfGeoState of the object. You can highlight specific pfGeoStates, turn it on on a pfGeoState, or enable it globally. The pickfly example uses highlighting to color the selected object. /usr/src/Performer/src/sample/pickfly There is a highlighting example at /usr/src/Performer/pguide/libpr/progs/hlcube.c and you can man on pfHighlight. srf. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Thu Jun 16 12:30:49 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406161930.AA05192@tubes.asd.sgi.com> Subject: Re: Mouse input To: guest (Angus Henderson) Date: Thu, 16 Jun 94 12:30:57 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406151648.AA07390@death.reading.sgi.com>; from "Angus Henderson" at Jun 15, 94 5:48 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > What is the best way of determining which channel the mouse is in, on > a 3 chaannel, 3 pipe performer application ? > > I am using pfuGetMouse, but I need to collectInput in whichever > channel/pipe has the mouse. I am using GL input. > > a.t.b > > ANgus > > The Sharks Are Swimming Again > > "Imagine your witty quote here" I know of no easy way to find out which pipe the cursor is in and the comment in collectGLInput, which implies that mouse x/y are returned as -1 if the cursor is not in the collecting pipe, no longer seems to be correct. -jr From guest Thu Jun 16 12:51:15 1994 From: "Drew Hess" Message-Id: <9406161250.ZM21841@airy.arc.nasa.gov> Date: Thu, 16 Jun 1994 12:50:48 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: multiple pfChannels vs. multiple pfPipes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O I want to render several views of the same scene on a 4-processor Onyx/RE2 (one RE2 pipeline at this point) in a Performer application. Is it generally better to configure Performer to use one pfPipe and multiple pfChannels, using channel groups to share as much state information as possible; or should I use multiple pfPipes and split the number of channels up evenly among the pfPipes? Also, if I get a second RE2 pipeline then obviously I would want multiple pfPipes, but assuming I still need more pfChannels than I have hardware pipelines, then I would assume the same partitioning issue applies. (That is, do I create 2 pfPipes -- one for each RE2 pipeline -- and split up the pfChannels among them or do I create multiple pfPipes per hardware pipeline and reduce the number of pfChannels per software pipe (i.e. pfPipes)?) Thanks -dwh- dhess@vision.arc.nasa.gov dhess@cs.stanford.edu From guest Thu Jun 16 13:21:40 1994 From: "Chris Tanner" Message-Id: <9406161321.ZM1110@faith.asd.sgi.com> Date: Thu, 16 Jun 1994 13:21:08 -0700 In-Reply-To: desmond@iss.nus.sg (Desmond Hii Toh Onn) "TG_CONTOUR" (Jun 16, 1:46am) References: <9406160846.AA12867@charon> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: desmond@iss.nus.sg (Desmond Hii Toh Onn), info-performer@sgi.sgi.com Subject: Re: TG_CONTOUR Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 16, 1:46am, Desmond Hii Toh Onn wrote: > Subject: TG_CONTOUR > Greetings, > I've implemented texgen using the predraw and postdraw > callbacks and it works pretty well for TG_SPHEREMAP > > So one day, I tried it with TG_CONTOUR and It doesn't look > like it's working. Is there anything that i missed. The effect > is like TG_LINEAR. > > thanks > > des' > > > > >-- End of excerpt from Desmond Hii Toh Onn I originally had the same problem when recently implementing callbacks to attenuate light points using texgen. The answer is that texgen uses the model viewing matrix when texgen is actually called verses the model view matrix when the geometry is draw to figure out the transforms necessary for TG_CONTOUR. Thus, because you attach the callbacks to the leaf nodes in performer, the model view matrix is always the same when you call texgen as when you draw the geometry. Thus the effect is that of TG_LINEAR. The workaround is quite simple, just load the model view matrix with the identity matrix before calling texgen then pop it afterwards. SO... example performer code: long pfuPreDrawContour(pfTraverser *trav, void *data) { (trav, trav); (data, data); mmode(MVIEWING); pushmatrix(); loadmatrix(IdentMat); texgen(TX_S, TG_CONTOUR, params2); texgen(TX_T, TG_CONTOUR, params3); texgen(TX_S, TG_ON, NULL); texgen(TX_T, TG_ON, NULL); popmatrix(); return NULL; } long pfuPostDrawContour(pfTraverser *trav, void *data) { (trav, trav); (data, data); texgen(TX_S, TG_OFF, NULL); texgen(TX_T, TG_OFF, NULL); return NULL; } -- _____________________________________________________________ Chris Tanner (cct@faith.asd.sgi.com) Silicon Graphics - Advanced Graphics Division _____________________________________________________________ From guest Thu Jun 16 13:27:27 1994 From: aaron@qbert.dseg.ti.com (Aaron Hightower) Subject: Re: multiple pfChannels vs. multiple pfPipes To: iris-performer@sgi.sgi.com Date: Thu, 16 Jun 1994 15:30:21 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2411 Status: O "Attribution from author Drew Hess" > From holodeck.asd.sgi.com!guest Thu Jun 16 15:09:57 1994 > From: "Drew Hess" > Message-Id: <9406161250.ZM21841@airy.arc.nasa.gov> > Date: Thu, 16 Jun 1994 12:50:48 -0700 > X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) > To: info-performer@sgi.com > Subject: multiple pfChannels vs. multiple pfPipes > Content-Type: text/plain; charset=us-ascii > Mime-Version: 1.0 > > I want to render several views of the same scene on a 4-processor Onyx/RE2 (one > RE2 pipeline at this point) in a Performer application. > > Is it generally better to configure Performer to use one pfPipe and multiple > pfChannels, using channel groups to share as much state information as > possible; or should I use multiple pfPipes and split the number of channels up > evenly among the pfPipes? From the man page for pfPipe: A pfPipe is tied to a specific hardware pipeline according to the hardware screen that the graphics window is opened on. In initFunc, scrnselect should be used to select a hardware pipeline. If initFunc is NULL, the full-screen window will be opened on the hardware pipeline whose id corresponds to the pfPipe id, e.g.- scrnselect(1); will be used for pfPipe number 1. For best performance only one pfPipe should render ^^^^^^^^^^^^^^^^ to a given hardware pipeline. If multiple views on a single screen are desired, use multiple pfChannels. > Also, if I get a second RE2 pipeline then obviously I would want multiple > pfPipes, but assuming I still need more pfChannels than I have hardware > pipelines, then I would assume the same partitioning issue applies. (That is, > do I create 2 pfPipes -- one for each RE2 pipeline -- and split up the > pfChannels among them or do I create multiple pfPipes per hardware pipeline and > reduce the number of pfChannels per software pipe (i.e. pfPipes)?) Hope this helps, _ _ | | *-------------------------------------------* | | __| |___ | Aaron.Hightower@dseg.ti.com 214.575.6759 | __| |___ \ / | Simulation & Planning Technology | \ / \_ / | 6620 Chase Oaks Blvd M/S 8518 | \_ / \ ( | Plano TX 75023 | \ ( \/ *-------------------------------------------* \/ From guest Fri Jun 17 12:38:19 1994 Message-Id: <00581.2854634693.1483@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Thu, 16 Jun 1994 16:38:15 PST Subject: meshing triangles Status: O REGARDING meshing triangles Hi All, I've found that pfuMeshGSet(3pf) requires the pfGeoSet vertices be in a particular order for meshing to occur. I believe that the vertices must be ordered as described in bgntmesh(3g), i.e. [v0,v1,v2], [v3,v2,v1]. pfGeoSet vertices that would mesh with the help of swaptmesh(3g) are not meshed by pfuMeshGSet(). Does anyone have a routine to order the vertices within a pfGeoSet so that pfuMeshGSet() will actually mesh them? Thanks in advance, Mark Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4110 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET From guest Fri Jun 17 08:12:56 1994 From: "Michael Jones" Message-Id: <9406170812.ZM3996@babar.asd.sgi.com> Date: Fri, 17 Jun 1994 08:12:48 -0700 In-Reply-To: "Marc SIMON Presales support" "Fog on RE" (Jun 17, 3:14pm) References: <9406171514.ZM20930@girl.paris.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Marc SIMON Presales support" , info-performer@sgi.sgi.com Subject: Re: Fog on RE Cc: mtj@giraffe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 17, 3:14pm, Marc SIMON Presales support wrote: > Subject: Fog on RE :Testing some customers codes using fog with perforemr 1.2 seems to show a :problem with the resolution of the fog table on the RE2. : :Thanks to explain to me what's happend . Is it a bug ?? Is there a way to :avoid this ?? We'll check into this. :My customer is today waiting for an answer to decide to continue or to :stop with Performer . If your customer thinks the problem is in the RE2, then why would they think that not using Performer (while still using the RE) could make the situation better? Several fog-related questions have come up lately. Perhaps we need to expand the Programming Guide's section on pfFog control and operation in the next release of the manual. -- Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:9U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Fri Jun 17 14:06:17 1994 Date: Fri, 17 Jun 94 14:06:08 -0700 From: stimpy@niesten.arc.nasa.gov (William Briggs) Message-Id: <9406172106.AA12633@niesten.arc.nasa.gov> To: info-performer@sgi.sgi.com Subject: pfPhase() Status: O We are using: SkyWriter VGXT, IRIX 4.0.5, Performer 1.0 My situation: Our app has always been used with pfPhase set to PFPHSE_FREE_RUN. Now we need a fixed frame rate for taking experimental data. By setting the phase to PFPHASE_LOCK the app is still looping, but the display is frozen. I can change at will between PFPHASE_LOCK and PFPHASE_FLOAT and the app loops with no new display. Whenever I set the phase back to PFPHASE_FREE_RUN, the app loops three more times, then hangs. I have tried making PFPHASE_LOCK the default (so we are not changing it dynamically) but with the same results. We have never had any problems changing the framerate while in PFPHASE_FREE_RUN. My questions: How do I get it to work? :^) More specifically, are we supposed to be able to change the phase dynamically? Is this frozen display a bug in our code, or somewhere else? Why would it hang when going to PFPHASE_FREE_RUN? -------------------+------------------------------+------------------------ William Briggs | MailStop 262-2 | "The computer screen NASA Ames Research | PO Box 1000 | has become the retina (415) 604-6438 | Moffett Field, CA 94035-1000 | of the mind's eye." -------------------+------------------------------+------------------------ From guest Fri Jun 17 06:09:05 1994 From: "Marc SIMON Presales support" Message-Id: <9406171514.ZM20930@girl.paris.sgi.com> Date: Fri, 17 Jun 1994 15:14:06 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Fog on RE Cc: mtj@giraffe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Testing some customers codes using fog with perforemr 1.2 seems to show a problem with the resolution of the fog table on the RE2. When using FG_PIX_LIN or FG_PIX_EXP or FG_PIX_EXP2 with a far fog of 1000 m for instance and when drawing an object at 1100 m it is still visible. I known that it is of course related to the range of Z value defining by the near and far clipping plane and the lsetdepth value.But it works fine on a Indigo2 Extreme... You can try : - perfly enterprise.flt The model appear at ~ 2600 m from the viewer - fog on (Exponential or linear) - move the far fog to 2500 m . - You could see that the Mister Spoke ears are always visible... Try to do the same on Extreme GFX ... It works fine. Thanks to explain to me what's happend . Is it a bug ?? Is there a way to avoid this ?? My customer is today waiting for an answer to decide to continue or to stop with Performer . Thanks to help me quickly. -- -- Marc -- Marc SIMON Presales support =========================== --------- ////// // // ////// /////// /////// ----------- // // / / // // // / / // --------- ///// // / // ///////// /////// // ----------- // // // // // /// // --------- /////// // // // // / /// /////// ---------- Silicon Graphics France 21 Rue Albert Calmette Jouy-en-Josas 78350 FRANCE Tel (33) 1 34-88-80-00 email : smarc@paris.sgi.com ++++++++++++++++++++++++++++ smarc@paris.sgi.com **************************** From guest Mon Jun 20 01:47:42 1994 From: "Ran Yakir" Message-Id: <9406201147.ZM1394@rea1.bvr.co.il> Date: Mon, 20 Jun 1994 11:47:16 +0000 X-Face: aaaaaaaaaaljasddfjsdlkfjasd X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfMultiPipe + pfMultiProcess Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi A problem : Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual pipe performer application. The following pfMultiProcess modes give you the following results : 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - because you have only 4 CPUs) 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls in the same process No item here gives good results. This is due to the fact that multi-processing mode is the same for all pipes. If multi-processing mode was per pipe - I could run one pipe as PFMP_APPCULL_DRAW, and the other as PFMP_APP_CULL_DRAW. Then I would fully occupy my 4 CPUs. I know that 4 CPUs in not the bets configuration for running a dual pipe performer application, but I think that allowing a separate multi-processing mode for pipes would help in similar cases. Thanks Ran Yakir -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Mon Jun 20 02:24:31 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406201223.ZM11761@rea1.bvr.co.il> Date: Mon, 20 Jun 1994 12:23:18 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfApplyTex Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, My problem regards the calling of pfApplyTex(). After calling pfDraw() in my drawChannel cb, I draw some geometry involving texture. My code looks something like this: .... pfEnable(PFEN_TEXTURE); pfApplyTEnv(texenv); pfApplyTex(txt); .... draw geometry .... Sadly no texture appears on the geometry, gldebug confirms that neither tevbind nor texbind are called. However when calling pfPushState() just before the settings (and pfPopState() after drawing), makes all the difference. Now Performer draws the geometry using the desired texture (GLdebug.history recorded the calls to tevbind and texbind). One could argue and say that there was probably some overrides on the pfstate stack but calling pfGetOverride() yields no overrides. Well what is it that makes pfPushState() enable the texture calls? Thanks Alon From guest Mon Jun 20 03:00:55 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406201259.ZM11921@rea1.bvr.co.il> Date: Mon, 20 Jun 1994 12:59:42 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Seperate ISECT process Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O To: info-performer@sgi.com Hi, A week ago I came up with a problem regarding the use of a separate isect process, but unfortunately I did not receive an answer. Therefore I am sending the message again in case it was never received. ***************************************************************************** My application uses a separate process for intersection calls. (pfMultiprocess(PFMP_FORK_ISECT)). It seems that Performer lacks a two-way path between the APP process and the ISECT process. Currently changes done in the ISECT structure, in the APP process, are passed down to the isect_func() (the ISECT cb), but sadly enough it is not true the other way around. Since isects are done in a separate process and they are quite lengthy in time, it may take the process some time to come up with a result (could even take a couple of frames). Therefore it is important that a two-way data path is available between the two processes to enable a hand-shaking mechanism. Well, could or should Performer support a two-way data path? Meanwhile, is the only solution is the use of a globally defined, pre pfConfig, structure? Below are some relevant code lines from my application static void isect_func(void *userData) { IsectData *isect_data; isect_data = (IsectData *)userData; . . . } main() { . . . /* Initializing the ISECT cb */ pfIsectFunc(isect_func); isect_data = (IsectData *)pfAllocIsectData(sizeof(IsectData)); . . /* Main loop */ while (1) { . . . pfPassIsectData(); pfFrame(); } } Thanks Alon From guest Mon Jun 20 18:38:55 1994 Resent-From: aschaffe (Allan Schaffer) Resent-Message-Id: <9406201838.ZM4391@holodeck.asd.sgi.com> Resent-Date: Mon, 20 Jun 1994 18:38:49 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) Resent-To: info-performer@sgi.sgi.com From: jaydee@thor.ats.qc.ca (Jean Daigle) Date: Mon, 20 Jun 1994 09:55:39 -0400 In-Reply-To: "Ran Yakir" "pfMultiPipe + pfMultiProcess" (Jun 20, 11:47am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: guest Subject: Re: pfMultiPipe + pfMultiProcess Status: O On Jun 20, 11:47am, "Ran Yakir" wrote: } Subject: pfMultiPipe + pfMultiProcess } From guest@holodeck.asd.sgi.com Mon Jun 20 05:07:35 1994 } From: "Ran Yakir" } Date: Mon, 20 Jun 1994 11:47:16 +0000 } X-Face: aaaaaaaaaaljasddfjsdlkfjasd } X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) } To: info-performer@sgi.com } Subject: pfMultiPipe + pfMultiProcess } Content-Type: text/plain; charset=us-ascii } Mime-Version: 1.0 } } Hi } } A problem : } } Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual } pipe performer application. The following pfMultiProcess modes give you the } following results : } } 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) } 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - } because you have only 4 CPUs) } 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls } in the same process ... } }-- End of excerpt from "Ran Yakir" Have you tried PFMP_APP_CULLDRAW? This will utilize your 4 processors effectively -- 1 for UNIX, 1 for APP, 2 for CULL+DRAW for your two pipes. This would imply that your scene is light enough for CULL+DRAW to not frame-extend. Such has not been the case for us, but your mileage may vary. Your alternative of allowing per-pipe multiprocessing mode specification sounds attractive. I'd be very interested in trying it out should the wizards of Performerdom make this feature available. In the mean time, would it be at all possible to run two completely separate Performer instances, each configured for one of your two pipes, and communicating via shared memory for syncronization? Just a wild thought. Regards, Jean Daigle. ----------------------------------------------------------------- | Jean Daigle ATS AeroTechnologies Inc. | | Software Designer 1250 Boul Marie-Victorin | | St. Bruno, QC J3V 6B8 | | jaydee@ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 | ----------------------------------------------------------------- From guest Mon Jun 20 08:13:42 1994 Message-Id: <199406201512.IAA21256@archimedes.chinalake.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-performer@sgi.sgi.com From: jan@archimedes.chinalake.navy.mil (Jan A. Barglowski) Subject: Data Stream buffering/interpolation... Status: O Hello! While not graphics, this would be of VizSim importance. I have to buffer the incoming data stream from ethernet to our app for three reasons: 1) the data stream may be coming in at a fixed, known data rate *slower* than 30 Hz, 2) incoming packets may occasionally be lost, and 3) the data may "jerk" about -- move randomly about the "real" location (GPS margin of error). My first thought is to try a real-time spline function. This could possibly smooth the data to any rate I'd wish, but I haven't heard of any "predictive" algorithms (haven't started looking 'til now, either :-) If I didn't care about the possible visual descrepencies during the acquisition (I do), then I could do the interpolation after acquisition and before "playback". Questions are then: - What is a suitable splining (or other smoothing) function to use, that could possibly work real-time in a predictive manner? - What is a good way to interpolation the rotations (quaternions)? - Is this the proper way to approach this problem? - What are you doing, if you have this same problem? Any pointers to papers, books, code snippets, etc. welcome! Thanks! jan. Jan Anthony Barglowski Phone: (619) 927-1057 Computer Dude Internet: jan@archimedes.nwc.navy.mil Visualization Lab Packet: SYSOP@WA6YBN.#SOCA.CA.US.NA Naval Air Warfare Center kc6uth@kc6uth.ampr.org -Weapons Division [44.17.2.6] From guest Mon Jun 20 10:39:25 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406201739.AA08225@tubes.asd.sgi.com> Subject: Re: meshing triangles To: guest (Marcus) Date: Mon, 20 Jun 94 10:39:00 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <00581.2854634693.1483@multigenuunet.UU.NET>; from "Marcus" at Jun 16, 94 4:38 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > REGARDING meshing triangles > Hi All, > > I've found that pfuMeshGSet(3pf) requires the pfGeoSet vertices be in a > particular order for meshing to occur. > > I believe that the vertices must be ordered as described in bgntmesh(3g), > i.e. [v0,v1,v2], [v3,v2,v1]. pfGeoSet vertices that would mesh with the > help of swaptmesh(3g) are not meshed by pfuMeshGSet(). > > Does anyone have a routine to order the vertices within a pfGeoSet so that > pfuMeshGSet() will actually mesh them? > You can't rearrange the order of vertices without changing the front/back orientation of polygons. If you use backface culling for improved rendering performance (and you should), then you will get dropped polygons if you change their orientation. pfGeoSets do not use swaptmesh. There are many reasons for this; the most pertinent is that OpenGL has abolished swaptmesh. In conclusion, the tmesher does about the best it can with its current algorithm. From guest Mon Jun 20 11:04:19 1994 From: "Chris Tanner" Message-Id: <9406201104.ZM6984@faith.asd.sgi.com> Date: Mon, 20 Jun 1994 11:04:06 -0700 In-Reply-To: "Ran Yakir" "pfMultiPipe + pfMultiProcess" (Jun 20, 11:47am) References: <9406201147.ZM1394@rea1.bvr.co.il> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Ran Yakir" , info-performer@sgi.sgi.com Subject: Re: pfMultiPipe + pfMultiProcess Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 20, 11:47am, Ran Yakir wrote: > Subject: pfMultiPipe + pfMultiProcess > Hi > > A problem : > > Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual > pipe performer application. The following pfMultiProcess modes give you the > following results : > > 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) > 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - > because you have only 4 CPUs) > 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls > in the same process > > No item here gives good results. This is due to the fact that multi-processing > mode is the same for all pipes. If multi-processing mode was per pipe - I could > run one pipe as PFMP_APPCULL_DRAW, and the other as PFMP_APP_CULL_DRAW. Then I > would fully occupy my 4 CPUs. > I know that 4 CPUs in not the bets configuration for running a dual pipe > performer application, but I think that allowing a separate multi-processing > mode for pipes would help in similar cases. > > > Thanks > > Ran Yakir >-- End of excerpt from Ran Yakir Because of current complexities in the Performer MP framework, if you are using multiple pfPipes then you must have the cull process forked (because they dont share views and thus they dont share culls). This means that you should try just forking the cull (APP_CULLDRAW). That should give you (if you look at procs with ps for instance): 1) App 2) (a clock wrapper proc that doesnt eat much cpu)... 3) CullDraw 4) CullDraw Hope that helps... Later, Chris Tanner IRIS Performer Remember, if you really want best real-time results make sure you take a look at 'lockcpu.c' in the 1.2 /usr/src/Performer/src/lib/libpfutil directory such that you can lock the procs down on the corresponding cpus and ensure no competition for processors or context switches... -- _____________________________________________________________ Chris Tanner (cct@faith.asd.sgi.com) Silicon Graphics - Advanced Graphics Division _____________________________________________________________ From guest Tue Jun 21 08:35:52 1994 Date: Tue, 21 Jun 94 08:34:01 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406211534.AA12516@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: pfMakePtsPlane in Performer 1.2 for IRIX 4.05H Cc: goodhart@cod.nosc.mil Status: O Has anybody had any problems with the function pfMakePtsPlane. I've been getting segmentation violations (I think) when I call that function. I remember this problem in the past too, perhaps on a Beta version. Just wondering if anyone has seen any similar behavior. Running Performer 1.2 on IRIX 4.05H on a Crimson Reality Engine. Curt PS I haven't had any problem with this on Performer 1.2 for IRIX 5.2 on an Onyx. From guest Tue Jun 21 10:22:00 1994 From: "Wade Olsen" Message-Id: <9406211021.ZM14668@fnord.asd.sgi.com> Date: Tue, 21 Jun 1994 10:21:41 -0700 In-Reply-To: Masaki Aono "X-Motif + performer sample program" (Jun 16, 10:40am) References: <9406160140.AA23125@ns.trl.ibm.com> X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: Masaki Aono , info-performer Subject: Re: X-Motif + performer sample program Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 16, 10:40am, Masaki Aono wrote: > Subject: X-Motif + performer sample program > Dear Sirs/Madams: > > Is there a sample program that uses OSF/Motif as GUI in > Performer's program? I find that the sample program "intersect.c" > uses GL(qdevice(),qtest(), and qread()) as GUI (see "Pipeline", > March/April 1994, Vol.5, No.2). > > What I'd like to get is a sample program that uses Performer's > libraries and X/Motif's widgets (such as Push Button widget to > quit) alone, without including GL libraries such as "" and > "". > Specifically, is it possible to replace Openpipeline() and > DrawChannel() by similar functions using Motif widgets? > > > Regards, > Masaki Aono > E-mail: aono@trl.ibm.co.jp > > > > >-- End of excerpt from Masaki Aono Here you go: To extract, save this message to a file, do a "uudecode ", then a "tar xvfo performer_motif.tar" ----------------------------------------------------------------------- begin 644 performer_motif.tar M<&5R9F]R;65R7VUO=&EF+P`````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````#`P,#2P@ M=&AI2!I2!D;V5S('-O(&)Y(&]P96YI;F<@:71S"F]W;B!W:6YD;W&ES=&EN9R!'3%@@=VED9V5T(&-R96%T960@8GD@=&AE(&%P<&QI8V%T:6]N M"G!R;V-E2!S:6UP;&EF:65D+@H**B\*"B-I;F-L=61E(#QS=&1I;RYH M/@HC:6YC;'5D92`\7!E0H*"0D)"2\O(%1H:7,@R`B+6UP(BP@(BIM<%]M;V1E(BP@ M6')M;W!T:6]N4V5P07)G+"!.54Q,('TL"GT["@IS=&%T:6,@9FQO870@9&EA M;65T97(["0DO+R!$:6%M971E%]P;W,["0DO+R!# M=7)R96YT(&UO=7-E('!OF4["2\O($-UF4[ M"2\O('-H87)E9"!M96UOR!-3T1%7U=)4D5&4D%-12P@34]$15]415A455)%+"!.54U? M34]$15,@?3L*"G-T871I8R!S=')U8W0@9')A=U]M;V1E7W-TPH@("`@1TQ87TY/ M4DU!3"P@1TQ87T)51E-)6D4L("`)1TQ87TY/0T].1DE'+`H@("`@1TQ87TY/ M4DU!3"P@1TQ87UI325I%+"`@"4=,6%].3T-/3D9)1RP*("`@($=,6%].3U)- M04PL($=,6%]$3U5"3$4L"512544L"B`@("!'3%A?3D]234%,+"!'3%A?4D=" M+"`@(`E44E5%+`H@("`@1TQ87TY/4DU!3"P@1TQ87U=)3D1/5RP)1TQ87TY/ M3D4L"B`@("`P+"`P+"`P+`I].PH*"B\O($%N(%AT(&-A;&QB86-K(&9U;F-T M:6]N(&-A;&QE9"!W:&5N(&$@(F1R87<@;6]D92(@8G5T=&]N(&ES"B\O('1O M9V=L960N"@IS=&%T:6,@=F]I9"`*;6]D94-"*%=I9&=E="P@:6YT(&UO9&4L M(%AM5&]G9VQE0G5T=&]N0V%L;&)A8VM3=')U8W0@*B!C8BD*>PH@("`@9')A M=U]M;V1E2`](%A/<&5N1&ES<&QA>2AG;'A?:6YF;RT^9&ES<&QA>5]N86UE*3L* M("`@(%=I;F1O=R!G;'A?=VEN9&]W(#T@9VQX7VEN9F\M/GA7:6YD;W<["B`@ M("`*("`@(%A7:6YD;W=!='1R:6)U=&5S(&%T=')I8G5T97,["B`@("!81V5T M5VEN9&]W071TPH)("`@(&-O;F9I9UMI72YA%]W:6YD;W<[ M"@E]"@H)"0D)+R\@0V]N;F5C="!T:&4@1TP@8V]N=&5X="!T;R!T:&4*"0D) M"2\O($=,6'=I9&=E="!CPH@("`@PH@("`@("!I9B`H9')A=U]M;V1E'!O%]I;F9O"B\O('-T%]S:7IE M(#T@8V(M/G=I9'1H.PH)*G=I;E]Y7W-I>F4@/2!C8BT^:&5I9VAT.PH@("`@ M?0H*"0D)"2\O(%1H:7,@:&%P<&5NF5D+@H@("`@:68@*&-B+3YR96%S;VX@ M/3T@1VQX0U)?1TE.250I"B`@("!["@E$:7-P;&%Y("H@9&ES<&QA>2`](%AT M1&ES<&QA>2AW*3L*"5=I;F1O=R`@>%=I;F1O=R`](%AT5VEN9&]W*'2!S;R!D5]N86UE(#T@,#L*"6=L>%]I;F9O+3YX5VEN9&]W(#T@ M>%=I;F1O=SL*"@D)"0DO+R!296QE87-E(&5X8VQUPH) M=V]R:U]I9"`](%AT07!P061D5V]R:U!R;V,H87!P7V-O;G1E>'0L("A8=%=O M2D*("`@('L*"5AT4F5M M;W9E5V]R:U!R;V,H=V]R:U]I9"D["@H)"0D)+R\@268@=&AE2UW86ET M#L*("`@(&UO=7-E7WE?<&]S(#T@979E;G0M/GAB=71T;VXN M>3L*?0H*+R\@5&AIFEM+"`F87II;5]S:6XL("9A M>FEM7V-OFEM7W-I;B`J(&EN8VQ?8V]S.PH@("`@=FEE=U]P M;W-;,5T@/2!V:65W7V-E;G1EFEM7V-O MFEM.PH@("`@=FEE=U]D:7);,5T@/2!V:65W7VEN8VP["B`@ M("!V:65W7V1IPH@("`@:6YT(&YE M=U]X(#T@979E;G0M/GAM;W1I;VXN>#L*("`@(&EN="!N97=?>2`](&5V96YT M+3YX;6]T:6]N+GD["@H@("`@9FQO870@9'@@/2`H9FQO870I*&YE=U]X("T@ M;6]U%]P;W,I.PH@("`@9FQO870@9'D@/2`H9FQO870I*&YE=U]Y("T@ M;6]U5]P;W,I.PH*("`@(&UO=7-E7WA?<&]S(#T@;F5W7W@["B`@("!M M;W5S95]Y7W!O2X*("`@(&EF("A"=71T;VXQ M36%S:R`F(&5V96YT+3YX;6]T:6]N+G-T871E*0H@("`@>PH)9&ES=&%N8V4@ M*ST@+2AF86)S*&1I2`O(#$P,"XP*3L* M("`@('T*"@D)"0DO+R!2;W1A=&4@=&AE('9I97=E&UO M=&EO;BYS=&%T92D*("`@('L*"79I97=?87II;2`M/2!D>"`O(#(N,#L*"79I M97=?:6YC;"`M/2!D>2`O(#(N,#L*("`@('T*"@D)"0DO+R!4PH)9FQO870@9F]V7W@L(&9O=E]Y.PH)<&9'971# M:&%N1D]6*'1H94-H86YN96PL("9F;W9?>"P@)F9O=E]Y*3L*"@EF;&]A="!A M>FEM7W-I;BP@87II;5]C;W,["@EF;&]A="!I;F-L7W-I;BP@:6YC;%]C;W,[ M"@EP9E-I;D-OFEM7W-I;BP@)F%Z:6U?8V]S*3L* M"7!F4VEN0V]S*'9I97=?:6YC;"P@)FEN8VQ?"P@)GA?9G5D9V4L("9J=6YK*3L*"7!F4VEN0V]S*&9O=E]Y+"`F>5]F=61G M92P@)FIU;FLI.PH)>%]F=61G92`O/2`J=VEN7WA?F4["@H)=FEE=U]C96YT97);,%T@+3T*"2`@("`H87II M;5]C;W,@*B!D>"`J('A?9G5D9V4@*R!A>FEM7W-I;B`J("@M:6YC;%]S:6XI M("H@9'D@*B!Y7V9U9&=E*0H)"2H@9&ES=&%N8V4["@EV:65W7V-E;G1EFEM7W-I;B`J(&1X("H@>%]F=61G92`K(&%Z:6U?8V]S M("H@:6YC;%]S:6X@*B!D>2`J('E?9G5D9V4I"@D)*B!D:7-T86YC93L*"79I M97=?8V5N=&5R6S)=("T]"@D@("`@*"UI;F-L7V-O2`J(&1I5]F=61G93L*("`@('T*"B`@("!A9&IUF4H)B!A<'!?8V]N=&5X="P@(E!F36]T:68B+`H)"0D)(&]P=&EO M;G,L(%AT3G5M8F5R*&]P=&EO;G,I+`H)"0D)("9A4QE=F5L*%!&3D997U=!4DXI.PH@ M("`@=F]I9"`J(&%R96YA(#T@<&9'9713:&%R961!2!A%]I;F9O7W-TF5O9BAD$YG M:6YI=$-A;&QB86-K+`H)"2`@*%AT0V%L;&)A8VM0$YR97-I>F5#86QL8F%C:RP* M"0D@("A8=$-A;&QB86-K4')O8RER961R87=#0BP@,"D["B`@("!8=$%D9$5V M96YT2&%N9&QE"!B;W5N9#L*("`@('!F1V5T M3F]D94)";W@H9&%T82P@)B!B;W5N9"P@,"D["B`@("!P9E9E8S,@"D["B`@("!P9E-U8E9E8S,HF5;,ETI.PH@("`@9&ES=&%N8V4@ M/2!D:6%M971E2!F2D*>PH@("`@*G@@/2`P.PH@("`@*GD@/2`P.PI]"@IE>'1E"P@;&]N9R`J('DI"GL*("`@("IX(#T@ M*G=I;E]X7W-I>F4["B`@("`J>2`]("IW:6Y?>5]S:7IE.PI]"FEN*#0U+C`@ M+R`R("H@35]022`O(#$X,"DI.PH*("`@('!F0VAA;DYE87)&87(H=&AE0VAA M;FYE;"P@9&EA;65T97(@+R`Q,"XP+"!D:6%M971E Message-Id: <199406211728.KAA25367@well.sf.ca.us> To: info-performer@sgi.sgi.com Subject: Splitting pfPipes across several machines Status: O We have a customer who is interested in using Performer where each pfPipe is on a separate machine rather than being separate pipes in a single machine. Has anyone tried to do this? Ian Fakespace Inc. (415) 688 1940 From guest Tue Jun 21 10:48:56 1994 Message-Id: <9406211748.AA22830@surreal.asd.sgi.com> To: goodhart@cod.nosc.mil (Curtis L. Goodhart) Cc: info-performer@sgi.sgi.com Subject: Re: pfMakePtsPlane in Performer 1.2 for IRIX 4.05H In-Reply-To: Your message of "Tue, 21 Jun 94 08:34:01 PDT." <9406211534.AA12516@cod.nosc.mil> Date: Tue, 21 Jun 94 10:48:46 -0700 From: Jim Helman Status: O The code for this routine is extremely simple and is identical in 1.1 and both 1.2 versions (5.2 and 4.0.5). I can't think of any reason why it would behave differently on 4.0.5H vs. 5.2 or on a Crimson vs. Onyx. Bad FP values or colinear points could cause an FP exception, but as far as I can tell, a SEGV would only be caused by a bad pointer either one of the pfVec3 src args or the pfPlane* dst arg. Can you get it to fail in a simple case? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 Date: Tue, 21 Jun 94 08:34:01 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) To: info-performer@sgi.sgi.com Subject: pfMakePtsPlane in Performer 1.2 for IRIX 4.05H Has anybody had any problems with the function pfMakePtsPlane. I've been getting segmentation violations (I think) when I call that function. I remember this problem in the past too, perhaps on a Beta version. Just wondering if anyone has seen any similar behavior. Running Performer 1.2 on IRIX 4.05H on a Crimson Reality Engine. Curt PS I haven't had any problem with this on Performer 1.2 for IRIX 5.2 on an Onyx. From guest Tue Jun 21 11:16:36 1994 Message-Id: <9406211816.AA22934@surreal.asd.sgi.com> To: "Ran Yakir" Cc: info-performer@sgi.sgi.com Subject: Re: multi-channel synchronizing In-Reply-To: Your message of "Tue, 21 Jun 94 20:23:37 -0000." <9406212023.ZM11108@amcor.bvr.co.il> Date: Tue, 21 Jun 94 11:16:27 -0700 From: Jim Helman Status: O I can think of two things that might contribute to this: 1) You don't mention whether your pipes are genlocked. When driving multiple pipes from the same Performer application, it's important that the pipes be genlocked for good synchronization. 2) There's a bug in 1.2 regarding the vertical retrace clock initialization in multiple hardware pipes. We don't initialize them so they can be out of sync. The workaround is to do it yourself by simulataneously (i.e. within the same video field) calling pfInitVClock(0.0). A good place to do this synchronization is during the first invocation of the channel draw callback. Something like this should work: if first invocation of a channel draw callback on this pfPipe { wait for other draw processes to reach this point /* block on pipe until next retrace */ gsync(); cpack(0x000000); /* initialize clocks */ pfInitVClock(0.0f); } rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 21 11:30:26 1994 Message-Id: <9406211830.AA22961@surreal.asd.sgi.com> To: "Ian E. McDowall" Cc: info-performer@sgi.sgi.com Subject: Re: Splitting pfPipes across several machines In-Reply-To: Your message of "Tue, 21 Jun 94 10:28:58 PDT." <199406211728.KAA25367@well.sf.ca.us> Date: Tue, 21 Jun 94 11:30:13 -0700 From: Jim Helman Status: O > We have a customer who is interested in using Performer > where each pfPipe is on a separate machine rather than > being separate pipes in a single machine. Has anyone > tried to do this? Several things are required: 1) The hardware pipes should be genlocked. 2) You need a mechanism to synchronize the notions of time (pfInitClock and pfInitVClock). This requires some network mechanism for time synchronization, preferably down to a around a millisecond. I think network time protocols like NTP might come close. Once you have time of day and pfGetTime synced to well under a video frame period, syncing the VClocks can be done with a little communication over standard ethernet. 3) If you want visual coherency down to individual video fields, you also need to synchronize swapbuffers so that the displays won't get out of sync by a video field if one pipe frame extends. You can do this pretty well using a very low-latency interface such as SCRAMNet or a VMIC shared memory, but there will still be a small "hairy edge" where sync failure is possible. Reality Engine has a GANGSWAP wire which allows synchronization of swapbuffers across multiple pipes. The pfChanShare attribute PFCHAN_SWAPBUFFERS_HW enables this. HOWEVER, this mode should only be used in dedicated full screen applications. GANGSWAP cannot coexist with cursor changes (e.g. crossing X window borders). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 21 11:42:50 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406211842.AA09399@tubes.asd.sgi.com> Subject: Re: Seperate ISECT process To: guest (Alon Rosenfeld 18 Hatzedef street Jaffa) Date: Tue, 21 Jun 94 11:42:37 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406201259.ZM11921@rea1.bvr.co.il>; from "Alon Rosenfeld 18 Hatzedef street Jaffa" at Jun 20, 94 12:59 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > > To: info-performer@sgi.com > > > Hi, > > A week ago I came up with a problem regarding the use of a separate isect > process, but unfortunately I did not receive an answer. Therefore I am sending > the message again in case it was never received. > > ***************************************************************************** > > My application uses a separate process for intersection calls. > (pfMultiprocess(PFMP_FORK_ISECT)). > > > It seems that Performer lacks a two-way path between the APP process > and the ISECT process. Currently changes done in the ISECT structure, > in the APP process, are passed down to the isect_func() (the ISECT cb), > but sadly enough it is not true the other way around. > > Since isects are done in a separate process and they are quite lengthy in time, > it may take the process some time to come up with a result (could even take a > couple of frames). Therefore it is important that a two-way data path is > available between the two processes to enable a hand-shaking mechanism. > > > Well, could or should Performer support a two-way data path? > Meanwhile, is the only solution is the use of a globally defined, pre pfConfig, > structure? Performer is conceptually structured as pipelines, either intersection or drawing, where data flows only downstream. The semantics of upstream data propagation are a bit sticky so we've left it up to the user. A pre-pfConfig-allocated chunk of shared memory or pfDataPool should work fine for APP/ISECT handshaking. From guest Tue Jun 21 11:47:04 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406211846.AA09416@tubes.asd.sgi.com> Subject: Re: pfApplyTex To: guest (Alon Rosenfeld 18 Hatzedef street Jaffa) Date: Tue, 21 Jun 94 11:46:54 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406201223.ZM11761@rea1.bvr.co.il>; from "Alon Rosenfeld 18 Hatzedef street Jaffa" at Jun 20, 94 12:23 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi, > > My problem regards the calling of pfApplyTex(). > > After calling pfDraw() in my drawChannel cb, I draw some geometry > involving texture. My code looks something like this: > > .... > pfEnable(PFEN_TEXTURE); > pfApplyTEnv(texenv); > pfApplyTex(txt); > > .... draw geometry .... > > Sadly no texture appears on the geometry, gldebug confirms that neither tevbind > nor texbind are called. However when calling pfPushState() just before the > settings (and pfPopState() after drawing), makes all the difference. Now > Performer draws the geometry using the desired texture (GLdebug.history > recorded the calls to tevbind and texbind). One could argue and say that there > was probably some overrides on the pfstate stack but calling pfGetOverride() > yields no overrides. > > Well what is it that makes pfPushState() enable the texture calls? > Darned if I know. Perhaps pfGetOverride is faulty. Are you overriding any texture state in other places? As an experiment, call pfFlushState instead of pfPush/PopState. From guest Tue Jun 21 12:03:52 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406211903.AA09441@tubes.asd.sgi.com> Subject: Re: pfMultiPipe + pfMultiProcess To: guest (Ran Yakir) Date: Tue, 21 Jun 94 12:03:37 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406201147.ZM1394@rea1.bvr.co.il>; from "Ran Yakir" at Jun 20, 94 11:47 am X-Mailer: ELM [version 2.3 PL8] Status: O > > Hi > > A problem : > > Lets say you have a 4 CPU, dual headed ONYX machine, and you want to run a dual > pipe performer application. The following pfMultiProcess modes give you the > following results : > > 1. PFMP_APPCULLDRAW - runs both channels on one CPU (bad) > 2. PFMP_DEFAULT, PFMP_APP_CULL_DRAW - runs the system with 5 processes (bad - > because you have only 4 CPUs) > 3. PFMP_APPCULL_DRAW - not permited, because performer won't allow both culls > in the same process > > No item here gives good results. This is due to the fact that multi-processing > mode is the same for all pipes. If multi-processing mode was per pipe - I could > run one pipe as PFMP_APPCULL_DRAW, and the other as PFMP_APP_CULL_DRAW. Then I > would fully occupy my 4 CPUs. This makes sense if the culling loads for your 2 pipes are not balanced. The pipe with PFMP_APP_CULL_DRAW will have an entire CPU dedicated to culling while the PFMP_APPCULL_DRAW pipe will have to share APP with CULL. In general I am not in favor of asymmetric multiprocessing pipelines. It complicates Performer's API, semantics and internal code. The salient issue here is how to attain better load balancing. Performer's multiprocessing granularity is coarse which hampers load balancing but I believe the dividends of vastly reduced synchronization overhead, data management and a simplified programming model greatly outweigh any load balancing problems arising from coarse-grained parallelism. In addition, you can, in theory, duplicate the above behavior by using IRIX5 sysmp/schedctl commands to restrict processes to CPUs. For the above example you could MP_RESTRICT the 2 CULLs to the same CPU and use priorities or your own semaphores in the cull callbacks to serialize the 2 CULL processes and avoid wasted effort in context switching. > I know that 4 CPUs in not the bets configuration for running a dual pipe > performer application, but I think that allowing a separate multi-processing > mode for pipes would help in similar cases. > From guest Tue Jun 21 10:24:47 1994 From: "Ran Yakir" Message-Id: <9406212023.ZM11108@amcor.bvr.co.il> Date: Tue, 21 Jun 1994 20:23:37 +0000 X-Face: aaaaaaaaaaljasddfjsdlkfjasd X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: multi-channel synchronizing Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi I'm trying to run a dual piped system, which, upon arrival of hardware, should become triple piped. Right now I have only 4 CPUs on my ONYX, su I use PFMP_APP_CULLDRAW. The weird thing is that the left and right channels don't seem to synchronize. Although their cull-draws run on different processors, they tend not to run concurrently. Moreover, they skip frames in a manner that channel 0 does frame # N, channel 1 does (N+1), channel 0 does (N+2), channel 1 does (N+3), and so on ... . Sometimes they suddenly sync, and run concurrently, but not for long. Just to be sure its not an overload, I asked pfFrameRate to be 10Hz (100 msec), while the whole draw/cull thing takes less then 20 msec. I do plush the pipe at the end of each frame to get accurate timing results. In addition, I used the cpu locking utils from libpfutil, and runed as root, so that they don't switch processors on me. And ofcourse I run with PFPHASE_LOCK. Can anyone understand what that is ? Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Wed Jun 22 01:53:22 1994 Message-Id: <9406220852.AA82131@ns.trl.ibm.com> To: info-performer Cc: aono@trl.ibm.co.jp Subject: texture-map with Performer Date: Wed, 22 Jun 1994 17:52:39 +0900 From: Masaki Aono Status: O Hi. I'm curious about texture mapping with Performer. My questions are as follows: (1) Given a set of 3D triangles that represent a human head bone. Is there a tool to generate cylindrical/spherical texture coordinates such as the ones that are provided by Inventor's facilities? Please note that I want to texture-map an image surrounding the human head bone. If anyone knows a better way of texture-map with other methods, please suggest it to me. (2) Is there a source code that corresponds to pfLoadTexFile(tex,name)? I'm particularly interested in understanding the specific format of the texture image file. Although there is a description of such image file in GL's Programming Guide, it seems that a real texture file has certain header information (judging from the data provided in /usr/src/Performer/data such as tree.rgba and wood256.rgb), doesn't it? Anyone who knows the texture image format, please let me know. I'd appreciate anyone who can give an answer to me. Regards, Masaki Aono Tokyo Research Laboratory aono@trl.ibm.co.jp From guest Wed Jun 22 11:04:44 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406221804.AA16622@tubes.asd.sgi.com> Subject: Re: pfPhase() To: guest (William Briggs) Date: Wed, 22 Jun 94 11:04:32 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406172106.AA12633@niesten.arc.nasa.gov>; from "William Briggs" at Jun 17, 94 2:06 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > We are using: SkyWriter VGXT, IRIX 4.0.5, Performer 1.0 > > My situation: Our app has always been used with pfPhase set to > PFPHSE_FREE_RUN. Now we need a fixed frame rate > for taking experimental data. By setting the > phase to PFPHASE_LOCK the app is still looping, > but the display is frozen. I can change at will > between PFPHASE_LOCK and PFPHASE_FLOAT and the app > loops with no new display. Whenever I set the phase > back to PFPHASE_FREE_RUN, the app loops three more > times, then hangs. I have tried making PFPHASE_LOCK > the default (so we are not changing it dynamically) > but with the same results. We have never had any > problems changing the framerate while in PFPHASE_FREE_RUN. > > My questions: How do I get it to work? :^) More specifically, are > we supposed to be able to change the phase dynamically? > Is this frozen display a bug in our code, or somewhere > else? Why would it hang when going to PFPHASE_FREE_RUN? > > -------------------+------------------------------+------------------------ > William Briggs | MailStop 262-2 | "The computer screen > NASA Ames Research | PO Box 1000 | has become the retina > (415) 604-6438 | Moffett Field, CA 94035-1000 | of the mind's eye." > -------------------+------------------------------+------------------------ > > > > From guest Wed Jun 22 15:22:50 1994 Message-Id: <9406222222.AA23146@surreal.asd.sgi.com> To: info-performer Cc: mars@clubted.csd.sgi.com (David Marsland) Subject: EMAIL OVERLOAD??? Date: Wed, 22 Jun 94 15:22:48 -0700 From: Jim Helman Status: O The amount of traffic on the info-performer list is getting to be a bit much for a mailing list. Perhaps when the list gets a little bigger, someone will want to sponsor the RFD and CFV effort to start a newsgroup. Until then, a few tips. Being able to automatically sort incomng mail into separate folders makes life a lot easier when dealing with high volume mailing lists. I'm only familiar with two Zmail and RAND MH, but other mail systems probably have similar capabilities. 1) RAND MH users can sort incoming mail creating a ~/.forward file that reads something like: "| /usr/local/mh/lib/slocal -user jimh" And then a ~/.maildelivery file like: #field pattern action result string # To info-performer qpipe ? "/usr/local/mh/lib/rcvstore +inbox/infoperf" Cc info-performer qpipe ? "/usr/local/mh/lib/rcvstore +inbox/infoperf" This will cause mail to be placed straight into +inbox/infoperf and other mail to be left in /usr/mail/. See mhhook(1) for details. 2) Zmail users can sort incoming mail by placing a line in ~/.zmailrc like: filter pinfo 'save "/usr/people/jimh/Mail/infoperf"' -t -i info-performer This will cause mail to be saved in ~/Mail/infoperf. It will still appear in your incoming mail, but messages such as these which have already been saved to a folder can be purged with the Update command. Zmail/MedaiMail Pro users can set up filters from the GUI without editting ~/.zmailrc. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Wed Jun 22 15:39:05 1994 From: Brad West Subject: More on Email Overload To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Does anyone know how to do this with Pine (sort things into a different folder that is)? Or, since newsgroups take some time to get started, could we in the meantime get this into a digest form mailed out daily? From guest Wed Jun 22 16:09:24 1994 Date: Wed, 22 Jun 94 19:13:16 -0400 From: newcomb@enews.nrl.navy.mil (Dale Newcomb) Message-Id: <9406222313.AA20351@enews.nrl.navy.mil> To: info-performer@sgi.sgi.com Subject: Digest format Status: O Brad West once said... >in the meantime get this into a digest form mailed out daily? I second the motion! 10-20 mail messages a day really gets out of hand! A once a day digest would be 10-20 times better (-: than the current format. Dale From guest Wed Jun 22 17:17:25 1994 From: Simon Bennett Subject: Re: More on Email Overload To: Brad West Cc: info-performer@sgi.sgi.com In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Wed, 22 Jun 1994, Brad West wrote: > Does anyone know how to do this with Pine (sort things into a different > folder that is)? Or, since newsgroups take some time to get started, could > we in the meantime get this into a digest form mailed out daily? You can use an additional "mail agent" such as "procmail" or "mailagent" to add this sort of functionality to just about any mailer, such as PINE that doesn't come with a filter of its own. Later versions of PINE allow for multiple inboxes and as such fit in with using "procmail" et al quite nicely... Both "procmail" and "mailagent" are freely available by FTP... +--------------------------------------------------------------------------------+ Simon Bennett simonb@wormald.com.au Wormald Technology Advanced Systems Engineering Ph: +61 2 981 0611 (x512) "Business meetings are really very useful... For one thing they clearly demonstrate just how many people the company can do *without*" From guest Wed Jun 22 10:52:57 1994 From: Bernd Froehlich Message-Id: <9406221554.AA06322@viswiz.gmd.de> Subject: Darkness To: info-performer@sgi.sgi.com Date: Wed, 22 Jun 94 19:39:09 MDT Status: O Hi, we have just moved from Performer 1.2 beta ( 1.2a64 ) to 1.2 and from Irix5.1.1.2 to 5.2 on our Onyx RE2 system. Our software uses an extended version of the wavefront-obj-loader of the Performer 1.2 beta release. After recompiling the sources under 5.2 and Performer 1.2 our objects are not lit any more. Only the ambient term seems to work. Any ideas? Bernd ------------------------------------------------------------------------- Bernd Froehlich email: bernd@viswiz.gmd.de Dept. Scientific Visualization Tel: +49-2241-14-2364 GMD Fax: +49-2241-14-2040 Schloss Birlinghoven D-53754 St. Augustin Germany ------------------------------------------------------------------------- From guest Thu Jun 23 02:22:08 1994 From: "JAVIER CASTELLAR" Message-Id: <9406231041.ZM910@mar.madrid.sgi.com> Date: Thu, 23 Jun 1994 10:41:57 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Re: EMail Overload Mime-Version: 1.0 Encoding: 2 TEXT BOUNDARY, 30 MESSAGE, 3 TEXT BOUNDARY Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19406231041.ZM910.madrid.sgi.com" Status: O --PART-BOUNDARY=.19406231041.ZM910.madrid.sgi.com Encoding: 24 X-Zm-quoted-printable Content-Description: plain text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u Hi all, I agree with Jim in relation with the email overload and the idea to create a newsgroup BUT ... be aware about the next issues: 1) A big set of people only have access to the WAN using only low speed modems. 2) If info-performer goes to newsgroup, a big chunk of clients and SGI subsidiaries (which don=B4t acess to newsgroups due to several reasons) = will lose contact with it. The reason is that a newsgroup takes more bandwidth= because the people trends to subscribe to lots of newsgroups. Briefly: in= some organizations they forbid newsgroups (including small SGI offices). Then: PLEASE DO NOT REMOVE info-performer as MAILING LIST. IF YOU ARE PLANING DOING IT, PLEASE KEEP THE MAILING LIST AS WELL. P.D: Today we have a nice ISDN link, but we have suffered the above probl= em in the past. (anyway we don=B4t use newsgroups). Javier Castellar javier@madrid.sgi.com --PART-BOUNDARY=.19406231041.ZM910.madrid.sgi.com-- From guest Thu Jun 23 13:21:55 1994 From: "Bob Buckley" Message-Id: <9406231414.ZM16212@grimmy.mss.ctaeng.com> Date: Thu, 23 Jun 1994 14:14:21 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Landing Light Lobes Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 845 Status: O Hello all, We have the need for generating landing light lobes on our aircrew trainers for night landings. I've seen the 'projtex' demo and have taken a look at the source. Does anyone know of documentation concerning texture projection and the theory behind it? Has anyone attempted or been successful with aircraft landing light lobes? Thanks =========================================================================== 'Bwana' Bob Buckley CTA, Inc. Sr. Software Engineer 5670 Greenwood Plaza Blvd Visual Systems Englewood, CO 80111 (303) 889-1207 (303) 889-1200 bbuckley@ctaeng.com (303) 889-1398 Fax =========================================================================== From guest Fri Jun 24 09:50:48 1994 Message-Id: <199406241649.LAA04325@cs.tamu.edu> Date: Fri, 24 Jun 94 11:48:41 -0500 To: info-performer@sgi.sgi.com Subject: please add Status: O Please add me to the mailing list thanks, davew@cs.tamu.edu From guest Mon Jun 27 08:27:14 1994 Message-Id: <9406271526.AA18350@wb.com> Date: 27 Jun 1994 11:28:04 U From: "Weiblen, Mike" Subject: Massive Texture To: "Pf Mail List" Status: O I realize this isn't strictly a Performer question, but I am using Performer to load the textures... =============================================================================== I'm doing stress experiments to determine what limits the amount of texture I can load into RAM. The system I'm experimenting with is a 4-proc ONYX, 512MB RAM, 2 RM5s. My tests consist of loading many of our hi-res NELLIS geospecific photo textured terrain tiles (3.7MB of texture memory each). My initial experiments ended with "ERROR #2 texdef2d: ERR_OUTMEM" after Performer pfuDownloadTexList() reports ~114MB of texture loaded. I then set my filesize, datasize, stacksize, memoryuse and vmemoryuse limits to "unlimited". I watch the memory consumption with gr_osview and Performer's output as the RMs texdef() and page out the textures. gr_osview's memory bargraph goes up to 128M of some unspecified unit (words?). When it gets to ~122M, I see disk activity which bumps it down to ~118M. At the time of the first disk swap, pfuDownloadTexList() is reporting about 250MB texture loaded. Paging from the RM to RAM is bad enough, but swapping to disk is a real killer, and I'm looking for what kind of control I have over the texture swap threshold. Is there a manifest limit on the total RAM texture capacity? It has been difficult for me to get time on our 1500MB ONYX to test if the limit is a percentage of total mem. The bottom line: On the big ONYX, will it be possible for me to load our entire hi-res NELLIS database (total 525 MB of texture) without swapping textures to disk? -- mew From guest Mon Jun 27 13:38:09 1994 From: Brad West Subject: email overload pine solution To: Pf List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Here's a good way to solve things without having to use any sort of mail agent when you are using Pine. Just have your mailing list mail go to a different account. For instance, I usually use a machine with address "grizzly.cs.washington.edu", but I sometimes use "stein.u.washington.edu". My direct mail goes to grizzly, mailing list goes to stein. (Delete your .forward file!). Then, in Pine, create a separate folder for that inbox. In my .pinerc file I have: incoming-folders=Performer {stein.u.washington.edu}inbox It's pretty cool. I go through my normal mail, and then Pine gets my password for stein and opens the Performer folder. Brad From guest Mon Jun 27 19:19:44 1994 Message-Id: <9406280219.AA13885@surreal.asd.sgi.com> To: "Weiblen, Mike" Cc: "Pf Mail List" Subject: Re: Massive Texture In-Reply-To: Your message of "27 Jun 94 11:28:04 +0800." <9406271526.AA18350@wb.com> Date: Mon, 27 Jun 94 19:19:34 -0700 From: Jim Helman Status: O > At the time of the first disk swap, pfuDownloadTexList() > is reporting about 250MB texture loaded. Keep in mind that there can be up to three copies of a texture: 1) The image array that you handed Performer with pfTexImage() or the array allocated within pfLoadTexFile(). Unless you plan on changing texture attributes after the texture has been defined, you don't need this image at run time. To free the storage call pfFreeTexImage() after the texture has been used the first time (so you're sure it has been GL texdef'd.) This is in external format, typically 8 bits per component. 2) The image array inside GL on the host that GL uses to page down to the graphics pipe when needed. This is in internal format, 16bits per texel by default (e.g. RGB_5), and is necessary. 3) The copy (sometimes) down in the graphics hardware. If pfuDownLoadTexList() was reporting 250MB of texture loaded, that means there should be 250MB inside GL. Unless you have called pfuFreeTexImage, Performer has another 250MB to 500MB (depending on whether the internal and external formats have the same number of bytes per texel). 250MB is a LOT of texture. If you plan to do real-time paging of these textures through the 4-16MB of RM memory, you may run into some performance problems when GL deals with a large number of textures ids. If the textures are not mipmapped, you might look at using subtexload or tx_nocopy to reuse Performer (and hence GL) texture IDs. If the textures are mipmapped, you might look at combining several small textures that are used together onto larger single textures to reduce the number of GL texture IDs to a few hundred. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 28 00:16:31 1994 Date: Tue, 28 Jun 94 00:20:01 -0700 From: Stephen Lau Message-Id: <9406280720.AA04689@Crazypete.AI.SRI.COM> To: info-performer@sgi.sgi.com, "Weiblen, Mike" Subject: Re: Massive Textures Status: O Mike, I routinely page gigabytes of textures in and out of texture map memory on a 4 proc Onyx with RM4 boards, i.e. 4 MB of texture map memory. In the application I'm developing, textures are being read across a high speed network and paged into texture map memory as needed and paged out of texture map memory when no longer visible to the user. What you need to do is handle the paging yourself, if you let the GL try to page it, you'll have real poor performance. If you know the extent of the textures at runtime you can use subtexload() to specify what part of a very large texture you are about to load. In my case, the textures are being delivered across an unreliable high speed network, so what I do is treat texture map memory as about 110 128x128 16 bit textures. The number doesn't add up to exactly 4MB, since I keep some static textures around for clouds and buildings. I use TX_FASTDEFINE when I do a texdef2d() and keep track of which texture is associated to which "slot" in the 100 texture maps available. When I want to swap out a texture in a particular slot, since it is no longer visible or for whatever reason, I use TX_TEXTURE_IDLE with texture id "n", where "n" corresponds to the number of the texture that I want to toss out. This works real well and I've paged in and out of texture map memory gigabytes of textures. The end user perceives it as a very large area they can "roam" around in both in 2D and 3D. Hope this helps. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "If there's nothing wrong with me, SRI International | there must be something wrong 333 Ravenswood Ave., Menlo Park, CA. 94025| with the universe!" (415) 859-2925 (415) 326-6200| - Beverly Crusher, Star Trek:TNG ------------------------------------------------------------------------------- From guest Mon Jun 27 23:49:16 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406280948.ZM11775@rea1.bvr.co.il> Date: Tue, 28 Jun 1994 09:48:03 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfChanPick Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi there, I am currently using the pfChanPick routine. To enable selective picking I set isect masks of different nodes and GeoSets to have appropriate masks according to the object's type (using pfNodeTravMask). The only thing left to do before calling pfChanPick() is to set the channel isect traversal mask with which the traversal will compare with the individual nodes. How does one set this channel traversal mask? When calling pfSegsIsectGSet() one can set the traversal mask but how do you do it when calling pfChanPick()? Alon From guest Tue Jun 28 09:13:09 1994 Date: Tue, 28 Jun 94 09:12:56 -0700 From: mtj@babar (Michael Jones) Message-Id: <9406281612.AA23716@babar.asd.sgi.com> To: info-performer@sgi.sgi.com Subject: Performer Demo Contest Status: O To: Friends of Performer Worldwide From: The IRIS Performer Team RE: SIGGRAPH '94 Performer Contest The IRIS Performer team will again have an Onyx/RE2 system in one of SGI's booths at SIGGRAPH '94 in Orlando, Florida. We are looking for interesting and attractive demos of existing applications developed using IRIS Performer for exhibition at this station. The prizes, beyond the deep and lasting satisfaction of public recognition of a job well done, will be a new IRIS Performer "polo-style" shirt that has the IRIS Performer (with top-hat and cane) embroidered in seven colors on the front. This latest addition to the PerformerWear line is beautiful and much sought after. We'll have a 4-CPU deskside system with either two or four Raster Manager boards at a small stand with monitor, mouse and (possibly) a flybox. If you have an application that runs well in this configuration that you would like to enter into the judging for the demo contest, please take the following steps: 1. Send email to me (mtj@sgi.com) with a brief summary of the application: what it is, how the user interacts, frame rates, special I/O devices required, etc. A screen snapshot in RGB form would be great. The decision will happen on July 11th, and entries after the decision will be deemed to have lost. 2. I'll respond with the method for sending your demo to us for judging and a simple release form that says we're allowed to show the demo in our booth at SIGGRAPH '94. FAX the release back to me and ftp or mail the demo, and you'll have entered. 3. Please let me know if you would be willing to schedule a time slot during SIGGRAPH when you could come by the booth and explain your work to the many customers who will be asking for more information. 4. Also, let me know if you'd like to have an RGB snapshot of your application and a one paragraph description of it to appear on the SGI IRIS Performer xmosaic page. The judges (the seven members of the IRIS Performer team) will pick four winning demos based on theme, technical merit, and beauty. All entrants -- winning or not -- will be invited to join the IRIS Performer team for a late-night "engineering discussion" (;-) at Disney's Pleasure Island. Good Luck! Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj@sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Tue Jun 28 01:44:51 1994 From: "Harald Kaul" Message-Id: <9406281043.ZM1007@harald.munich.sgi.com> Date: Tue, 28 Jun 1994 10:43:58 -0600 In-Reply-To: "Weiblen, Mike" "Massive Texture" (Jun 27, 11:28am) References: <9406271526.AA18350@wb.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Weiblen, Mike" , "Pf Mail List" Subject: Re: Massive Texture Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O On Jun 27, 11:28am, Weiblen, Mike wrote: > Subject: Massive Texture > I realize this isn't strictly a Performer question, but I am using Performer to > load the textures... > > =============================================================================== > gr_osview's memory bargraph goes up to 128M of some unspecified unit (words?). > When it gets to ~122M, I see disk activity which bumps it down to ~118M. At > the time of the first disk swap, pfuDownloadTexList() is reporting about 250MB > texture loaded. > > Paging from the RM to RAM is bad enough, but swapping to disk is a real killer, > and I'm looking for what kind of control I have over the texture swap > threshold. > > Is there a manifest limit on the total RAM texture capacity? It has been > difficult for me to get time on our 1500MB ONYX to test if the limit is a > percentage of total mem. The bottom line: On the big ONYX, will it be > possible for me to load our entire hi-res NELLIS database (total 525 MB of > texture) without swapping textures to disk? > > -- mew > > >-- End of excerpt from Weiblen, Mike in addition to Jim's comments: the memory bargraph uses pages as unit, I don't think it says 118M but 118k, this is 118k * 4k = 472 MB, ==> you are reaching the limit of the memory of your "small" system. Jim pointed out why you needed such much memory. -Harald -- @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ Harald Kaul @ @ SiliconGraphics GmbH @ @ D-85630 Grasbrunn-Neukeferloh @ @ Mail Stop IMU-315 @ @ Tel.: (+int) 89/46108-123 @ @ FAX: -222 @ @ VM: #59195 @ @ E-Mail: @ @ haraldk@munich.sgi.com @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ From guest Tue Jun 28 11:20:26 1994 Message-Id: <9406281820.AA26597@surreal.asd.sgi.com> To: info-performer@sgi.sgi.com, "Weiblen, Mike" , Stephen Lau Subject: Re: Massive Textures In-Reply-To: Your message of "Tue, 28 Jun 94 00:20:01 PDT." <9406280720.AA04689@Crazypete.AI.SRI.COM> Date: Tue, 28 Jun 94 11:20:10 -0700 From: Jim Helman Status: O A couple more bits of info. Currently subtexload and fast define only work for non-mipmapped textures. Better things are coming with OpenGL. When you're using idling textures (TX_TEXTURE_IDLE) and then pfApplying or texbinding new ones to page them down to the graphics pipe, keep in mind that texture memory fragmentation can occuar. To completely avoid fragmentation, you need to keep all your pagable textures the same size and type. And if you're making a major scene transition in your database (e.g. a VR portal), you can reduce potential fragmentation by idling the whole set of old textures before starting to bind/apply the new ones. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 28 12:17:36 1994 Date: Tue, 28 Jun 94 15:18:38 -0400 From: seguin@vr1.engin.umich.edu (Ralph Seguin) Message-Id: <9406281918.AA17017@vr1.engin.umich.edu> To: info-performer@sgi.sgi.com Subject: Performer and Inventor together Cc: seguin@vr1.engin.umich.edu Status: O Hi. I have a couple of questions. We currently have an application using an SGI Onyx and a Fakespace Boom2C (upgrading to a 3C and a 2nd Onyx soon hopefully). Our application is homebrewed using GL. On the next round of development, we would like very much to start using Performer to help with rendering speed, and to use Inventor to supply us with a good user interface. My question is: -Is this feasible? -Practical? -Possible to put Performer render into a GLX widget? Make canvas toggle between full screen and parented size? (boom mode requires full screen). Thanks, Ralph From guest Tue Jun 28 13:03:00 1994 Date: Tue, 28 Jun 94 13:06:28 -0700 From: Stephen Lau Message-Id: <9406282006.AA07453@Crazypete.AI.SRI.COM> To: info-performer@sgi.sgi.com, Jim Helman Subject: Re: Massive Textures Status: O Yeah, texture fragmentation was a problem that I noticed after doing some timing tests. All of my textures are the same size and type, 128x128. Too bad there isn't any more hooks into the GL to examine and manage texture map memory. Steve ------------------------------------------------------------------------------- Stephen Lau lau@ai.sri.com| "If there's nothing wrong with me, SRI International | there must be something wrong 333 Ravenswood Ave., Menlo Park, CA. 94025| with the universe!" (415) 859-2925 (415) 326-6200| - Beverly Crusher, Star Trek:TNG ------------------------------------------------------------------------------- From guest Tue Jun 28 13:19:12 1994 Message-Id: <9406282017.AA26821@surreal.asd.sgi.com> To: Stephen Lau Cc: info-performer@sgi.sgi.com Subject: Re: Massive Textures In-Reply-To: Your message of "Tue, 28 Jun 94 13:06:28 PDT." <9406282006.AA07453@Crazypete.AI.SRI.COM> Date: Tue, 28 Jun 94 13:17:30 -0700 From: Jim Helman Status: O > All of my textures are the same size and type, 128x128. > Too bad there isn't any more hooks into the GL to examine > and manage texture map memory. With OpenGL, it's less problematic to eliminate fragmentation in this way, since you can define your own mipmaps. This means that you can make all of your pagable textures the same size (say 256x256) and then combine multiple images into a single texture (say 4 128x128's into a 256x256) without worrying about the "mixing" of adjacent images that occurs in the automatically generated Iris GL mipmaps. Does anyone have texture paging/fragmentation issues that could not be addressed in this way? rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Tue Jun 28 11:02:02 1994 Message-Id: <9406281800.AA19550@wb.com> Date: 28 Jun 1994 14:02:10 U From: "Weiblen, Mike" Subject: RE: Performer Demo Contest To: "Michael Jones" , "Pf Mail List" Status: O Cool! Can you give any more specifics on the machine: How much RAM/disk? RM4s or RM5s? -- mew Mike Weiblen (mweiblen@wb.com), ARPA War Breaker, Arlington VA, 703-908-4358 _______________________________________________________________________________ Date: Tue, 28 Jun 94 09:12:56 -0700 From: mtj@babar.asd.sgi.com (Michael Jones) Message-Id: <9406281612.AA23716@babar.asd.sgi.com> To: info-performer@sgi.com Subject: Performer Demo Contest To: Friends of Performer Worldwide From: The IRIS Performer Team RE: SIGGRAPH '94 Performer Contest ... We'll have a 4-CPU deskside system with either two or four Raster Manager boards at a small stand with monitor, mouse and (possibly) a flybox. If you have an application that runs well in this configuration that you would like to enter into the judging for the demo contest, please take the following steps: ... From guest Tue Jun 28 07:14:20 1994 From: "Daniel Banek" Message-Id: <9406281608.ZM28790@sgikar.karlsruhe.sgi.com> Date: Tue, 28 Jun 1994 16:08:25 -0600 Reply-To: panic@karlsruhe.sgi.com X-Mailer: Z-Mail-SGI (3.0S.1023 23oct93 MediaMail) To: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O please subscribe me regards Daniel Banek -- +---------------------------------+ __ __ * __ | Daniel Banek Graphic Guru | /| / / / /_//\ /| / / / | SiliconGraphics Germany | / |/ /_/ / /--\/ |/ / /_ | email: panic@karlsruhe.sgi.com | | Mailstop: IKA-317 VM #9207 | +---------------------------------+ From guest Wed Jun 29 04:54:15 1994 Date: Wed, 29 Jun 94 13:54:06 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9406291154.AA24765@scl> To: info-performer@sgi.sgi.com Subject: Environment mapping ... Status: O Bonjour a tous ... I'm using environment mapping with 1.2 version and I'd like to find the binary and/or source code which allows to transform a standard map image to a spherical one as in the buttonfly envmap demos ... does any one knows anything about where to find this ? ... Merci a tous ... Thank's to everybody ... Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Wed Jun 29 11:11:10 1994 Date: Wed, 29 Jun 94 11:07:57 PDT From: goodhart@cod.nosc.mil (Curtis L. Goodhart) Message-Id: <9406291807.AA07297@cod.nosc.mil> To: info-performer@sgi.sgi.com Subject: Compiler crash - perfly Status: O A couple of us now have experienced system intermittent system crashes when we are compiling modified perfly code. We are running on an ONYX with 2 CPUs running IRIX 5.2 and Performer 1.2. We do a make on perfly, and the system crashes and then comes up in the state where we can restart the system (ie the display comes up with the icons for different things: green light for restarting the system, an icon for diagnostics, etc). A recompile of the same source code then may work. Ie the crash is itermittent. Anyone experienced anything like this? Thanks, Curt Goodhart NRaD San Diego, CA 619 553-2002 From guest Wed Jun 29 09:10:13 1994 From: "Ran Yakir" Message-Id: <9406291909.ZM9676@amcor.bvr.co.il> Date: Wed, 29 Jun 1994 19:09:07 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfFog Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi What is the reason for the exsitance of fog-offsets ? Is there any difference (in performance or other) between setting fog-ranges or fog-offsets ? Ran -- __ | Ran Yakir /_) _ __ \ / _ / o __ | Graphics App. Chief Engineer / )_ (_(_) ) \/ (_(_/<_(_)( | BVR Technologies Ltd. _/ | -------------------------------------+-------------------------------- Phone : | E-mail : rany@bvr.co.il Work : 972-3-5715671 | Res. : 972-3-6995364 | Fax : 972-3-5715668 | From guest Wed Jun 29 18:59:43 1994 Message-Id: <00581.2855761377.1539@multigenuunet.UU.NET> Organization: Software Systems X-Charset: MACINTOSH X-Umcp-To: INFO PERFORMER From: Marcus To: INFO PERFORMER Date: Wed, 29 Jun 1994 17:00:55 PST Subject: Re: FadeLOD & Lightpoints == Status: O Reply to: RE>FadeLOD & Lightpoints == BU Sorry for the late reply, The OpenFlight loader does not handle directional light points correctly. The direction vector is simply interpreted wrong and the light shape is 90 degrees by 90 degrees (old/current Performer defaults?). MultiGen directional lights have shapes of 180 by 180 degrees. If they have a back color they're considered PFLP_BIDIRECTIONAL (but only front colored, hmm... any chance that Performer will support multi-colored light points?) otherwise they're PFLP_UNIDIRECTIONAL. Light point direction vector and shape are nearly fixed. These and other improvements will be available in the next OpenFlight loader released by MultiGen Inc., some time in July ... 1994 ;-) (SIGGRAPH permitting) As to the falloff of a pfLightPoint, MultiGen doesn't have that concept, so the default falloff value of 4 is used by the loader. Their interaction with Performer's fade LOD capability is best answer by someone in the Performer Group. PS: Thanks for the reminder Jean. Regards, Mark Barnes, Member Technical Staff MultiGen Inc., 1884 The Alameda, San Jose CA, 95126 PH: (408) 261 4110 FX: (408) 247 4329 EMAIL: multigen!marcus@uunet.UU.NET -------------------------------------- Date: 6/8/94 10:05 PM To: Marcus From: Howard Abrams From guest Wed Jun 29 11:14:04 1994 Message-Id: Date: Wed, 29 Jun 94 20:13 MDT From: matomira@lig.di.epfl.ch (Fernando D. Mato Mira) To: info-performer@sgi.sgi.com Subject: stereo on Indigo II Extreme Reply-To: matomira@epfl.ch Status: O Hello, I am running Performer 1.2 on an Indigo II Extreme with 5.2 and everything is OK with the dual-channel display until I do setmonitor(STR_RECT) Then, the machine gets into stereo mode, and I get to see in stereo, but the application stops updating the display, even if I return to normal mode. The programs seems to run fine if stereo was set before lanunching it (of course, doing setmonitor from the program messes up allways). I create the channels like in the 3-channel simulation example (with one less channel, different offsets, and viewports that will match the stereo drawing areas). Thanks Fernando D. Mato Mira Computer Graphics Lab Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248 CH-1015 Lausanne FAX : +41 (21) 693 - 5328 Switzerland E-mail : matomira@di.epfl.ch From guest Thu Jun 30 01:52:08 1994 Date: Thu, 30 Jun 94 10:52:04 +0200 From: gce@scl.syseca.fr (Cedric Gautier ) Message-Id: <9406300852.AA01757@scl> To: info-performer@sgi.sgi.com Subject: Shadows ... Status: O Bonjour a tous ... This is not really a Performer question but the answer should help me to use it in !. Any ideas where I can find some shadows rendering example codes ?. Merci par avance ... Thank's a lot ... Cedric from Dahouet harbor on Armor coast in France - email: gce@syseca.fr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From guest Wed Jun 29 23:15:47 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406300900.ZM18215@rea1.bvr.co.il> Date: Thu, 30 Jun 1994 09:00:01 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: pfChanPick Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, I am currently using the pfChanPick routine. To enable selective picking I set isect masks of different nodes and GeoSets to have appropriate masks according to the object's type (using pfNodeTravMask). The only thing left to do before calling pfChanPick() is to set the channel isect traversal mask with which the traversal will compare with the individual nodes. How does one set this channel traversal mask? For Draw and Cull traversals one may use pfChanTravMask() but what routine should I use when using the pfChanPick() call? thanks Alon From guest Thu Jun 30 00:55:42 1994 From: "Pablo Goldszeft" Message-Id: <9406301053.ZM18789@rea1.bvr.co.il> Date: Thu, 30 Jun 1994 10:53:13 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Inventor format file loader Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hello, I'm trying to import an Inventor file created with the "revo" demo tool, to my Performer 1.2 application using the LoadIv() routine. The routine doesn't seem to recognize the tokens in the file. Why? (By the way, "revo" outputs files in Inventor 2.0 format. I've converted the files into Inventor 1.0 format using the "iv2toiv1") The file looks as follows: #Inventor V1.0 ascii Separator { ShapeHints { hints (ORDERED | CONVEX) } Coordinate3 { point [ 0.5 -0.2 0, 0.472909 -0.2 0.16235, 0.39457 -0.2 0.307106, 0.273474 -0.2 0.418583, 0.122743 -0.2 0.4847, -0.0412897 -0.2 0.498292, -0.200848 -0.2 0.457887, -0.338641 -0.2 0.367862, -0.439737 -0.2 0.237974, -0.493181 -0.2 0.0822973, -0.493181 -0.2 -0.0822973, -0.439737 -0.2 -0.237974, -0.338641 -0.2 -0.367862, -0.200848 -0.2 -0.457887, -0.0412897 -0.2 -0.498292, 0.122743 -0.2 -0.4847, 0.273474 -0.2 -0.418583, 0.39457 -0.2 -0.307106, 0.472909 -0.2 -0.16235, 0.5 -0.2 0, 0.5 0.2 0, 0.472909 0.2 0.16235, 0.39457 0.2 0.307106, 0.273474 0.2 0.418583, 0.122743 0.2 0.4847, -0.0412897 0.2 0.498292, -0.200848 0.2 0.457887, -0.338641 0.2 0.367862, -0.439737 0.2 0.237974, -0.493181 0.2 0.0822973, -0.493181 0.2 -0.0822973, -0.439737 0.2 -0.237974, -0.338641 0.2 -0.367862, -0.200848 0.2 -0.457887, -0.0412897 0.2 -0.498292, 0.122743 0.2 -0.4847, 0.273474 0.2 -0.418583, 0.39457 0.2 -0.307106, 0.472909 0.2 -0.16235, 0.5 0.2 0 ] } Normal { vector [ 1 0 0, 0.945817 0 0.324699, 0.789141 0 0.614213, 0.546948 0 0.837166, 0.245485 0 0.9694, -0.0825793 0 0.996584, -0.401695 0 0.915773, -0.677282 0 0.735724, -0.879474 0 0.475947, -0.986361 0 0.164595, -0.986361 0 -0.164595, -0.879474 0 -0.475947, -0.677282 0 -0.735724, -0.401695 0 -0.915773, -0.0825793 0 -0.996584, 0.245485 0 -0.9694, 0.546948 0 -0.837166, 0.789141 0 -0.614213, 0.945817 0 -0.324699, 1 0 0, 1 0 0, 0.945817 0 0.324699, 0.789141 0 0.614213, 0.546948 0 0.837166, 0.245485 0 0.9694, -0.0825793 0 0.996584, -0.401695 0 0.915773, -0.677282 0 0.735724, -0.879474 0 0.475947, -0.986361 0 0.164595, -0.986361 0 -0.164595, -0.879474 0 -0.475947, -0.677282 0 -0.735724, -0.401695 0 -0.915773, -0.0825793 0 -0.996584, 0.245485 0 -0.9694, 0.546948 0 -0.837166, 0.789141 0 -0.614213, 0.945817 0 -0.324699, 1 0 0 ] } NormalBinding { value PER_VERTEX_INDEXED } QuadMesh { verticesPerColumn 2 verticesPerRow 20 } } -- Pablo Goldszeft From guest Thu Jun 30 09:38:29 1994 Date: Thu, 30 Jun 94 09:06:10 -0700 From: sal@sgidev.mdc.com (Sal Cabaruvias) Message-Id: <9406301606.AA15175@sgidev.mdc.com> To: iris-performer@sgi.sgi.com Subject: Performer Questions Status: O Hi, I was refered by local sgi salesman to you. I hope you can help me. I am creating a 400 by 400 nm database using DTED data. This creates 60 by 60 nm tiles (sections). If I was to implemented a swapping alogithm to bring my tiles as I need them, what Performer calls do I use? I am using Coryphaeus DWB to create my database files. I not sure what calls release old sections of the database and what calls bring in databases. Thanks, sal ----------------------------------------------------------------------------- Salvador Cabaruvias |email: sal@sgidev.mdc.com CSSL |saying: "Well I be done seen about McDonnell Douglas | everything when I see elephant (310) 593-6719 | fly!" --- Dumbo --- ----------------------------------------------------------------------------- From guest Thu Jun 30 09:39:55 1994 From: "Dennis Pierce" Message-Id: <9406301239.ZM11436@sgimco.orlando.sgi.com> Date: Thu, 30 Jun 1994 12:39:51 -0400 X-Mailer: Z-Mail-SGI (3.0S.1026 26oct93 MediaMail) To: iris-performer@sgi.sgi.com Subject: collisions Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O customer is doing collision detection between ownship and models in his database - he fires off intersection rays and gets hit coordinates returned that are related to his ownship's distance from the world's center, not related to the distance between the ownship and the model is this normal? also, what is the proper method to use to determine if his ownship intersects a moving model? collisions with SCS objects works just fine, but the DCS objects are absolute to the distance from the origin and not the relative distance between models thanks! bye. -- Dennis Pierce, SGI, 900 Winderley Place, Ste 130, Maitland, FL 32751 email: dpierce@sgi.com vmail: 8548 tel : 407.660.0073 late : 407.660.2789 fax : 407.660.8981 cell : 407.256.8447 From guest Thu Jun 30 08:31:47 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406301829.ZM20019@rea1.bvr.co.il> Date: Thu, 30 Jun 1994 18:29:58 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: bug in pfuTraverse() Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, I believe that there is a bug in the pfuTraverse() routine. The bug is such that every time the routine recursively enters itself, it writes the node (given as a parameter) into trav->node. The fact that trav is a pointer to a single copy of the trav structure (initially passed by the user) causes the last assignment of trav->node to hold and in turn the postFunc will get a trav pointer with a wrong node pointer (that of the last visited node in the recursion). I fixed it as follows: pfuTraverse(pfNode *node, pfuTraverser *trav) { pfMatrix mat; From guest Thu Jun 30 09:00:36 1994 From: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Message-Id: <9406301848.ZM20075@rea1.bvr.co.il> Date: Thu, 30 Jun 1994 18:48:41 +0000 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: bug in pfuTraverse() Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: O Hi, I believe that there is a bug in the pfuTraverse() routine. The bug is such that every time the routine recursively enters itself, it writes the node (given as a parameter) into trav->node. The fact that trav is a pointer to a single copy of the trav structure (initially passed by the user) causes the last assignment of trav->node to hold and in turn the postFunc will get a trav pointer with a wrong node pointer (that of the last visited node in the recursion). I fixed it as follows: pfuTraverse(pfNode *node, pfuTraverser *trav) { pfMatrix mat; . . pfNode *keep_node; keep_node = trav->node; trav->node = (pfNode *)node; . . . . . if (trav->postFunc) (*trav->postFunc)(trav); trav -> node = keep_node; return PFTRAV_CONT; } Thats it I guess Alon From guest Thu Jun 30 11:52:33 1994 Message-Id: <9406301852.AA24688@surreal.asd.sgi.com> To: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Cc: info-performer Subject: Re: bug in pfuTraverse() In-Reply-To: Your message of "Thu, 30 Jun 94 18:48:41 -0000." <9406301848.ZM20075@rea1.bvr.co.il> Date: Thu, 30 Jun 94 11:52:30 -0700 From: Jim Helman Status: O Correct. It's now fixed for the next release. thanks, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 12:02:43 1994 Message-Id: <9406301902.AA24730@surreal.asd.sgi.com> To: "Dennis Pierce" Cc: iris-performer@sgi.sgi.com Subject: Re: collisions In-Reply-To: Your message of "Thu, 30 Jun 94 12:39:51 EDT." <9406301239.ZM11436@sgimco.orlando.sgi.com> Date: Thu, 30 Jun 94 12:02:32 -0700 From: Jim Helman Status: O > customer is doing collision detection between ownship and models > in his database - he fires off intersection rays and gets hit > coordinates returned that are related to his ownship's distance > from the world's center, not related to the distance between > the ownship and the model 1) The line segments need to be constructed in world space around the ownship. 2) To avoid detecting ownship, the line segments need to either start outside the ownship model or intersection masks set to ignore ownship. If the customer follows these two rules, it should work fine. > also, what is the proper method to use to determine if his ownship > intersects a moving model? collisions with SCS objects works just > fine, but the DCS objects are absolute to the distance from the > origin and not the relative distance between models Hmm... the behavior of SCSes and DCSes should be identical. Is the user transforming the pfHit collision point into world space? Hits are returned in the local coordinates as specified in the pfGeoSet. If the SCSes have been "flattened" to identity matrices during database loading, the behavior will be different, since the flattened geometry now now includes the transformation formerly represented in the SCS. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 12:05:33 1994 Message-Id: <9406301904.AA24743@surreal.asd.sgi.com> To: alon@bvr.co.il (Alon Rosenfeld 18 Hatzedef street Jaffa ) Cc: info-performer@sgi.sgi.com Subject: Re: pfChanPick In-Reply-To: Your message of "Thu, 30 Jun 94 09:00:01 -0000." <9406300900.ZM18215@rea1.bvr.co.il> Date: Thu, 30 Jun 94 12:04:49 -0700 From: Jim Helman Status: O > How does one set this channel traversal mask? For Draw and Cull traversals one > may use pfChanTravMask() but what routine should I use when using the > pfChanPick() call? Currently, pfChanPick's mask is hard coded to PFTRAV_SET_PICK. But using the currently unused pfChanTravMask(PFTRAV_ISECT) sounds like a possible idea for a future release. For now, if you want different masks, you should use pfSegsIsectNode(). rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 13:25:27 1994 Date: Thu, 30 Jun 1994 15:26:41 -0500 From: Milt Fulghum Message-Id: <199406302026.AA13558@esiris3.vss.fsi.com> To: info-performer@sgi.sgi.com Subject: List Server for Performer? Reply-To: fulghum@vss.fsi.com Status: O Greetings, I heard a rumor that the subject list server exists. If so, please send me subscription info. Thanks, Milton Fulghum ----------------------------------------------------------------------------- Milton L. Fulghum PHONE: (314) 925-8576 FlightSafety International, Inc. FAX: (314) 925-8444 2590 North Highway 94 E-Mail: fulghum@vss.fsi.com Saint Charles, MO 63301-0037 From guest Thu Jun 30 14:11:01 1994 Message-Id: <199406302110.RAA02009@gecko.cis.ohio-state.edu> To: info-performer@sgi.sgi.com Subject: Format for materials Status: O I'm looking for the format for the material file used by wavefront (.obj) data file. I'm using the pfsgi.mtl file as an example but would like clarification on some aspects as well as a complete list of options. Is this documented anywhere ? Thanks, Mark Visconti LTSI, WPAFB, Dayton, OH From guest Thu Jun 30 17:31:16 1994 id AA28044; Thu, 30 Jun 94 17:30:04 -0700 Date: Thu, 30 Jun 1994 17:30:02 -0700 (PDT) From: "Payton R. White" Subject: Intersect problems To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I'm getting a crash deep in the collision routines and I would like some feedback on what might be causing it. I can't find anything that says I should call intersect functions from a specific place or process but I wouldn't doubt that this is part of the problem. Currently my collision routines are called from my navigation function in the draw callback. This is what I get back from 'where' in dbx: 0 pfGeode::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x10023100) ["../../../lib/libpf/pfGeode.C":518, 0x499b70] 1 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x10023100) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 2 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x10023100) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 3 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x1) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 4 pfGroup::intersect(pfIsector*)(0x0, 0x940860, 0x0, 0x2, 0x0) ["../../../lib/libpf/pfGroup.C":512, 0x4869a8] 5 pfNode::segsIsect(_pfSegSet*,_pfHit***)(0x8e02d0, 0x940860, 0x7fffabd8, 0x2, 0x0) ["../../../lib/libpf/pfNode.C":1257, 0x484240] 6 pfSegsIsectNode(0x8e02d0, 0x1001d680, 0x7fffabd8, 0x2, 0x10023100) ["../../../lib/libpf/cNode.C":369, 0x453b70] 7 pfpCollideGrnd(coord = 0x781444, node = 0x8e02d0, zpr = 0x7fffac14) ["/users/guests/u27486/vr/pfpCollide.c":72, 0x42d0b8] 8 full_drive(coord = 0x781444) ["/users/guests/u27486/vr/nav.c":635, 0x4285d8] 9 nav_drive(shared = 0x781440) ["/users/guests/u27486/vr/nav.c":589, 0x42817c] 10 navigate(shared = 0x781440) ["/users/guests/u27486/vr/nav.c":50, 0x42616c] 11 DrawChannel(chan = 0x9497e0, data = (nil)) ["/users/guests/u27486/vr/vr.c":178, 0x42bf40] 12 doDrawChannel(pfChannel*)(0x949c80, 0x0, 0x10023100, 0x2, 0x4038426e) ["../../../lib/libpf/pfProcess.C":1775, 0x44d434] 13 pfFrame(0x9497e0, 0x781444, 0x781450, 0x2, 0x0) ["../../../lib/libpf/pfProcess.C":1500, 0x44c5f8] 14 main(argc = 1, argv = 0x7fffaef4) ["/users/guests/u27486/vr/vr.c":63, 0x42ba88] Thanks, -- Visualization << SGI >> Simulation -- Payton R. White __ __ __ prwhite@ucsd.edu / / /_/ _/ /_ ______ _____ __ __ / /___ __ / __/______ / __ // .__// /__/ // __ // / / / / ____/ / /_/ // / / _ // / / // /_ / /_ / __/_ / ____//_/ \_/ \_//_/ /_//___/ /___//_____/ / /When the going gets weird, the weird turn pro. /_/ - Hunter S. Thompson From guest Thu Jun 30 18:19:28 1994 Message-Id: <9407010119.AA26287@surreal.asd.sgi.com> To: "Payton R. White" Cc: info-performer@sgi.sgi.com Subject: Re: Intersect problems In-Reply-To: Your message of "Thu, 30 Jun 94 17:30:02 PDT." Date: Thu, 30 Jun 94 18:19:12 -0700 From: Jim Helman Status: O > I can't find anything that > says I should call intersect functions from a specific place or process > but I wouldn't doubt that this is part of the problem. Bad documentation. pfSegsIsectNode() should only be called from the APP or ISECT process, although it probably would also work from the CULL process. The DRAW process does not have a private copy of the scene graph, so it's easy to imagine scene graph changes colliding. Also, intersections can be time consuming, so they are usually the last sort of thing you want to be doing in the DRAW process. > Currently my collision routines are called from my navigation > function in the draw callback. That's probably the cause of the problem. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Thu Jun 30 20:13:57 1994 Message-Id: Date: Thu, 30 Jun 94 22:13 CDT From: milo@mcs.com (Greg Corson) To: info-performer@sgi.sgi.com Status: O Please unsubscribe me...thanks milo@mcs.com From guest Thu Jun 30 20:13:42 1994 Date: Thu, 30 Jun 1994 20:13:55 -0700 From: hitchner@netcom.com (Lew Hitchner) Message-Id: <199407010313.UAA01452@netcom14.netcom.com> To: info-performer@sgi.sgi.com Subject: Re: Intersect problems Status: O "Payton R. White" wrote and "Jim Helman" replied: >> I can't find anything that >> says I should call intersect functions from a specific place or process >> but I wouldn't doubt that this is part of the problem. > > Bad documentation. pfSegsIsectNode() should only be called from the > APP or ISECT process, although it probably would also work from the > CULL process. The DRAW process does not have a private copy of the > scene graph, so it's easy to imagine scene graph changes colliding. > > Also, intersections can be time consuming, so they are usually the > last sort of thing you want to be doing in the DRAW process. > >> Currently my collision routines are called from my navigation >> function in the draw callback. > > That's probably the cause of the problem. > > rgds, > > -jim helman > > jimh@surreal.asd.sgi.com > 415/390-1151 Actually, this is documented -- in the new and improved IRIS Performer Programming Guide (for v1.2, Doc. # 007-1680-020). In chapter 7: Frames and Load Control, in the section "Rules for Invoking Functions While Multiprocessing" in table 7-4 "Trigger Routines and Associated Processes" on page 177, it says exactly what Jim replied: that pfSegIsectNode should only be called from ISECT or APP processes. The rest of that table and section contain much more good info. This is a new manual and I imagine most users haven't read it much. But thanks to the Performer Group a lot of work was put into improving the v1.2 Prog. Guide -- and it is improved! I recommend it both for learning or reviewing fundamental principles and as a reference (this release of the manual is quite well indexed). Lew Hitchner VR and Visual Sim Consultant Mountain View, CA hitchner@netcom.com From guest Thu Jun 30 21:07:37 1994 From: hardis@vsl.ist.ucf.edu (Ken Hardis) Message-Id: <9407010407.AA14053@horus.vsl.ist.ucf.edu> To: info-performer@sgi.sgi.com Subject: UNSUBSCRIBE Cc: hardis@vsl.ist.ucf.edu Status: O Please unsubscribe me; thanks hardis@vsl.ist.ucf.edu ******************************************************************************* * KEN HARDIS Phone: 407-658-5511 * * Institute for Simulation & Training FAX : 407-658-5059 * * Visual Systems Lab Email: hardis@vsl.ist.ucf.edu * * 3280 Progress Drive * * Orlando, FL 32826-0544 "for(;;) { :-) }"* *******************************************************************************